gebeer

This is not native. It is a field definition for a custom field 'langs' that lets you choose one or more language. The array format of the field definition that I posted is used in the @bernhard's fabulous RokMigrations module but you can define the field manually via GUI, too, if you prefer so.

In one of my projects I have a separate field 'langs' that editors can check. Definition (for RockMigrations): 'langs' => [ 'label' => 'Languages', 'tags' => 'general', 'flags' => 0, 'type' => 'FieldtypePage', 'derefAsPage' => 0, 'inputfield' => 'InputfieldCheckboxes', 'parent_id' => '', 'labelFieldName' => 'title', 'optionColumns' => 1, 'template_id' => 'language', ], So it is a page reference field that gives you checkboxes for each language. You could then use the value of this field in your logic for the language switch.

Solved. It was indeed a problem with our setup, not with renderLayout().

Hi @bernhard we just updated RockFrontend on a site from 3.20.0 to 3.23.3 and the site stopped working. I fixed it by changing templates/_main.php <?= $rockfrontend->renderLayout($page); // worked before update ?> <?= $rockfrontend->render($page); // works after update ?> We use RockPageBuilder and in templates/sections/main.latte <div sortable x-ref="additional-sections"> {$page->get('rockpagebuilder_blocks')->render()|noescape} </div> Now after the update that threw an error on our home page because template home has no field rockpagebuilder_blocks I am wondering why this is. Do you have any idea? I looked at the function signature for render() and the examples in the PHPDoc do not mention that we can pass a Page object as $path argument. So I thought we could not call render($page) at all. But it works. I guess because $page is then overwritten with $this->wire->page. So renderLayout($page) would be the correct method to use. But something in the inner workings of renderLayout must have changed and stopped the site from working. I suspect that the way we have setup rendering with RockPageBuilder, RockFrontend and Latte is fundamentally wrong.

@FireWiresorry, I totally did not see AsmSelect in the list albeit it being the very first item. Strange things happen sometimes...

If you leave active checked, it will automatically fall back to the default language. This behavior is the default behavior. You can change that behavior per language field in the Details tab

The list of currently supported inputfield types under heading "Possible values for “type”" at https://processwire.com/blog/posts/custom-fields-module/ does not list AsmSelect which you chose for your page field (multiple) based on the screenshots. Maybe this is the issue? Have you tried field type SelectMultiple instead of AsmSelect?

That is great news. I've been using Supermaven in Cursor for the past 4 months with deactivated Cursor Tab feature. IMO Supermaven works way faster and more intelligent than Cursor Tab. So I really appreciate them integrating it into Cursor.

Good to know. Thanks for the heads up.

@bernhardwe just tested it with 2 deployments after module upgrade and it seems to work fine. Thank you again!

Wow, that was quick. Thank you. We will update and report back here if problem is solved.

Hi @bernhard we are experiencing a problem with the path to the icons folder in RockIcons. After running deployments the path changes and icons cannot be displayed anymore in the frontend because RockIcons is looking for them in a wrong path. I suspect that the full absolute path to the icons folder is stored and used in the RockIcons module. Now when we run a deployment, the actual folder where the icons lived before does not exist anymore because it is replaced by a new one for the new deployment. That new folder is symlinked to the "current" folder. But somehow the old folder path is still in the system. After a modules refresh, the path is updated and icons are displayed again. That is why I opened But I think it would be a cleaner solution to fix this in RockIcons.

Hi @bernhard can we trigger a modules refresh with https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/deployments/#hooks ? How would I call wire()->modules->refresh correctly in a $deploy->after hook?

Done

Thank you for clarifying :-)