New custom page Classes aren't getting added to the watchlist after recent update?

[gornycreative]

Using RockMigrations 3.33.0 when I copy new custom page class files to the classes directory they aren't getting added to the watchfile list automatically.

Previous versions picked up magicpages and added them.

Even after I try to add them using watch() and watchPageClasses() for some reason when I output the watchlist they are not appearing.

Page classes that already exist are watched - when they are updated the migrations run fine.

Is there a watchlist cache I need to clear someplace?

None of these classes are part of a module, they are all simply in the classes directory off the root pw folder. e.g. /pw/site/classes/

My page class structure hasn't changed. It's pretty simple.

<?php namespace ProcessWire;

use RockMigrations\MagicPage;

class TestingPage extends Page {

    use MagicPage;

    const tpl = 'testing';
    const group = 11.55;
  
  // I added a check for this constant in the watch() method for instanceof Page so I can have more control over migration order.

    public function migrate() {

        $rm = $this->wire->modules->get('RockMigrations');

        $rm->migrate([
            'template' => [
                'testing' => [
                    'fields' => [
                        'title' => [
                        ],
                    ],
                    'fieldgroups_id' => 'testing',
                    'flags' => 0,
                    'cache_time' => 0,
                    'sortfield' => 'name',
                    'useRoles' => 1,
                    'noParents' => 1,
                    'childTemplates' => [
                        0 => 'test-child',
                    ],
                    'parentTemplates' => [
                    ],
                    'slashUrls' => 1,
                    'noMove' => 1,
                    'childNameFormat' => 'title',
                    'noChangeTemplate' => 1,
                    'noShortcut' => 0,
                    'compile' => 3,
                    'label' => 'Testing',
                ],
            ],
            'roles' => [
                'guest' => [
                    'access' => [
                        'testing' => [
                            'view',
                        ]
                    ],
                ],
                'copy_editor' => [
                    'access' => [
                        'testing' => [
                            'view',
                        ],
                    ],
                ],
            ],
            'pages' => [
                'testing' => [
                    "template" => "testing",
                    "title" => "Testing",
                    "parent" => "name=options,template=options-main",
                    "status" => [
                        'on',
                    ],
                ],
            ],
        ]);
    }
}
?>

In my install the Options page does already exist.

[gornycreative]

Hey I just saw the new release of 3.34 - and it looks like perhaps there is a cache getting cleared now.

I will give it a try and let you know how it goes.

[gornycreative]

Okay, I found my template to templates typo in the config array.

I also forgot that at one point I added in a migratePageClasses method call but subsequently removed it.

Putting it back in triggered the migrations in those class files.

It seems like once the template name is in the 'magic-templates' cache they are watched/migrated.

If I am not putting my classes in a separate module, would I still use migratePageClass? It seems like the preferred pageClassLoader is only for migrating classes that are in a modules file set.

[bernhard]

14 hours ago, gornycreative said:

If I am not putting my classes in a separate module, would I still use migratePageClass?

No. What I'm always doing is this in Site.module.php:

$rm->createTemplate('foo');

This will create the template if it does not exist and it will automatically trigger ->migrate() on an in-memory page that has that template.

On subsequent requests the template does already exist and if it's a MagicPage then it should automatically be watched for changes.

PS: Did you read the phpdoc on migratePageClasses() ? ? 

DEPRECATED AS OF 24.7.2023
   * Please use $rm->pageClassLoader() instead!
   *
   * Migrate all pageclasses in given path
   * Note that every pageclass needs to have the template name defined in
   * the "tpl" constant, eg YourPageClass::tpl = 'your-template-name'

I have to add better docs on that one day...

[gornycreative]

2 hours ago, bernhard said:

PS: Did you read the phpdoc on migratePageClasses() ? ? 

I read A LOT of your source code because I have to diff with changes I've made to accommodate my requirements.

So the template creation should happen first. Got it.

2 hours ago, bernhard said:

I have to add better docs on that one day...

Maybe. The mechanics are usually clear but it sometimes isn't obvious what is triggering what, and in what order.

And I know you like "triggering" things ?

      // object to migrate
      // usage: $rm->watch("file.php", true, ['trigger'=>$something]);
      // will trigger $something->migrate() when file.php changes
      // see RockCommerce.module.php/Product for an example
      'trigger' => false,

I like the idea of this. Should be fun to build with.

[bernhard]

Great news ? I've just pushed v3.35 which adds auto-loading of pageclasses to RockMigrations!

Now if you are developing a module that ships with custom pageclasses all you have to do is to add them in the /pageClasses folder of your module and add the proper namespace! ???

See the docs here: https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/custom-pageclass/

On 1/5/2024 at 9:53 PM, gornycreative said:

I read A LOT of your source code because I have to diff with changes I've made to accommodate my requirements.

What about PRs? Having a watch priority as class constant for example sounds like a good idea to have ? 

[gornycreative]

Yeah sure I can do PRs if you want.

I ended up forking your migratePageClasses method and cutting out the migration aspect and calling it detectPageClasses. I understand why its pretty redundant for your purposes (primarily page classes in custom modules) but being able to run something to quickly check in directories for new classes without doing a full migration is helpful for my use case.

[bernhard]

On 1/5/2024 at 7:10 PM, bernhard said:

I have to add better docs about Magic Pages one day...

That day was today ?? https://github.com/baumrock/RockMigrations/blob/38f643989f459e694ff14d3392fad8f90bbe6264/docs/magicpages/readme.md

Docs will soon be on https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/ as well ?