bernhard

I'd have used the one that is in $config->superUserPageID which is 41 usually... Or it could simply do a $users->get() to return the first superuser it can find? I don't think that this is anything worse than what we already have... I just doublechecked and my tracy bar is shown for guest users on local dev and I can use the console for whatever I want. So a superuser-login-button would not hurt imho? ? Thx for the tweaks on the user switcher!! I was talking about the login-link in the bar: Looks like you have already setup a redirect feature here? If I visit page /foo on the frontend, then click "login" in the tracy bar I come to the login screen and after login I'm back at /foo When using the regular login the process is different: Visit /foo on the frontend --> go to /processwire --> login --> see the pw page tree (or dashboard) --> go back to /foo (manually)

Thx ? Thx for the reminder, I linked the post in the video description! Yesterday I implemented another way of doing the same principle into RockMigrations. RockMigrations has had the initClasses() method, but you had to call that manually and provide the correct namespace. With yesterday's update you simply let the custom page class use the MagicPage trait and RockMigrations will autoload the pageclass on boot and trigger init() and ready() on the correct timing. I didn't want to put that into the video though as it's a very young addition and I've already had to fix some things today. But it looks like a very promising approach to me ? Thx, I'll try my best. It's quite a lot of work, but it's fun.

Thx for the inspiration - this is for you ?

@adrian what do you think of a "Login as Superuser" button for local development (obviously)? I'm doing lots of db restores (using RockShell) and after the restore I'm always logged out and need to log in. The problem with the log in is that I have to move away from the current page, then navigate back to the site I was watching... Ideally I could just click "Login as Superuser" while viewing the page as guest and I'm logged in and redirected to the same page I was before. Another small thing: Would it be possible to add the doubleclick-submit feature to the user switcher as well (as you did it with the language switcher)? PS: Just realised that when clicking "login" in the tracy debug bar it already redirects me to the correct frontend page after login, thx for that!!

I've edited my statement from 2019. Ryan has already pulled in several contributions and said he is happy to add others. So I think while it does not happen very often (which has the benefits that @pwired mentioned) it is not true (any more?) that PRs are ignored ?

Thx for the feedback @Spinbox I'll try to do that! ? Would you need an explanation of the concept of migrations in general or would that be too much?

Edit: Sorry for double-posting, I forgot that I already posted that yesterday! I've fixed a bug though and the color now comes from the AdminStyleRock setting which makes it even more great ? --- When using the latest version of AdminStyleRock you'll get perfectly aligned frontend + backend styling using ALFRED frontend editing: Backend Inline Editor Modal Editor You'll get all that by changing only a single color in AdminStyleRock:

The latest version adds some improvements to alfred styling. Now the ALFRED styles take the primary color setting of this module as primary color ?

I guess it just needs to get published by ryan

I've just implemented a new way of how watching files work and bumped the version to 1.0.0 As from version 1.0.0 the module will not run ALL migrations any more but only the ones that either have the "force" property set or that have changed since the last migrations run. I'm working on a site with lots of RockMatrix blocks and all blocks have their own migrate() method. Using RockFrontend I get livereload as soon as I change a watched file, but then the reload took over 9 seconds because I had so many migrations going on. Now the new version does only migrate changed files and forced files, which brings down the duration for the reload to around 1 second ? When using migrate() from the CLI it will still trigger all migrations, even for unchanged files. That update will especially be interesting for you @dotnetic I guess? ? This is how the log looks like (HomePage was changed and RockMatrix is forced, so these two files are the only ones being triggered):

Thx @3fingers great to hear that!

I have just released version 2 of RockMigrations: GitHub: https://github.com/baumrock/RockMigrations Modules Directory: https://processwire.com/modules/rock-migrations/ Please star the module on GitHub if you like it ? Are you unsure if RockMigrations is the right tool for you? @Jonathan Lahijani in a very nice PM ? Read the full post here Read the full post here Read the full post here QuickStart The example code uses bd() calls for dumping data. You need TracyDebugger installed! Put this in your site/migrate.php /** @var RockMigrations $rm */ $rm = $modules->get("RockMigrations"); bd('Create field + template via RM'); $rm->createField('demo', 'text', [ 'label' => 'My demo field', 'tags' => 'RMDemo', ]); $rm->createTemplate('demo', [ 'fields' => [ 'title', 'demo', ], 'tags' => 'RMDemo', ]); Reload your site and you will see the new field and template in the backend and you'll see the message in the tracy debug bar.

Which article? Yes I'm using OBS + Davinci Resolve

Hey @flydev ?? thank you very much ? I'll try to put the feedback into the next video! Regarding the sound: Does anybody know how to find the right level? Are there some hard numbers one can use? I have just done that by best guess with my usual speaker settings...

The module got several updates over the last few weeks. Now it integrates perfectly with RockFrontend and ALFRED frontend editing and you'll get the same look+feel both for the backend and frontend editing: Backend: Frontend:

