bernhard

Please have a look at this thread. As far as I know this is still valid:

You can also take a look at https://www.cursor.com/ and https://windsurf.com/editor - I tried both for several months and both are very good and have their pros and cons.

Either way it should not log something on each request. The goal is that RockMigrations does not slow down the site and only does something when it really needs to do something. This was obviously not the case here even though a single fileputcontents() might not be a noticeable penalty, but still...

Hey @FireWire thx for the report! This was partly intended and partly not. The intentional part was that it SHOULD log something if migrations are triggered but disabled (to make it obvious if somebody expects migrations to do something and nothing happens). What was also intentional is that the file does only reset when migrations actually run. The idea was to save disk read/write operations. What was NOT intentional though is that this logging took place on every single request, which obviously means a small performance penalty on each request when using RockMigrations - even when it is disabled. I just pushed a fix for this to v6.8.2 https://github.com/baumrock/RockMigrations/commit/429ce68f3418aeedee108d80949fc14a224561a5 Now the logging only happens when $config->debug is enabled. I also removed the log regarding MagicPages, which was logging on every single request, adding an additional file write on every single request 😮 Thank you for making me aware of that!

Ever needed a color picker on some kind of settings page? Didn't want to install and setup a full-blown colorpicker module? Here's a quick and dirty hook to change a regular text field into an <input type="color"> type of input: Before: After: <?php public function init(): void { wire()->addHookBefore('Inputfield::render', $this, 'changeFieldType'); } public function changeFieldType(HookEvent $event): void { $f = $event->object; $colorFields = [ Site::field_col_primary, Site::field_col_secondary, Site::field_contrast_primary, Site::field_contrast_secondary, ]; if (!in_array($f->name, $colorFields)) return; $f->attr('type', 'color'); } So right before the text input is rendered we change its "type" property to "color" and the browser will render a default color picker 😎 It once more shows how versatile ProcessWire is. And maybe it helps someone... 🙂 PS: Be advised that with that hack you only modify the optics of the field. The field will under the hood still be a regular text field, which means you'll not get any sanitisation or such from it and you might have to take care of that on your own. In my case it's a superuser-only settings page. So it is no issue at all.

Thank you very much @FireWire This also fixed this issue and is now part of RockPageBuilder v6.5.0 😎 I'm really thankful that you are not only using my modules but also helping to improve them 🙂

Hey @noodles this is now possible with the latest update v1.7.0 😎 I worked on that for several hours - far more than I initially thought. I tried different things, refactored, reset, and settled with a new "expert" option to keep the "simple" and "advanced" modes as they were and not bloat the GUI for something that probably 99% of users will never need?

When using vanilla JS you need to make sure that this header is set. This is what tells PW it's an ajax request. jQuery sets it by default, vanilla JS doesn't.

Ok then it means you are missing the ProcessWire namespace on the _init file 😉 I've added a note to the docs, thx.

Hi @Stefanowitsch the module needs to be installed otherwise the rockdevtools() function will not be available

Hi @bia welcome to the forum, ProcessWire will not output anything automatically. It will only output what you tell it to. Usually that is HTML (websites), but you could also use it to output PDFs or an API or whatever. You tell it what to output in so called template files. So for the template "events" it would call /site/templates/events.php, for example. In that template file, you would then place something like this to show children of your events page: <ul> <?php foreach($page->children as $event) { echo "<li>{$event->title}</li>"; } ?> </ul> This would output an unordered list (<ul>) of events. Then you could add links to directly view those event pages: echo "<li><a href='{$event->url}'>{$event->title}</a></li>";

I like both suggestions a lot 🙂 So a final question would be where to show it if all language tabs are expanded. I'd probably hide it then?

Looking at that mockup again I was a little confused... I think it should better say "clear content in all languages" ?

Ok great we have some positive feedback from ryan as well. He'd be willing to improve that detail in the core as well: Didn't think about the page render option before... What do you guys think? At first I thought it might be exactly one would need, but it might also be exactly the opposite. Maybe someone wants to have the default value blank, but other language values non-blank. Didn't have a good example for that, but I think I have one: What if we are on a website that shows events taking place in Vienna. The default language of the website is german. So for the german version of the website it's just showing the event title and details. But for the non-german website it might show "this event will be in german". Ok thinking about it further I'd probably add a select field then on each event to choose the language and then add that logic to the template code. Anyhow. Wanted to mention that and wanted to provide ryan with some good suggestions that he can easily add to the core. Happy about your input

Hey @FireWire This is what I had written so far: But then things didn't work the way I planned 🙈 I invested several hours in your reports this week. Managing existing recurrences is really not that easy, unfortunately. I even encountered an error with google calendar again while testing this week. Initially I thought I'd add this and have some great content for my monthly newsletter... But here we are. 3rd of April and no newsletter yet... I'm working on the RRule issue though and hopefully have some news soon!

Ah, thx, just replied on that pm and didn't see this message. Please try the version that I sent you and let me know if that fixes it. If not we'll have to find another solution.

It looks like your autoload module is not autoloading 😉 Maybe you changed the "autoload" prop to true after installing the module? Then you need a modules refresh to make sure ProcessWire recognises that change and loads your module on every request. Just set "forceIsLocal" of tracy to true and you'll have tracydebugger enabled even for guest users. This is what I'm using in all my projects in my config-local.php: // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => getenv("TRACY_LOCALROOTPATH"), 'numLogEntries' => 100, // for RockMigrations 'editor' => 'windsurf://file/%file:%line', ];

Ah sorry didn't see you are trying it from within a module. The hook that I shared should work there as well. Your module needs to be an autoload module. So I'd do this: add my hook in /site/templates/admin.php and check if it works add my hook in /site/templates/ready.php - it should work as well add my hook in your module's init() method - it should work as well If it doesn't work place a " bd('fired') " or whatever in your module's init() method and check if that dump shows up on the login screen. If not, then your init() is not triggered on that pageload.

It depends on where exactly. Or what exactly you want to modify. All backend requests call /site/templates/admin.php, so you can do something like this there (BEFORE the final require statement): wire()->addHookAfter('ProcessLogin::execute', function ($event) { $event->return = 'before' . $event->return . 'after'; }); edit: oh, and you can add scripts/styles there as well: $url = rockfrontend()->url(__DIR__ . '/admin.js', true); wire()->config->scripts->add($url); /** @var Config $config */ require($config->paths->core . "admin.php");

Thx @Stefanowitsch I understand. I've just added that to v6.4.0 Docs are on the module config screen:

Can you send me your invoice number / mail address via PM please?

I'm not using SCSS so I din't think of that. But it would not be hard to do I guess. Why would that help? Isn't it just creating a new file? Or should it have some prepopulated code?

@Jochen Fritsch the current version is v6.3.1, can you confirm you are talking about v5.2.0 which is from 02/2024? https://www.baumrock.com/en/releases/rockpagebuilder/ ProcessWire 3.0.229 is also not the recent version. So are you talking about an old project that has been working before or is that a new install? You might watch out for errors in the console and you might hit a max_input_vars limit on pages that have many many blocks/items/fields. One huge advantage of editing blocks on the frontend is that it will only ever load one block with a hand full of fields. On the backend all fields have to be loaded, which might cause issues (though I never hit any limit myself).

Do you have v1.4.1 ? This issue has been fixed 2 days ago: https://github.com/baumrock/RockDevTools/issues/3

Great, yeah sounds like a good solution. The title field is often special with its global flag so this is very good to have as a reference, thx for sharing!