Jump to content

gebeer

Members
  • Posts

    1,481
  • Joined

  • Last visited

  • Days Won

    43

Everything posted by gebeer

  1. Hi there, why the heck would you want to migrate your migrations? Since v6 of RockMigrations there's a new feature called "config migrations" which you can read more about here. In a nutshell: instead of having an often lengthy migration function like $rm->migrate([ 'fields' => [...], 'templates' => [...] ]) with hundreds of lines in either site/migrations.php or site/modules/Site.module.php or other places, we can neatly organize our migration definitions into single files inside site/RockMigrations/fields and site/RockMigrations/templates (...roles, ...permissions). Where each file has the name of the field/template/role/permission and returns an array of settings. If you have module specific migrations, they go under /site/modules/MyModule/RockMigrations/(fields/templates/etc) This is absolutely wonderful for several reasons. Here's just a few that come to mind: clean structure smaller migration files easy to discover in explorer panel faster migrations because only migrations for changed files will fire portability across projects Because I immediately fell in love with this concept, I am currently updating migrations for all projects to the new structure. This can be a very tedious task. We could write a script (and maybe this is the ultimate solution). BUT since I'm lazy, I just commanded my favorite AI assistant to do the job for me. I did this in windsurf editor Write mode (Cascade), but you can also use cursor's composer for this. Let me share how I approached it. I created the directories "fields" and "templates" under site/RockMigrations. And one migration file each for a field and a template to have examples to pass to the AI. Then I copied the 'fields' array from above mentioned $rm->migrate(['fields => []]) (that was originally in my Site.module.php) and pasted it into the windsurf Cascade (or cursor composer) chat. Along with these instructions: For each item in this array do the following operations: 1. create file site/RockMigrations/fields/{array_key}.php 2. add namespace ProcessWire and return the array found under this {array_key} Mirror structure of @seo_fieldset.php Where @seo_fieldset.php is passing the contents of site/RockMigrations/fields/seo_fieldset.php as context to the AI. And here's what happened: windsurf Cascade decided to do the operation in batches. It would let me check the results after every 4 files or so and asked me if I wanted to continue with the next batch. After about 10 minutes all my 31 field migrations where refactored into the new structure and I was very happy following along while sipping away at my coffee :-) After that I did the same for the 'templates' array. Some considerations on why I chose this exact approach: I could have given the whole Site.module.php file as context and asked the AI to read the fields array from there. But that file is pretty large and the fields array alone was about 400 lines of code. And that might have exceeded the context window or at least confused the AI. I used the phrase "Mirror structure of ..." because I found that to be a very effective prompt whenever you want the assistant to write code based on an example. Actually I did not find that out by myself (I'm not that great of a prompt engineering genius). Got it from IndyDevDan over at YT. Highly recommended channel btw. To wrap things up, I can highly recommend switching to the new config migrations structure. So much cleaner. So much better. A big praise to @bernhard for coming up with this. Also praises to the developers over at cursor and codeium (windsurf) for these amazing tools. And, not to forget: Hail Claude!
  2. Thank you very much for the fix. I can confirm that Tracy s now working without the modification. I think, for larger corporate sites redirects that route from root to a specific language/market URI are not that unusual. So it is great that you made things work for those use cases.
  3. Awesome! What about RockMPP (RockMultiPurposePicker) or RockPickAnything? Or just RockPicker.
  4. We were experiencing a similar issues because the POST request now goes to / root instead of the current page loaded like before with ./ In our case the console result frame would load the homepage of the frontend instead of the actual results. I solved it for our case (a hook to PageView::execute on /) by returning if it is a tracy request $wire->addHookBefore("ProcessPageView::execute", function (HookEvent $event) { // do not redirect if tracy request if(isset($_POST['tracyConsole']) && $_POST['tracyConsole'] == 1) return; // alternative // if (isset($_SERVER['HTTP_X_TRACY_AJAX']) && $_SERVER['HTTP_X_TRACY_AJAX']) return; if ($_SERVER['REQUEST_URI'] === '/') { ... session()->redirect("{$lang}{$marketName}"); } We need that redirect to determine language and market based on a request to GeoApify API. I think that others might potentially run into this as well. So if the change of xmlhttp.open("POST", "./", true); to root / is not strictly necessary for Tracy to work, it might be better to revert that? @adrian
  5. 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.
  6. Ah, thank you. That make sense. Will prioritize my Site module migration so that the backup is created before the config migrations kick in.
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Solved. It was indeed a problem with our setup, not with renderLayout().
  13. 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.
  14. @FireWiresorry, I totally did not see AsmSelect in the list albeit it being the very first item. Strange things happen sometimes...
  15. 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
  16. 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?
  17. 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.
  18. @bernhardwe just tested it with 2 deployments after module upgrade and it seems to work fine. Thank you again!
  19. Wow, that was quick. Thank you. We will update and report back here if problem is solved.
  20. 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.
  21. 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?
  22. 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.
×
×
  • Create New...