Leaderboard

Thanks for your answer. To clarify, I don't want to get pages with empty values, nor do I have a problem with finding what I need. I'm curious why a blank search query produces non-blank results. I might post this question on GitHub later.

Story of my/our lives. HA. Thank you for your work on this, it looks great and the syntax is very nice. Excellent work 🙌

No, it's deftly that particular page, just sitting in the page tree like many others. It is, by the way, the first page in the page tree with an item_number (the pages above have empty item_number values).

above i wrote "Even when i removed the Config Migrations files for these repeater fields these repeater fields have "doubles" in the template fields" i.e. i couldn't reproduce this effect (new repeater-field rows when repeater-field Config-Migrations file is moved away. But: a repeater field Config - Migrations file produces to an improper database when refreshing modules is clicked

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! 🙂

working! thank you

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; }

@bernhard Maybe I should mark this post as "solved" 😆

@bernhard Of course you thought of this... I need to go back and read the docs more ha! I completely missed that. Everyone save yourself the trouble and RTFM 🤣

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!

Yes, please. The LazyCronLock.cache means there was an issue and LazyCron was stopped. You can safely delete both files in your DEV environment. Take a look at them. There are just timestamps in them, so LazyCron can check on those. Using ready.php was for testing purposes only. LazyCron will work from within a module. I use that a lot for maintenance tasks.

@Ahmad This module has a problem in the AllInOneMinify.module file ... When you go to the processwire installation directory and site\modules\AllInOneMinify/AllInOneMinify.module And change this code from the line 713: foreach ($files as $file) { $_timestamp = ($_timestamp + $file['last_modified']); } Change to : foreach ($files as $file) { $_timestamp = ($file['last_modified']); } I only deleted the variable " $_timestamp + " and it worked ... But I do not know if it will have any later consequences ... In addition, you should install a great debugging module that will help you find problems with the name Tracy Debugger