bernhard

I came to this thread by coincidence: It was very popular back then. But I've never heard of anybody using dynamic roles over the last few years. Is anybody using it and want to share the "why" and "how"? ?

You might want to add an additional if($page->template != 'your-pagereference-template') return; inside the hook if you do not want to set all languages active globally on the site...

Does it work if you place this hook in site/ready.php? <?php // set all languages active automatically $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); foreach($this->wire->languages as $lang) { if($lang->isDefault()) continue; $page->set("status$lang", 1); } $page->save(); });

Thx for that example. I understand now. <?php // migrate field content only if the address field exists if($rm->fields->get('address')) { // first we make sure the fields exist $rm->createField('foo', 'text'); $rm->createField('bar', 'text'); $rm->createField('baz', 'text'); // then we make sure they are added to xyz template $rm->addFieldsToTemplates(['foo','bar','baz'], 'xyz'); // then we migrate data foreach($pages->find('template=xyz,address!=') as $p) { $parts = ...; // split address into parts $p->of(false); $p->foo = $parts[0]; $p->bar = $parts[1]; $p->baz = $parts[2]; $p->save(); } // then we delete the obsolete field $rm->deleteField('address'); } // then we use the existing migration config for future use // so you can easily add other stuff (like whatsoever field) $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], 'whatsoever' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], 'whatsoever' => [ 'fields' => ['whatsoever'], ], ], ]); If you are inside a module that uses a migrate() method to migrate data this could easily been refactored to this: <?php class MyModule ... { public function migrate() { $rm = $this->wire->modules->get('RockMigrations'); $this->migrateAddressData(); $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], 'whatsoever' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], 'whatsoever' => [ 'fields' => ['whatsoever'], ], ], ]); } public function migrateAddressData() { // if the address field does not exist any more // we can exit early as we have nothing to do if(!$rm->fields->get('address')) return; // first we make sure the fields exist $rm->createField('foo', 'text'); $rm->createField('bar', 'text'); $rm->createField('baz', 'text'); // then we make sure they are added to xyz template $rm->addFieldsToTemplates(['foo','bar','baz'], 'xyz'); // then we migrate data foreach($pages->find('template=xyz,address!=') as $p) { $parts = ...; // split address into parts $p->of(false); $p->foo = $parts[0]; $p->bar = $parts[1]; $p->baz = $parts[2]; $p->save(); } // then we delete the obsolete field $rm->deleteField('address'); } } This is one of the situations that are not possible using YAML of course ? But the "migrateAddressData" could be done in PHP while the migrate() could migrate YAML data still.

Exactly. It's even named like this: migrate($config) https://github.com/BernhardBaumrock/RockMigrations/blob/db4d300b4369863d41003f5c668b7ecaf2f19b5d/RockMigrations.module.php#L2693 Sorry, I don't understand. Note that I have no experience with multiplier fields. Maybe you can give me another example?

Migration 21-11 (add foo field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo'], ], ], ]); Migration 21-12 (add bar field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar'], ], ], ]); Migration 22-01 (add baz field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], ], ]); RockMigrations works in a way that no matter how often you run the migration the config will be applied and the system will result in the same config each time. I know this is a totally different concept than you are using in your migrations module but it has turned out to be extremely easy to use and it works well. In the example above it does not matter if you jump from 21-11 to 21-12 and then to 22-01 or if you go directly from 21-11 to 22-01. Or you could even start with 22-01 and nothing else before. That's easy as long as you add things to the system. Removing things is a little different, but it's also easy: 22-02 (remove baz field) <?php $rm->removeField('baz'); $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar'], ], ], ]); Reverting things it a totally different topic! 22-01 --> 21-11 would not really be possible using RockMigrations. Though you can think of 22-02 as a "revert migration" that does exactly what a reversion would do. But if one does not like that concept they could also use RockMigrations in a way your module works. In my experience this makes migrations just a lot more complex while adding things into a php array is cake. I've never had any problems over the last few years with my concept ?

thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity. What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example: <?php namespace ProcessWire; /** @var RockMigrations $rm */ return [ 'fields' => [ 'foo' => [ 'type' => $wire->languages ? 'textlanguage' : 'text', ], ], 'templates' => [ 'demo' => [ 'tags' => RockMails::tags, 'fields-' => [ 'title', 'foo', ], ], ], ]; That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML. I'm really curious what it is really about, thx.

Well that's two different dumps... one is dumping the array and one is dumping an object that has an array inside the data property! d($config->paths); d($config->paths->data); Personally I think that behaviour is good ?

yes ? ... ps: same for d()

Ok strange because I tested it today myself and it just worked for 110 items, so I thought it works as expected?! ?‍♂️

did dbd() not work for you?

--disregard--

bdb() or barDumpBig()

Hi and welcome to the forum / PW ? Have a look at https://processwire.com/modules/tracy-debugger/ that makes your life a lot easier!

I think I don't agree with you here. Could you please explain that in detail? I'm not sure I understand. What you are asking for is exactly what I'm showing in the video?!

Side note @ryan it would be nice if you could add relevant keywords to the title of new news or blog posts. This makes it easier to find information when you are searching for it weeks or months later ("weekly update 14.1." is not nearly as helpful as "weekly update find raw parents, sanitizer float" in a search result) +1 for better version control support. I've not built RockMigrations just for fun ?

Yes, the link does not work on my DDEV environment ?

Hi @Richard Jedlička there's one slash too much on line 134 ? PS: If it is easy to implement a "save + reload" button would be nice to have in the modal ?

Hey @horst why is that by design? I don't understand why we should not be allowed to upload webp directly if we want to display webp afterwards?

You need to download it first...

Thx @rjgamer It is shipped now with the core: https://processwire.com/blog/posts/pw-3.0.179/ Or you install and use AdminStyleRock which makes it possible to select the primary color via inputfield on latest dev:

Did a quick test:

TracyDebugger shows all the available options, so you don't have to remember them already. But you have to write them down manually at the moment. I guess it would be possible to create that yaml file on the fly. If tracy knows all the settings and can write them to the panel I'm quite sure it is possible to write them to a yaml file as well. Maybe @adrian can tell us something about that?

This would be some kind of a dream for me to have in ProcessWire. ?‍♂️

/site/modules/MyModule /site/modules/MyModule/classes /site/modules/MyModule/classes/MyPageClassOne.php /site/modules/MyModule/classes/MyPageClassTwo.php /site/modules/MyModule/MyModule.module.php The module: <?php namespace ProcessWire; class MyModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyModule', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->initClasses(__DIR__."/classes"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } The class: <?php namespace ProcessWire; class MyPageClassOne extends Page { public function init() { $this->wire->addHookAfter("Pages::saveReady", $this, "onCreate"); } public function onCreate(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof self) return; if($page->id) return; $page->status = 1; // auto-publish this page $this->message('Auto-published page '.$page->path); } } initClasses() will not only load your custom page classes but also trigger the init() method once. That makes it possible to attach all kinds of hooks that belong to the custom page class where they belong: Into the page classe's php file. You avoid hook-hell in ready.php like this. It will load one instance of your page class on every request though. You can also use custom namespaces easily: // in the module: $this->rm()->initClasses(__DIR__."/classes", "MyNameSpace"); // your page class: <?php namespace MyNameSpace; use ProcessWire\Page; class MyPageClassOne extends Page { ... } You don't need to use RockMigrations for that. You can have a look what initClasses() does. You could also just set the page class on the template. I don't know if that can be done manually but using RockMigrations it is just setting one property of the template: 'my_template' => [ 'fields' => [...], 'pageClass' => ..., ]