Jump to content

Migrations in custom Page Classes


gebeer
 Share

Recommended Posts

Hi @bernhard,

referring to this post:

Thank you for the detailed explanation there. I was not sure if the custom PageClass files would be called before the associated template exists and therefore the migrations would run initially. For example, I have a site/classes/MemberPage.php with migrations in it, where the migration creates the member template.

Will the migrations be triggered before the member template even exists?

Link to comment
Share on other sites

Hi @gebeer no, of course the page class' migrate() method can only be called once the template exists. But that is done automatically by RM if you use the createTemplate() method:

Vw0Afaw.png

That means all you need is to create your pageclass in /site/classes/FooPage.php and then in your Site.module.php (or wherever else) you do $rm->createTemplate('foo');

This is an example of my modules overview page on baumrock.com where I'm even too lazy to create the view file manually to make the page be publicly accessible, but you can do that manually if you prefer:

<?php

namespace ProcessWire;

use RockMigrations\MagicPage;

class ModulesPage extends Page
{
  use MagicPage;

  const tpl = 'modules';

  public function migrate()
  {
    $rm = $this->rockmigrations();
    $rm->createViewFile($this);
    $rm->migrate([
      'fields' => [],
      'templates' => [
        $this->getTplName() => [
          'fields' => [
            'title',
            RockPageBuilder::field_blocks,
          ],
          'childTemplates' => [
            'module',
          ],
          'sortfield' => 'title',
        ],
      ],
    ]);
  }
}

This is my migrate() in Site.module.php:

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

    // cleanup/reverts
    $this->cleanup($rm);

    $rm->installModule("RockPageBuilder");
    $rm->setPagenameReplacements('de');
    $rm->setModuleConfig('AdminThemeUikit', [
      // use consistent inputfield clicks
      // see https://github.com/processwire/processwire/pull/169
      'toggleBehavior' => 1,
    ]);
    $rm->setModuleConfig('ProcessPageList', [
      'useTrash' => true, // show trash in tree for non superusers
    ]);
    // install german language pack for the default language
    // this will install language support, download the ZIP and install it
    // $rm->setLanguageTranslations('DE');
    // $rm->installModule("LanguageSupportFields");
    // $rm->installModule("LanguageSupportPageNames");
    // $rm->installModule("LanguageTabs");
    // $rm->setFieldData("title", ['type' => 'textLanguage']);

    $rm->installModule("RockPdf");
    $rm->installModule("RockMoney");
    $rm->installModule("RockSearch");
    $rm->installModule("RockMails");
    $rm->installModule("RockForms");
    $rm->installModule("RockCommerce");
	...

    // create global fields
    $rm->migrate([
      'fields' => [
        self::field_search => [
          'type' => 'RockSearch',
        ],
      ],
    ]);

    $rm->createTemplate('pdf');
    $rm->createTemplate('modules');
    $rm->createTemplate('module');
    $rm->createTemplate('release');
    $rm->createTemplate('releases');
    $rm->createPage(
      template: 'releases',
      parent: '/',
      title: 'Releases',
      status: ['hidden'],
    );

	...
  }

Language specific migrations are commented out for performance reasons and only necessary once or maybe if new updates are available.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 12/4/2023 at 5:46 PM, bernhard said:

Hi @gebeer no, of course the page class' migrate() method can only be called once the template exists. But that is done automatically by RM if you use the createTemplate() method:

Thank you for the explanations 🙂 Would be awesome to have this in the Wiki. Would you mind me adding it there through a PR?

Splitting up migrations and working with multiple migrations distributed over the code base is something more advanced and not so easy to wrap ones head around. Especially when it comes to order of execution. Can we influence that? Might have overlooked it if it's in the documentation or Wiki...

Link to comment
Share on other sites

@gebeer I'd love to have better docs, but I don't like github wikis - that's why I built my own docs system on baumrock.com

It reads module docs from markdown files that are stored under the /docs folder within the module. See https://github.com/baumrock/RockFrontend/tree/main/docs for example. Would be great if you could create a PR for RockMigrations that show that info on my website like here: https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/deployments/

I'm busy with client work for the next weeks, so any help is very welcome 🙂 

Link to comment
Share on other sites

1 hour ago, bernhard said:

@gebeer I'd love to have better docs, but I don't like github wikis - that's why I built my own docs system on baumrock.com

It reads module docs from markdown files that are stored under the /docs folder within the module. See https://github.com/baumrock/RockFrontend/tree/main/docs for example. Would be great if you could create a PR for RockMigrations that show that info on my website like here: https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/deployments/

I'm busy with client work for the next weeks, so any help is very welcome 🙂 

Great way of managing the docs. I'll make a PR.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...