v1.17.6 improves the UI/UX of ALFRED frontend editing even further and when using AdminStyleRock you'll get the same styling both on the backend and the frontend: Backend: Frontend:

Yeah, that's one of very rare examples where PW might add a little too much magic ? The different return values of an image field can definitely lead to confusion or even worse to problems. Until April this year I thought I would be save just using $page->getUnformatted('images') as this always returns the array version. https://processwire.com/talk/topic/26952-get-image-in-the-context-of-a-hook/?do=findComment&comment=222914 But thankfully @Robin S has pointed out that this array might include temporary items and therefore might lead to unexpected results again... See https://processwire.com/talk/topic/26952-get-image-in-the-context-of-a-hook/?do=findComment&comment=222917 There are several not so obvious solutions to the problem: https://processwire.com/talk/topic/26952-get-image-in-the-context-of-a-hook/?do=findComment&comment=222942 --- For my taste this shows that the different output formatting return types introduce more complexity and risk than necessary, but that decision was made a long time ago so we'll have to deal with it. Instead of using ->getUnformatted() I have switched to using ->getFormatted() instead and making sure to set the correct value via RockMigrations. <?php class Example extends Page { public function myImage() { // return image as single pageimage return $this->getFormatted('myimage'); } public function migrate() { [...] $rm->createField('myimage', 'FieldtypeImage', [ 'label' => 'My demo image field', // make sure that the image field returns a single image 'outputFormat' => FieldtypeFile::outputFormatSingle, [...] ]); } } I just realized though, that this can be a problem, because I'm defining an important piece of the method "myImage()" in another method! So on a more complex pageclass I might change the outputFormat of the field to outputFormatArray and I'll introduce a bug in myImage() ! That's not good... I think we should have something like this: $page->getImage('myimagefield'); // returns PageImage (or null) $page->getImages('myimagefield'); // returns PageImages Array That would make a bulletproof code look like this (which would then be a simple answer to your simple question): $image = $page->getImage('myimagefield'); if($image) echo "<img src='{$image->maxSize(400,300)->url}' alt='...'>"; // or $images = $page->getImages('myimagefield'); if($images->count()) echo "<img src='{$images->first()->maxSize(400,300)->url}' alt='...'>"; That would look a lot more like PW imho ? I've created a request for that, so if you like the idea give it a thumbs up: https://github.com/processwire/processwire-requests/issues/453

Yes, I understand that. They have the free choice to do it the hard way if they feel more secure then and come up with all the same questions that I came up with while developing the module. Nice idea but simply not possible. There has been a lot of discussion about that. See https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/#comment-220383 What you describe is exactly where RockMigrations shines. I keep repeating myself. And people keep not using RockMigrations. That's ok, but I'll not go into details of your question again. I've explained often why something that you describe is not a good solution. It might be a little easier to use, but it does not make the solution better in the big picture.

Likely never. I know how great it works and how much difference it can make. But it seems that there are very few people actually using it. Even though it's free and one of the best things I have built over the last few years. The reason why it is free is mostly because I thought many other module developers could benefit a lot from using it for their modules. We could have blog modules that create all the necessary fields and templates for example. I guess you'd be 10 times quicker using RockMigrations compared to a traditional API based setup. I plan to create a video about it as soon as I can. Maybe that will open some eyes. Maybe it will also show Ryan the benefit of the concepts and we get something similar for PW4 one day, who knows...

$rockmigrations->deletePage("/yourpage"); https://github.com/baumrock/RockMigrations/blob/2db2e74407a663150dbc2f423662b287b59d7919/RockMigrations.module.php#L976

In PW using RockMigrations the developer would just have to add this to a migrations file: $rm->installModule('Navigation'); Then the other dev could do a git pull and on the next reload everything would just work. I'm using a similar approach for my projects. I'm having a main module for the project, eg Site.module.php that is available for all kinds of project related stuff as $site API variable. There I put the global migrations, eg this: $rm->installModule('Navigation'); $rm->installModule('RockMatrix'); Then RockMatrix for example does also have migration files that create fields and templates that are only necessary for RockMatrix. Works absolutely great.

I'm sure you can do the same in gitea, we are using gitlab at work and it also works. The whole idea is that the deployment is done by php so you don't have to copy and paste complicated deployment scripts over and over again. And we can improve one script all the time instead of having 100 slightly different versions... But it's very opinionated of course. But works great for me and us.

You can either register your own api variable, eg in ready.php $wire->wire('contact', $yourpage); Or you simply add whatever property you need at runtime to the rockfrontend object: $rockfrontend->foo = 'Foo!'; $rockfrontend->bar = 'Bar!'; Then you can simply access those variables in your latte files: {$contact->title} {$rockfrontend->foo} {$rockfrontend->bar}

I've started with this guide as well, so thx a lot again for sharing that @gebeer but I want to mention that for anybody interested in automatic deployments RockMigrations ships with a ready-made deployment solution that you can use: https://github.com/baumrock/RockMigrations#deployments

Do you have input what you would like to see in such a video?