FireWire

@ryangorley No problem and no worries. The info here may always help someone else!

@ryangorley I'll leave that response up in case it helps anyone else but I just took a look at the DeepL website source code and it shows that it translates into Traditional Chinese which is ISO code zh-Hant, but the API is returning zh-Hans which Simplified Traditional Chinese. I think this may be where the disparity may be coming from. Here's the HTML used on their home page translation tool. They are providing full Traditional Chinese translation via the web, but not via the API (no idea why) <div data-testid="translator-target-lang" dl-selected-lang="zh-Hant" class="mobile:hidden truncate">Chinese (traditional)</div> So your best bet is to use zh-Hans in Fluency as that's the closest they offer via the API. I jumped onto an installation of Fluency on my own to check that out but jumped the gun with the translation cache reply...

@ryangorley Got you covered. There are no hard-coded languages in Fluency but getting the translatable languages involves an API call that can slow some things down during regular module use. Fluency caches available languages until cleared when you need to refresh the list, as in your case. Head over to the Fluency module config and scroll down to "Fluency Options" then nuke the translatable languages cache. Once you reload the page Fluency will retrieve and re-cache all of the latest language data and you should be good to go. Click button to light fuse, then run for cover:

@bernhard Using latte causes all stack traces to disappear. I'm getting unhelpful messages and no exception logging. I've tried to add an exception handler using a RockFrontend hook, but no dice. Getting some single line messages that aren't useful. Using Latte's {trace} at the top of a file rendered this: Attempting to hook and manually throw a WireException doesn't work. The hook is firing, but Latte is not responding to the example I took from the documentation. Any experience with this?

@SIERRA Hey there- I missed this because I wasn't tagged and it wasn't posted under the Fluency support thread. That message indicates that the Fluency module attempted to connect to the translation service API but was not able to get a response, or there was an unexpected response from Google. Can you check the entries in Setup > Logs > fluency-engine and see if there are any details you can share? Fluency requires that curl be installed to make API calls, can you confirm that it's configured on your server?

@JayGee I caught that bug in a project I'm working on right now and forgot to update the repo! Just pushed 1.0.1. You should be able to refresh your modules and see the upgrade. Let me know if that doesn't fix the issue.

So this is actually something I cooked up to "mark" certain subfields within the custom field and pretty much the entire cause of this approach I took. Your include tip is pretty ingenious, I never would have thought of that. These are good tips. As for the use case of addClass, it's definitely a hacky method of attaching some additional data to each subfield. I have a Pages::saveReady hook that loops through groups of fields on the page and creates a supplemental index field for the SearchEngine module. It's only necessary for fields that aren't compatible with the module out of the box. I needed a way to indicate which subfields of custom fields shouldn't be added to the search index so in the custom field config I added 'input:nosearchindex'. It's just a workaround to indicate which fields should be excluded at configuration but which wouldn't be known at runtime. Really appreciate the response, very helpful!

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