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

[bernhard]

This is really neat and I'm not sure why I didn't have that idea earlier! The filesOnDemand feature now supports callbacks!! 😎🚀

From the docs: Callback Feature

Sometimes you want to prevent the filesOnDemand feature to kick in. For example in the RockInvoice module I have a pdf field that stores invoices, but these invoices are protected from direct download by htaccess.

When I develop locally this leads to time consuming page requests and HTTP error messages that the requested file could not be downloaded. Callbacks to the rescue!

$config->filesOnDemand = function (Pagefile $file) {
  if ($file->field->name === RockInvoice::field_pdfs) return false;
  return 'https://my-live-site.com/';
};

 

[bernhard]

v7.0.0 removes the hideFromGuests() feature and moves it to the dedicated RockGatekeeper module: 

 

[erikvanberkum]

Bernhard, 

As announced in the changelog, I have: ⚠ BREAKING CHANGES

What the… Compile Error: Cannot declare class RockMigrations\MagicPages, because the name is already in use (line 17 of site/modules/MagicPages/MagicPages.module.php) 

Any quick workaround for this? This site is a new server setup with RockCommerce and RockForms, so nothing of value from the past. 

For now, I have commented out the MagicPages module, which gives me access to the backend again. 

 

[bernhard]

3 hours ago, erikvanberkum said:

As announced in the changelog, I have: ⚠ BREAKING CHANGES

Hey @erikvanberkum what breaking changes are you talking about? MagicPages have been there for ages and the latest breaking change was really only about removing the hideFromGuests feature which should have nothing to do with the MagicPages feature. It sounds like your system is loading RockMigrations multiple times somehow?

Do I understand you correctly that this is a fresh installation of RockCommerce + RockForms + all dependencies? Not an existing site? No updates or anything else?

[erikvanberkum]

@bernhard

I revisited the issue today. I upgraded from RockMigrations 6.9.0 to 7.0.0, and encountered an error, resulting in the loss of the entire backend. 

Cannot declare class RockMigrations\MagicPages, because the name is already in use (line 17 of site/modules/MagicPages/MagicPages.module.php)

Renamed MagicPages to .MagicPages and the site is workable again. Further investigation into the issue, it seems that the RockMigrations directory somehow got renamed to MagicPages. When I performed the upgrade, I ended up with two RockMigrations once in the directory RockMigrations and one in directory MagicPages. I will not further investigate how that happened. 

[snck]

@erikvanberkum  I (successfully) upgraded a website from RM 5.X to 6.9.0 and 7.1.0 in the end and had zero problems. But no single ProcessWire instance I am working on with RockMigrations has a file site/modules/MagicPages/MagicPages.module.php. In all my installations it is site/modules/RockMigrations/MagicPages.module.php. As MagicPages are part of RockMigrations, this should be the reason for the error you are experiencing. I would delete the site/modules/MagicPages directory as it seems redundant to me and do a modules refresh. 

Cheers,
Flo

[snck]

Hi @bernhard — first of all: thank you again for RockMigrations. It has become one of those “can’t-live-without” tools in my ProcessWire projects and makes CI/CD + deployments incredibly smooth.

Why I needed a workaround (shared hosting reality)

In this client project I migrate pretty much everything via RockMigrations: fields, templates, roles/permissions, installed modules — and also some pages/permissions that are created dynamically based on constants/config values that change from time to time.

That works great conceptually, but on a very slow shared host it led to painfully long migration runs even when there was nothing to change. A lot of my migrations are “dynamic config” style and get evaluated every deploy, which was costing me minutes per run (and that adds up quickly with multiple deploys/commits per day).

A tiny helper module: hash-based skipping for config migrations

I wrote a small helper module (not meant to be more than a little utility) that helps specifically with this scenario:

• Build a migration $config array (can include dynamic parts).
• Normalize + hash the config.
• If the stored hash for a key matches, skip running the migration.
• If it differs, run it and store the new hash.

So migrations only execute when the effective config changed.

How I use it (complete example)

This is how it’s used in my migrations (example shortened, but complete in terms of usage):

<?php

namespace ProcessWire;

use RockMigrations\MagicPage;

class AuthorPage extends Page
{
  use MagicPage;

  public function migrate(): void
  {
    /** @var RockMigrations $rm */
    $rm = $this->wire->modules->get('RockMigrations');
    $speed = $this->wire->modules->get('DlfMigrationSpeedUp');

    $config = [
      'fields' => [
        'firstname' => [
          'label' => 'First name',
          'type' => 'FieldtypeText',
        ],
        'lastname' => [
          'label' => 'Last name',
          'type' => 'FieldtypeText',
        ],
      ],
      'templates' => [
        'author' => [
          'fields' => [
            'title' => [
              'columnWidth' => 50,
              'label' => 'Display name',
            ],
            'firstname' => [
              'columnWidth' => 50,
            ],
            'lastname' => [
              'columnWidth' => 50,
            ],
          ],
        ]
      ]
    ];

    $key = 'template:AuthorPage';

    if ($speed && !$speed->shouldRun($key, $config)) {
      // unchanged -> skip
    } else {
      $rm->migrate($config);
      if ($speed) $speed->remember($key);
    }
  }
}

Important limitations (when this does not apply)

This only works if the migration outcome is fully determined by the config you hash.

It’s not a good fit if relevant parts can be changed outside code, for example:

• field/template settings changed in the PW admin GUI,
• manual permission tweaks,
• any DB drift that is not represented in the hashed config.

In my case it’s safe because I enforce “everything via RockMigrations/API” for this instance — but it’s definitely not something I’d blindly recommend for every setup.

Performance impact (real numbers)

On that shared host, some of my “dynamic config” migrations were extremely slow even when they effectively had nothing to change. Example excerpts from one run before the helper (I’m anonymizing the real class names here):

Before:

• TemplateXPage::migrate() 53.434s
• TemplateYPage::migrate() 29.347s
• TemplateZPage::migrate() 20.431s
• …many more similar steps…
• Total runtime in that log was ~226s.

With the helper enabled, unchanged migrations are skipped and return immediately:

After (unchanged config):

• TemplateXPage::migrate() 0.000s
• TemplateYPage::migrate() 0.000s
• TemplateZPage::migrate() 0.000s
• …everything essentially no-op…
• Total runtime (from the log): ~0.72s.

That’s a night-and-day difference for repeated deployments where the effective config didn’t change.

Code (module) on Gist

I didn’t want to paste the whole module here; the code is in this Gist:
https://gist.github.com/fsnck/cf7799c1f761681cc5f0dea13e3b802a

If anyone has thoughts on edge cases or improvements, I’m happy to discuss. And again: thanks @bernhard — RockMigrations is awesome.

[bernhard]

Cool @snck very interesting read. Glad you found a good solution for your problem and glad that RockMigrations helps you as much as it helps me 🙂