RockMigrations 🚀🔥 The Ultimate Automation and Deployment-Tool for ProcessWire

[bernhard]

RockMigrations v5.1.0

• The automatic detection of the php version/command on the remote when using deployments has been further improved and some issues have been fixed.
• Breaking Change: We now share the sessions folder by default on deployment. If you don't use RM deployments there is no breaking change and you can simply update.
• Another fix for deployments: We now use a timestamp like release-20240801220000-12345 because github deploy ids jumped from 999... to 1000... which broke the folder rename operation of deployments.
• Added automatic modules refresh on $rm->installModule(); Before this change I sometimes had the situation that I had to do a manual modules::refresh on my remote after pushing a new version that installed a new module. This is not the case any more ?
• You can now (again, as this has been there before but was removed in the last release) define the remote PHP command in your deploy yaml file if the automatic detection should not work for whatever reason. Simply add something like PHP_COMMAND: /path/to/your/php_binary_81
• Added getTemplateIds() method that can be handy when PW wants template ids but you want to define that in a human readable way like $foo->bar($rm->getTemplateIds(['home', 'basic-page']));

[Sanyaissues]

On 7/24/2024 at 2:58 AM, bernhard said:

In the module settings you have a checkbox to copy snippets over to /your/project/.vscode and that should make VSCode recognise the snippets and show suggestions once you type "rmf-" etc

Thanks @bernhard! rmf- suggestions are working for me. But I cannot find a way to see methods as createPage, deleteField as you do in your video. If you can point me in the right direction I would appreciate it.
 

Spoiler

From your video (sorry the quality).




My VSCode.

 
 

 

[bernhard]

I'm using https://intelephense.com/ and paid for it as it is so useful, but the free version is great as well!

[Sanyaissues]

Seems like after updating the DDEV instance some extensions were removed from the container, after reinstalling intelephense the methods are working. Thanks!

[bernhard]

RockMigrations v5.2.0

• Added a snippet for the RockIcons module/fields.
• Added a deprecation note for Magic Field Methods. This feature has been moved to RockFrontend, because the way I implemented it to RockMigrations was not ideal. It added a hook for every existing field, which was something I wanted to change for a long time. But as I didn't see any noticable performance penalties it didn't happen until recently 😎
  If you have been using magic field methods be sure to update RockFrontend to the latest version and refactor your code until you don't get any deprecation notices in your logs! Logs will be shown in the "magic-pages" log and will even have a notice how to fix it:

[FireWire]

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?

[bernhard]

Are your time settings correct? Maybe filemtime produces a wrong result or maybe time(). Those are compared and if one is wrong it could think the file changed

[FireWire]

@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 🤷‍♂️

[bernhard]

@FireWire glad you found the issue. Could you please open a new thread for this and explain the benefits of filesystem cache and how you are using it? Then we can discuss there in an isolated environment which makes it easier to reply, link, refer to... Please also explain your use case as I've never used filesystem cache.

[bernhard]

RockMigrations v5.3.0

• Added an automatic Modules::refresh() before executing $rm->installModule()
• Added GET_PHP_COMMAND for deployments as requested by @snck
• Added docs for the great filesOnDemand feature

[bernhard]

We always have to deal with exceptions, right?

I'm always using the $rm->setPageNameFromTitle() helper that will update the pagename according to the page title on save. That's easy to do in a MagicPage:

  public function init(): void
  {
    $rm = rockmigrations();
    $rm->setPageNameFromTitle($this);
  }

But what if we wanted to make sure that one page has a custom page name that can't be changed, so that we can rely on the url eg in a fetch() call?

  public function onSaveReady(): void
  {
    if ($this->id === 6840) $this->name = 'versandkosten';
    else rockmigrations()->setPageNameFromTitle($this);
  }

We have to use the magic "onSaveReady()" method, because in init() and in ready() we cannot use $this to access the current page, because init() and ready() are triggered on a NullPage object and not the page itself. The reason for this is interesting but not for this post 🙂 

[bernhard]

RockMigrations v5.5.0

• Added PR #65 from lemachinarbo that improves the moduleInstall command; Thank you! 🚀
• Added support for config migrations: See docs
  This update is extremely helpful and from now on the recommended way to write migrations, as this workflow makes circular references a problem of the past! 🥳💪
• Added docs about automated releases

[bernhard]

RockMigrations v6.0.0

I'm really sorry, but I had to introduce a breaking change if anybody already adopted the new config migrations. It's unlikely, because this addition was only 10 days old, but I bumped to v6.0.0 to be safe.

If you have not yet used config migrations you can just update without issues.

[FireWire]

@bernhard I was experimenting with them and was having trouble getting them to work, it didn't seem like the changes were being detected, I figured it was a problem with my usage. Was the change a fix or an improvement?

[bernhard]

Actually none of both. I just changed how fields created by RM can be referenced as class constants. Before it was like this:

RockCommerceFields::myfield

Now it is like this:

RockCommerce::field_myfield

[bernhard]

I've been working to improve the deployments feature. As a result I changed a small detail in v6.3.0 that might break your deployment pipeline.

If you are seeing this error:

Quote

Could not open input file: .../tmp-release-2024.../site/modules/RockMigrations/deploy.php

You can either update RockMigrations or, if that is not possible, make your workflow use the old version of the deployment:

Quote

uses: baumrock/RockMigrations/.github/workflows/deploy.yaml@v6.2.0

 

[FireWire]

@bernhard Just a friendly note to say how much RM has been a gamechanger for me. Started out with adopting it in RockPageBuilder but now I'm installing it on older sites that I am coming back to add features to simply for the speed and ease it provides when managing new fields. Bravo and thanks for the great module 🙌

[bernhard]

Hey @FireWire thanks for letting me know! Really great to hear 🙂 

Be sure to check out the new config migrations!!! They are a gamechanger in the gamechanger 😛 I've just updated the docs! https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/config-migrations/

v6.5.0 is out now 😎

[FireWire]

@bernhard Many thanks! 🙏

[Jonathan Lahijani]

@bernhard How do RM's config migrations work when it comes to creating pages, since it doesn't support page creation?

So let's say I wanted to create /colors/ with child pages red, green and blue.  I would have:

• /site/RockMigrations/templates/colors.php
• /site/RockMigrations/templates/color.php
• /site/RockMigrations/fields/color.php

To make the 'color' single-select page field use /colors/ as a parent page and 'color' as a template, the /colors/ page needs to be created using the 'colors' template and red/green/blue need to be created with the 'color' template.  Where would the code go for creating those pages if now the code for fields and templates are done in the new "config migrations" way?

[bernhard]

1 minute ago, Jonathan Lahijani said:

since it doesn't support page creation?

Not yet. PRs welcome.

2 minutes ago, Jonathan Lahijani said:

Where would the code go for creating those pages if now the code for fields and templates are done in the new "config migrations" way??

Wherever you want. Nothing changed here. You can put it in /site/migrate.php, you can put it in your /site/modules/Site/Site.module.php module's migrate() method, etc...

[bernhard]

@FireWire @Jonathan Lahijani @gebeer

I've created a demo module that shows how to use the new config migrations. Please note that it needs the latest RockMigrations version from the dev branch!

https://github.com/baumrock/ConfigMigrationsDemo