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 :-)

Hi @bernhard, The current Rockfrontend Docs talk about a favicon field that gets added if RockMigrations is installed (https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/seo/#favicon-and-og-image) In the code, I do not find any migration that installs that field. In the module code at https://github.com/baumrock/RockFrontend/blob/2c1570656bd0152f9927f03144d334eff5c8d4de/RockFrontend.module.php#L3346 it says Use [realfavicongenerator](https://realfavicongenerator.net/) to add a favicon to your site. Are the current docs this still valid? Since I don't have the favicon field despite RockMigrations being installed when I installed RockFrontend, I assume that functionality does not exist anymore? Could you please clarify. Thank you. Also In module settings, I get But there currently is no favicon.ico file in the root. If I change the check in https://github.com/baumrock/RockFrontend/blob/2c1570656bd0152f9927f03144d334eff5c8d4de/RockFrontend.module.php#L3335 to $hasFavicon = $http->status( $this->wire->pages->get(1)->httpUrl() . "favicon.ico" ) === 200; the detection works.

Thank you for joining. I agree, RockCommerce looks promising and gives developers lots of freedom on how to implement things. Just the way PW devs love it :-)

Thank you for updating the actions in both scripts!

The one I had linked to which is the official github checkout action is not deprecated https://github.com/actions/checkout and in active development. Could you provide the link to the deprecated version? EDIT: Ah, I see https://github.com/baumrock/RockMigrations/blob/main/.github/workflows/auto-release.yml uses the actions/checkout@v4 :-) So in our local main.yaml we need to use jobs: deploy-to-production: uses: baumrock/RockMigrations/.github/workflows/auto-release.yaml@main // instead of deploy.yaml Could you please confirm?

I think you need to update to action/checkout@v4. Looking at their changelog https://github.com/actions/checkout/blob/main/CHANGELOG.md they updated to Node 20 in v.4.0.0. That should take care of the problem. Alternatively, if you, for some reason, must stay on v3, you can set an env var FORCE_JAVASCRIPT_ACTIONS_TO_NODE20=true But I would try to avoid that because of https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/#removal-of-operating-system-support-for-non-node20-os-versions Hope that helps :-)

Hi @bernhard we just ran into some error with the deployment script: The following actions use a deprecated Node.js version and will be forced to run on node20: actions/checkout@v3. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/ Seems related to the action in use: uses: actions/checkout@v3

Hi @bernhard, I just installed RockSettings for the first time on PW 3.0.210. The project is still using CKEditor. So I got warnings for the TinyMCE fields that got installed through the RockSettings migration. So I need to override those. I'm doing this in site/migrate.php /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); $rm->watch(__FILE__, 0); // note priority set to 0 to execute before /site/modules/RockSettings/pageClasses/SettingsPage.php which has priority 1 $rm->migrate([ 'fields' => [], 'templates' => [ 'rocksettings' => [ 'fields' => [ 'title' => [ 'collapsed' => 4, ], 'rocksettings_contact' => [ 'collapsed' => Inputfield::collapsedNo, 'inputfieldClass' => 'InputfieldCKEditor', ], ... The migration takes no effect, because /site/modules/RockSettings/pageClasses/SettingsPage.php has priority 1 and site/migrate always has 9999, no matter what I set in the watch call. So the RockSettings migration always overrides my mygration in site/migrate.php Here's the CLI output with $rm->watch(__FILE__, 0); ddev exec php site/modules/RockMigrations/migrate.php Refresh modules ##### SORTED WATCHLIST ##### Array ( [#9999] => Array ( [0] => /var/www/html/site/migrate.php ) [#1] => Array ( [0] => /var/www/html/site/modules/RockSettings/pageClasses/SettingsPage.php ) ) ### Migrate items with priority #9999 ### Watchfile: /site/migrate.php Load /var/www/html/site/migrate.php ### Migrate items with priority #1 ### Watchfile: /site/modules/RockSettings/pageClasses/SettingsPage.php => RockSettings\SettingsPage::migrate() --- Trigger RockMigrations::migrationsDone This specific to site/migrate.php After moving my migrations to site/modules/Site.module.php, the priority is recognized ddev exec php site/modules/RockMigrations/migrate.php Refresh modules ##### SORTED WATCHLIST ##### Array ( [#1] => Array ( [0] => /var/www/html/site/modules/RockSettings/pageClasses/SettingsPage.php [1] => /var/www/html/site/modules/Site/Site.module.php ) ) ### Migrate items with priority #1 ### Watchfile: /site/modules/RockSettings/pageClasses/SettingsPage.php => RockSettings\SettingsPage::migrate() Watchfile: /site/modules/Site/Site.module.php ----- Migrate Module Site ----- Migrate Site --- Trigger RockMigrations::migrationsDone Also after moving the migrations to Site::migrateSettingsPage like mentioned in the docs. BTW the docs are currently not linked on https://www.baumrock.com/en/processwire/modules/rocksettings But even if tmy migration is run after the RockSettingsPage one, the 'inputfieldClass' => 'InputfieldCKEditor', takes no effect. If I set it manually via GUI, it gets reset to InputfieldTinyMCE after next migration. This is because inputfieldClass can't be overriden in template context. Before installing the TinyMCE fields in your RockSettingsPage, you could check if the module is available. If not, use InputfieldCKEditor. That would be great. I have sent you the adjusted site/modules/RockSettings/pageClasses/SettingsPage.php

Great hint, thank you. My logic for getting the block now looks like /** @var FieldData $blocks */ $blocks = $page->rockpagebuilder_blocks; /** @var Block $contactformBlock */ $contactformBlock = $blocks->get('type=ContactForm, _mxhidden=0'); This gets only non-hidden blocks which is perfect for my use case.

Indeed, I do. And I'd be very interested to try your module

Yes, that is correct. I would like to handle this through the block's status, if possible. Since Block inherits from Page that should be possible? Something like $contactformBlock = $blocks->get('type=ContactForm, status!=unpublished'); But: When I hide the block, I get $contactForm->status = 1 When I unhide it, I get same status 1. Looking at the RockPageBuilderBlocks pages in the page tree, they don't seem to have a regular Page status So status in Blocks seems to be handled differently from Page status. Is there already a selector that we could use for finding only unhidden blocks?