FireWire

@bernhard Found the culprit. RockMigrations is not compatible with WireCache: Filesystem. If both are installed it causes migrations to run on every PHP request that ProcessWire handles and may cause the UI to hang in certain instances. I disabled filesystem cache but given it's speed it would be great if that compatibility could be made. Possible? Found this a bit ago but I forgot to hit the submit reply button 🤷‍♂️

Having an issue where RockMigrations is running constantly, every 2-5 seconds from the looks of it. The log says "detected changes in migrate.php" but I didn't make any changes. I commented out everything in migrate.php and it continues to happen. It also said that it detected change in two RPB block PHP fields that didn't have any changes, so I deleted thos but no dice. I don't know where to start debugging. I disabled migrations in the module config and RockMigration continues to run and logs "Migrations disabled via module settings'. I've closed every tab but one and Tracy continues to show new log entries for RockMigrations so it appears that migrations are running on every request that ProcessWire handles, even when loading one page. I've upgraded RockMigrations, RockFrontEnd, RockPageBuilder in case there were any conflicts in versions. Any insights?

I had to review my code a bit to see what I meant. Bad job formulating that question... can confirm that my brain is soup. I needed to get the value of addClass. When I create the custom fields I'm setting a value for 'addClass' and while I can loop through the custom field to get names/values I couldn't access an underlying field object to get to the class string. It ended up being complex but I think that's because of how the data is stored for the child fields. Here's the loop I put together where the subfield had to be accessed separately to get the value set by 'addClass', using that chain I noted above was just because it was in this context. <?php foreach ($customField->defs()->getInputfields()->children() as $subField) { $subField->class; // Provides the class that I added when configuring the child field // Skip this field if it has X class assigned $subField->value; // Doesn't provide the value $page->{$customField->name}->{$subfieldDef->_custom_property_name}; // Used this to get the value because it was accessible here } // Looping this way looped over the 'data' property of the CustomField object foreach ($customField as $subfield) { $subfield; // Not a field object so no value or class property } So it was a workaround because I couldn't iterate over the child fields as if they were normal fields.

@ryan Is there a way to make the custom field children iterable? I have a script that loops through a couple of fieldtypes on a page where I don't know the names of the custom field children at runtime. My solution requires a little digging to access the '_custom_property_name' by drilling down into $customFields->defs()->getInputfields()->children() then looping through the subfield defs and accessing the value using $page->{$customField->name}->{$subfieldDef->_custom_property_name} I might be missing a better way to do that. I'm coding so much that my brain is going to melt and might have missed the right way to do it.

Safe travels!

New FormBuilderHtmx release. Version 1.0.1 is recommended for all users. Bugfixes and new features, read more on the FormBuilderHtmx module page. Cheers!

Just load everything into Redis and hope the server never restarts. Blazing fast performance fueled by hopes and prayers ⚡ 🙏 🔥 😭

How cool? REALLY COOL. My next project needs a calendar and this is going to save the day. I'd like to buy you a beer, or six. Hell, you can have an entire keg 🍻

@bernhard I can't tell you how unreasonably excited I am for this module.

@bernhard This is an amazing undertaking and truly appreciated! I started planning a calendar module a few months ago but just couldn't afford the time to implement it. I think the interface you designed is a great direction. I'm 100% willing to be a guinea pig and help test if it helps. This is definitely a tough one. I could see being hesitant to rely on a third party service to pull this information but the complexity of region and tracking dates might make managing it locally a real beast. Third party service eliminates the need to create complex rrules by just updating holidays locally according to up to date information. Maybe using a service to pull data for current year +/- x number of years and on demand or annually beyond that. Free service, queryable by region and year: https://date.nager.at/Api

This looks fantastic. I'm at my computer right now working on a ProcessWire site, hop over to the forums, see this, immediately useful. Awesome work, thanks!

@BitPoet Great module! Just saved me time and was exactly what I was looking for. The one thing I ran into is that if a child page with a single-template child restriction is set to hidden then it's still possible to select that template when creating a new page. My use case is a settings page that is published but hidden. I tested the changes made in this Github PR and it resolves the issue. Thanks again for the module!

@bernhard Oh heck yeah!!! That's going to be a gamechanger for me and really appreciate it!

While working with RPB I have started to modify the stubs in the /modules/RockPageBuilder/stubs directory because, while the advanced block stub has been great, I realized that there is a lot of boilerplate that evolves into projects and I found myself consistently having to copy/paste contents from existing blocks to new blocks when created. I've been editing the stubs in the RPB module directory but have to be sure that I re-copy my custom stubs after upgrading the module. Perhaps there could be an option to "Publish Block Stubs" on the module configuration page. It could create a /templates/RockPageBuilder/stubs directory where the default stub files could be copied to and would be used for creating new blocks when they exist. I've created several support classes/objects that help with speed and consistency when working with blocks and having have new blocks created from customized files would be super awesome. Inspired by Laravel's publish stubs feature ?

I only build websites in black and white. Color is a paid extra.

@Stefanowitsch many thanks for sharing your solution, really helped me out. I modified it a little when implementing. Does the same job but may be a little more optimized. <?php $wire->addHookBefore('Pages::saveReady', function($event) { // ...rest of code here $page->block_search_cache = $index; // By hooking before the saveReady event it's possible to set the search cache field value without calling an extra page save // $page->save(['noHooks' => true]); }); Worked for me and just thought to share. Thanks again!

@virtualgadjo I was able to find a similar conversation on a RPB module support thread and put something together. I did take an idea from you using the Pages::saveReady event rather than the Pages::saved event in that example which I like better. Same setup with the extra field as you have done. In case this helps anyone else, here's what I came up with. It may be useful outside of the context of RockPageBuilder where field types matter. /** * Adds any content in RockPageBuilder field blocks to the dedicated indexable search_engine_block * field that it then added to the search index */ $wire->addHookBefore('Pages::saveReady', function($event) { $page = $event->arguments(0); // Get only RPB fields if they exist $rpbFields = array_filter($page->fields->getArray(), function(Field $field) { return $field->type instanceof FieldTypeRockPageBuilder; }); if (!$rpbFields) { return; } // Map RPB fields with values from getSearchIndexValues method if it exists on the child block $indexableContent = array_map(function(Field $rpbField) use ($page) { $blocks = $page->getFormatted($rpbField->name)->getArray(); // Merge content for each block within a field into a single array return array_reduce($blocks, function($values, $block) { if (!method_exists($block, 'getSearchIndexValues')) { return $values; } return $values = [...$values, ...$block->getSearchIndexValues()]; }, []); }, $rpbFields); // Flatten array of arrays containing index-prepared content $indexableContent = array_merge(...$indexableContent); if ($indexableContent) { // This is where it may be improved to make use of a SearchEngine method $page->search_index_blocks = implode(' ... ', $indexableContent); } }); The last comment is right above where I think it would be useful to see if there's a way to make use of the SearchEngine object to index content. My implode() method is mimicking the format of the search_index field with ' ... ' but deferring that rather than mimicking it would be great. It's not a dealbreaker but it would help keep my code from knowing too much about how SearchEngine works internally. Thanks @virtualgadjo for sharing!

This is really great and I appreciate the module and the approach! Question: Is it possible to manually add content that should be indexed? My use case is fields that exist within RockPageBuilder and I'd like to update the index with field content using a hook. Thanks!

@bernhard I think you make a really good point and I could see myself using either sorting by name or folder for different projects. 100% agree on the backwards compatibility issue as well. I see the value in having it both ways and a setting would be really great!

@bernhardUnfortunately not yet, I have been jumping around on projects and haven't come back to it haha.

Made a tweak in the module that has helped, maybe a feature suggestion? ? I have two icon sets/folders that I'm using in folders called "material-icons" and "extras". The "extras" folder contain one-off icons that supplements material icons when needed. When selecting icons they are in order of the folder name which caused the 'X' social network in the "extras" folder to appear before icons with names beginning with 'a' in "material-icons". I added a little bit of code to sort by the name separate from their collection/namespace on line 34 when the values are rendered: <?php class InputfieldRockIcons extends InputfieldText implements InputfieldHasTextValue { // ... /** * Render the Inputfield * @return string */ public function ___render() { $module = rockicons(); // Added sorting by key/name $availableIcons = $module->icons(); uksort($availableIcons, fn ($a, $b) => explode(':', $a)[1] <=> explode(':', $b)[1]); // prepare icons $icons = ""; foreach ($availableIcons as $name => $path) { $selected = ($name == $this->value) ? "selected" : ""; // ... } // ... } Quick fix and the results feel more natural. RockIcons is another great module of yours I can't live without. Thanks for all of your hard work!

@bernhard I took a quick look and understand what you mean. Thanks!

@bernhard I've only experienced this when creating migrations inside block PHP files for RPB. I haven't looked but would there be something inside RockPageBuilder that filters block migrations before they're handled by RockMigrations?

Can I get access to the repo? Can't guarantee I can tackle this right now, but when I can I'd be happy to work on it!

Found something that may be of help to others. I have a RPB block that has a basic repeater field and uses a block migration. Rather than writing the migrations by hand, I've been copying RockMigrations code from fields to help make short work of writing migrations in block files. Example: Running migrations ended up causing a system template to be created every time modules were refreshed: I found the culprit in the block migration: <?php $rm->migrate([ 'fields' => [ 'listItems' => [ 'label' => 'List Items', 'type' => 'FieldtypeRepeater', 'fields' => [ 0 => 'text', ], 'template_id' => 0, // Potentially causes duplicate template creation 'parent_id' => 0, // Potentially causes duplicate template creation // ... ], ], // ... ]); Removing those two migration properties for that field resolved the issue. I'm not sure if this has any effect on other block migration field types since I haven't created too many in this project yet, but something to keep in mind when using the migration code output from an edit field page. @bernhard Is this something that an update in blocks where migration arrays could be "sanitized" to remove any properties that would conflict with how RPB needs fields to be created? Thanks for your work as always @bernhard!