gebeer

https://www.perplexity.ai/search/php-constants-naming-conventio-g4mLG8sbQyu34r4mGXmx6w Although the source for this is not php.net directly. I wanted to read up on that over there but php.net currently throws a 502 error. Anyways, that was just a side note. That explains why you never saw that error. But imo you should not assume that everybody uses underscores so I think, the renaming logic in my PR at https://github.com/baumrock/RockMigrations/pull/70/commits/a06c6062c61b5264932a8044cf25bac0c689f8cf should be implemented. Otherwise people who use hyphens in their template names would have to rename all their templates just to be able to use the RockMigrationsConstants magic.

Ah, thank you. That make sense. Will prioritize my Site module migration so that the backup is created before the config migrations kick in.

Hi @bernhard, I usually have a line in my Site module that does a DB backup before the migrations are running public function migrate() { // backup before migrations (not on ddev) if (strpos($this->config->httpHost, 'ddev') === false) $this->wire->database->backups()->backup(); ... I moved my migrations from the migrate method to the new phantastic config migration structure in site/RockMigrations. So much cleaner to have each field/template migration defined in a separate file :-) But: since the migrations now do not live in Site module, the DB backup is not being triggered because there are no changes to that file anymore. Long story short: Is there a setting in $config->rockmigrations that will do automatic backups befor each migration on the live server? Couldn't find anything related in the docs, the GH wiki or even searching the string "backup" in the RockMigrations module folder. Could this feature be added or how do handle this?

This solves only the first problem that I described. The error caused by hyphens in constant names still persists, even after switching to PHP8.3. Do you name all your templates with underscores like "basic_page" to avoid that? On a side note, after reading up on PHP constants, there seems to be a convention to name them in capital letters.

Hi @bernhard, I already fell in love with the new config migrations feature in RockMigrations > 6.0.0. I am currently on v6.0.1 So much cleaner to have migrations organized in this way. I just tried to implement the part about the constant traits, described at https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/config-migrations/#class-constant-traits First it would not work at all as described in the docs. I noticed that my file at site/modules/Site/RockMigrations/RockMigrationsConstants.php never got picked up because of searching for those files did not recurse into module subdirectries. Fixed in PR#70 commit https://github.com/baumrock/RockMigrations/pull/70/commits/faba5475a008ab14415c0e35f2c5c78d2e91f0b1. First problem: After fixing that, I get the Compile Error Traits cannot have constants Actually, constants are only allowed in Traits since PHP 8.2. So this would change the module dependencies from PHP>=8.0 to PHP>=8.2 I don't think this was intended. But it should be updated or at least documented that the automated constants thingy requires PHP>=8.2. Second problem: After upgrading to PHP8.2 I ran into the next issue: This is caused by the constant name "template_basic-page" containing a hyphen. As it seems, they are not allowed in constant names in PHP at all (https://www.php.net/manual/en/language.constants.php): For years I have naming conventions for templates and fields in PW. Template names always contain hyphens like in "basic-page". Field names always contain underscores like in "my_field". This is also helpful when looking at code to discern templates from fields on the first glance. I fixed this by replacing - with _ in constant names. See https://github.com/baumrock/RockMigrations/pull/70/commits/a06c6062c61b5264932a8044cf25bac0c689f8cf The issue with PHP8.2 still remains to be resolved. I suggest adding the requirement only to docs about RockMigrationsConstants.php because other than that RockMigrations seemed to work fine on 8.1 in my tests.

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!