bernhard

Hey @hellerdruck thx for your purchase and sorry for the trouble. I can't see your image unfortunately. Can you please upload it again and make sure it's visible?

Ok not exactly an hour - took a bit longer than expected... as always 🙈😅 Here you go: Please grab v5.11.0 here https://www.baumrock.com/en/releases/rockpagebuilder/ And RTFM check out the docs here: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/settings/#adding-settings-globally Thx for the idea! Enjoy! 🙂

Sorry I don't understand.

Thx. Please share exactly which field names you used and which db entries it created. That might save time when trying to duplicate it.

Give me an hour before you start refactoring... 😉

Ok nice. Just wanted to make sure I understand exactly why you are not using the available approach. But I like your idea. I'm thinking maybe RPB could load a file like /site/templates/RockPageBuilder/blocksettings.php like this: <?php return [ 'foo' => [ ... ], 'bar' => [ ... ], 'baz' => [ ... ], ]; Which would make it then possible to set block settings like this: <?php public function settingsTable(RockFieldsField $field) { $settings = $this->getDefaultSettings(); $settings ->add('foo') ->add('baz'); return $settings; }

Hey @thei thx for the report. Could you please provide steps to reproduce this issue so that I can investigate? Or even better do you have time to find a fix for it?

Hey @FireWire thx for sharing! Are you aware of https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/settings/#adding-default-settings ? Nevertheless I see potential in your workflow!

@Spinbox what do you mean exactly? Could you give me more context?

I'm just very busy and hoped others would jump in. Something seems to be different depending on the type of save. Check out https://processwire.com/talk/topic/30827-how-to-build-a-hacky-hook-recorder/ and see if you see a difference in the log.

Oh, sorry, of course! 🙈 Thx @matjazp!

Congrats @ryan and thank you @matjazp for helping with all the github issues! Great achievement and great start into the new year 🚀🥳

Download + Docs: baumrock.com/RockLite

What exactly do you mean / did you do?

Hey @Christophe this has come up in the RockMoney thread already. You need to install/enable the Intl extension for PHP on your system. I have added a check for this that should throw a more helpful error message and I have added it to the docs about RockMoney!

Stunning! Thx for sharing!

I'm loving config migrations more and more 🥰 They reduce complexity and increase stability and performance. Win-Win! Wherever you want. Nothing changed here. You can put it in /site/migrate.php, you can put it in your /site/modules/Site/Site.module.php module's migrate() method, etc... I have to correct myself here @Jonathan Lahijani Today I had to create the following page reference field: <?php return [ 'type' => 'page', 'parent_id' => '/tags/', // ... ]; The "parent_id" setting caused a problem, because the /tags page did not exist when this was run, so the migration failed. I went ahead and implemented a way to properly, reliably and easily create new pages with your config migrations: MAY I INTRODUCE: Config Migration Hooks 😍 😎 🚀 Please check out the dedicated docs page, which are at the moment only on the dev branch and will soon be merged to main and then be also available on my website: https://github.com/baumrock/RockMigrations/tree/dev/docs/config-migrations-hooks

How many pages are we talking? I've just created 10k pages for a testrun and my script took 330ms with a chunksize setting of 100 and 46ms with a chunksize of 1000 Did you use my exact script implementation? It's not only about using findIDs... Details matter 😉

ProcessWire should soon be listed under the DDEV Quickstart List: List: https://ddev.readthedocs.io/en/stable/users/quickstart/ PR: https://github.com/ddev/ddev/pull/6879

@FireWire @Jonathan Lahijani @gebeer I've created a demo module that shows how to use the new config migrations. Please note that it needs the latest RockMigrations version from the dev branch! https://github.com/baumrock/ConfigMigrationsDemo

First thing to check is if your hook gets executed. For that put this at the very top of your hook: d('fired'); You should see these dumps in the console output when you foreach() and save() If you don't see it, your hook does not get triggered, which means you found the reason why the page name does not update.

Not yet. PRs welcome. Wherever you want. Nothing changed here. You can put it in /site/migrate.php, you can put it in your /site/modules/Site/Site.module.php module's migrate() method, etc...

Hey @FireWire thanks for letting me know! Really great to hear 🙂 Be sure to check out the new config migrations!!! They are a gamechanger in the gamechanger 😛 I've just updated the docs! https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/config-migrations/ v6.5.0 is out now 😎

Thx for sharing! Just wanted to mention that modals also support auto-close on save, see here:

Needed this today while working on RockGrid. Realised that the version above attaches an event listener for every created link but doesn't remove it later. So I improved this by listening on the "pw-modal-closed" event on the $link instead of the $(document). This didn't work at first, but I found out, that the culprit was that I instantly removed the $link after it has been clicked, so obviously there is no element any more to listen for the event. After moving the $link.remove() in the modal closed callback it worked as expected. Here is the updated function that I use in RockCalendar: const openInModal = (href, options = {}) => { // merge options with defaults const defaults = { calendar: false, autoclose: true, buttons: "button.ui-button[type=submit]", }; const opts = { ...defaults, ...options }; // create a fake link element in body let link = document.createElement("a"); let $link = $(link); $link.attr("href", href); $link.addClass("pw-modal rc-link-remove"); if (opts.autoclose) $link.attr("data-autoclose", ""); if (opts.buttons) $link.attr("data-buttons", opts.buttons); $link.on("click", pwModalOpenEvent); $link.on("pw-modal-closed", () => { if (opts.calendar) opts.calendar.refresh(); $link.remove(); }); $link.click(); }; A different approach is to add a second button (save + close) to the modal: