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

[bernhard]

I just pushed an update to the DEV branch that I really believe should be part of the core:

That means you can still edit all settings on the module config screen, but you can override any setting in config.php like this:

<?php
$config->rockmigrations = [
  'syncSnippets' => true,
];

My module now shows that changes in a nice and easy way (bubble 2) and it also comes with links to edit a setting directly (1), which will scroll to the field in question ? 

What do you think, would this be helpful for your modules as well? Should this be part of the core?

[zoeck]

5 hours ago, bernhard said:

I just pushed an update to the DEV branch that I really believe should be part of the core:

The Image isn‘t working ? 

[bernhard]

Thx! I've updated the link. It was working for me so I would have not realised! Github changed something with embedding images from issue comments ? 

[bernhard]

RockMigrations now has a feature to easily make sure to fire certain migrations only once:

$rm->once(
  "2024-02-11: Simple demo of the new once() feature",
  function() {
    bd('I will be executed only once!');
  }
);

Extensive docs are already in place: https://github.com/baumrock/RockMigrations/tree/dev/docs/once

[gebeer]

Hi @bernhard since you have a major version change, does v4.0.0 introduce any breaking changes?

[bernhard]

Hey @gebeer nothing dangerous ? 

Quote

⚠ BREAKING CHANGES
remove ImageMurl tweak in favour of Latte Filter

I don't think that anybody except me was using this, but it's a breaking change...

Anybody not using it can safely update.

Before:

{$img->maxSize(500,500)->murl}

After:

{$img->maxSize(500,500)->webp->url|vurl}

This adds a version-url string for cache busting which is especially great when changing image focus point as then often the image url does not change (its still ...500x500...) but the image should get reloaded by the browser. This simple latte filter ensures that and the old ->murl had problems with webp so I changed it ? 

[bernhard]

From latest Rock Monthly newsletter:

RockMigrations v4.3.0

• New method hidePageFromTree()
• New config setting to disable magic methods (request by @netcarver) https://tinyurl.com/ykv9otsc
• Improved the "copy code" feature in the PW backend GUI
• Improved method renderTable()

[netcarver]

Hi @bernhard I just tried adding the following tweak to the tweaks/ directory, and am getting an error from RockMigrations when the admin reloads.  If I remove my attempted tweak, everything works again.  I think this is in RM, rather than the tweak file.  Thanks for the module, BTW.



PageListShowExtras.php

[netcarver]

Ah, this is user error - ignore my post above. :)

[bernhard]

Great! Are you porting a feature from AOS to RM Tweaks? ? 

[netcarver]

Yes, that's right. I use maybe 5 or so features from AoS and figured porting those over would be a good way to learn both how AoS does it, and how your tweaks work. I'll add as PRs, with attribution to tpr, as I go.

Updated to add: First four tweaks from AoS done and in as a pull request.

1. Show extra actions by default.
2. Show template name as a link to the template edit page.
3. "Bypass trash" adds the Delete button to the page action list and also allows permanent deletion from the delete tab when editing pages.
4. Prev/Next page edit links.

[netcarver]

All we need now is a community library of tweaks and macros. Perhaps it could be called "The Rock Pool" :)

[Ivan Gretsky]

I really like the idea with a tweaks pluggable collection. But I would prefer its usage was separated from the RockMigration module, so one could use tweaks without the more developer-centric  migration tool. I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive.

[adrian]

8 hours ago, Ivan Gretsky said:

I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive

https://github.com/baumrock/RockAdminTweaks

[Ivan Gretsky]

@bernhard, is that module not deprecated in favor of migrations tweaks? If not, shouldn't we be encouraged to develop the Tweaks module instead? Does it have its own support thread?

 

[netcarver]

The RockAdminTweaks repo says...

Quote

... you can place your own tweaks in /site/assets/RockAdminTweaks and they will automatically be included and handled by RATs.

Does RockMigrations have the same tweak loading ability from the assets directory?

[gebeer]

19 hours ago, Ivan Gretsky said:

I really like the idea with a tweaks pluggable collection. But I would prefer its usage was separated from the RockMigration module, so one could use tweaks without the more developer-centric  migration tool. I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive.

I totally support this. Since the tweaks part of RM can be expected to grow, I also think it would be better to have this in a separate module. RM really should be what it states: the ultimate automation and deployment tool. This is where it shines. I'd be sad to see it become bloated with functionality not related to that. Just my honest opinion.

[gebeer]

38 minutes ago, netcarver said:

Does RockMigrations have the same tweak loading ability from the assets directory?

Not yet, I guess, based on the loadTweaks method.

[netcarver]

I was unaware of RockAdminTweaks and have now installed it alongside RockMigrations. Porting the tweaks over is very simple (just a change to the namespace in the tweak file) and I prefer having them in the assets folder as well.

[netcarver]

Here's my first attempt at a public repo for Rock Admin Tweaks. Has the AdminOnSteroids tweaks from above, and my QuickWebAuthnLogin already ported over from RockMigrations.

[bernhard]

Hey guys, please check out the new version of RockAdminTweaks which now even has a forum thread ? 

Would be great to get some PRs with tweaks!

@netcarver I decided to rewrite the module because I didn't like some aspects of the old one.

@Ivan Gretsky I've just added those tweaks to RM because I was lazy and I did not get a single feedback on that RockAdminTweaks at all. But I agree that tweaks have nothing to do with RM, so I'm fine with moving them away from RM into a dedicated module. Do you have time to help with that?

[bernhard]

Anybody using RockMigrations for automated deployments please check out v5.0.1 which changes the names of the release folders from "release-[deploy-id]-[commit-sha]" to "release-YYYYmmddHHiiss-[commit-sha]"

The reason for this change is that yesterday suddenly my deployments broke and it turned out that the deploy-id made a jump from 999... to 100... which broke the logic that was used for renaming all release folders after each deployment. This should not happen any more now that we are using timestamps which are maybe more helpful anyhow.

I don't think so but in case it does not work with the new version remove all old release folders and then deploy again.

[Sanyaissues]

Hi @bernhard. I'm about to try rockmigrations, I already saw your videos (amazing job, thank you!), poke the docs and read a few posts on this thread. But there's something I'm wondering:

Let's say we have a clean PW installation and we want to create a page (dar) with the template (doo) and two fields (foo  & bar). What "workflow" will you follow to deploy them? My first guess:

1. On migrate.php we create the page, template and fields:

Spoiler

<?php namespace ProcessWire;

$rm = $modules->get("RockMigrations");

$rm->createField('foo', 'text', [
  'label' => 'The foo',
]);

$rm->createField('bar', 'text', [
  'label' => 'The bar',
]);

$rm->createTemplate('doo', [
  'fields' => [
    'title',
    'foo',
    'bar',
  ]
]);

$rm->createPage(
  template: 'doo',
  parent: 1,
  title: 'Hello dar-ling',
  name: 'dar'
);

 

2. We create  /site/classes/DooPage.php to define the settings for the doo template: 

Spoiler

<?php namespace ProcessWire;

use RockMigrations\MagicPage;


class DooPage extends Page{

    use MagicPage;
    
    public function migrate():void{

        $rm = $this->rockmigrations();

        $rm->migrate([
            'fields' => [
                'foo' => [
                    'type' => 'text',
                    'label' => 'Im Willem da foo',
                    'columnWidth' => 50
                ],
                'bar' => [
                    'type' => 'text',
                    'label' => 'Im at the bar',
                    'columnWidth' => 50
                ]
            ],
            'templates' => [
                'doo' => [
                    'fields' => [
                        'title',
                        'foo',
                        'bar'
                    ],
                ],
            ],
        ]);
    }

}

- Is that approach Ok? Any tips?
- After the page, template and fields were created, it's Ok to leave the "creation" instructions on migrate.php? Any risk of conflict with the instructions on DooPage (in my example I defined different titles for the foo and bar fields)?
- How can I see the RM methods using the vscode snippets?

Thanks.

[bernhard]

11 hours ago, Sanyaissues said:

Hi @bernhard. I'm about to try rockmigrations, I already saw your videos (amazing job, thank you!), poke the docs and read a few posts on this thread. But there's something I'm wondering:

Thx, I hope you enjoy it!

11 hours ago, Sanyaissues said:

- Is that approach Ok? Any tips?

Looks good. I'm always using an autoload module for every project called /site/modules/Site/Site.module.php and put all the global things there. So there I'd have a migrate() method with something like this:

<?php
public function migrate() {
  $rm = rockmigrations();
  $rm->createTemplate('doo');
}

And then all the migrations that are related to the "doo" template go into the DooPage.php pageclass.

Creating the fields can either go in Site.modul.php or in DooPage.php - it depends. If I want to reuse these fields I put them in Site.module.php - if they are solely for DooPage I put them in DooPage.php

11 hours ago, Sanyaissues said:

- How can I see the RM methods using the vscode snippets?

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

[gebeer]

On 7/22/2024 at 8:55 PM, bernhard said:

Anybody using RockMigrations for automated deployments please check out v5.0.1 which changes the names of the release folders from "release-[deploy-id]-[commit-sha]" to "release-YYYYmmddHHiiss-[commit-sha]"

The reason for this change is that yesterday suddenly my deployments broke and it turned out that the deploy-id made a jump from 999... to 100... which broke the logic that was used for renaming all release folders after each deployment. This should not happen any more now that we are using timestamps which are maybe more helpful anyhow.

I don't think so but in case it does not work with the new version remove all old release folders and then deploy again.

I can confirm that deployment worked for us after update to 5.0.1 only after removing the old release folders. When leaving them in place on the first deployment, the new release folder with new naming format did not get created. But current was symlinked to that non existing folder.