bernhard

Hi @*Most Powerful Pony!* what you are describing is indeed more complex and in such a situation you'd have to be more careful. But it's not really a drawback of RockMigrations in my opinion - it's a general team management issue just like any other merge conflicts. If I understood you correctly you are talking about a situation like this: - website X, v1.0 --- feature branch A - adds field_a v1.1a --- feature branch B - adds field_b v1.1b --- feature branch C - adds field_c v1.1c Now if anyone checks out A, then B, then C he'd had all three fields, yes. That can be a problem, I agree. The question is what you do to prevent such problems. In a classic approach you'd move back and revert migrations from branch A, then checkout B, then revert, then checkout C. But you can do the same with RockMigrations. You could for example make a DB dump of v1.0, work on branch A, then checkout B, do "rockshell db:restore" so you'd be on v1.0 and then after that restore RockShell will have applied your migrations and you'd be on v1.1b with only field_b (and no field a+c). What I'm usually doing is to have one single source of truth, which is usually the production system. Then I can do whatever I want in whatever branch and just do a "rockshell db:pull" and it will pull the production DB and apply my local migrations of my current branch. That way I also make sure that I don't get any bad surprises on deployment. But you could also use RockMigrations in a more classical way. @elabx is using it in combination with the older Migrations module, which takes care of executing migrations one by one and also provides a UI for rollbacks. That might make sense in a scenario like you are describing, still RockMigrations can be of great help for writing the migrations code itself. But don't forget that when going the classical route you basically double the development effort. Every change needs to have the corresponding rollback code as well. If that is a requirement, you can do it (even with RockMigrations). I just don't do it because I don't need it, because "rockshell db:dump" and "rockshell db:restore" is usually a lot faster than writing code for rollbacks (and not to forget test everything) ? I'm using DDEV and I'm checking in the DB into my repo. So checking out any commit in the history is "git checkout ... && ddev import-db -f dump.sql". That's it. But if you want to support RockMigrations I'd be happy to add support for classical workflows to RockMigrations or we can discuss any other cooperation to push ProcessWire forward on this topic ?

Thank you @Stefanowitsch for mentioning RockPageBuilder! However, it appears that what they need might differ from what RockPageBuilder offers. @FireWire eloquently highlighted this distinction recently: So, RockPageBuilder is more about helping developers to build content elements quickly and easily. These blocks enable clients to populate their websites with content seamlessly, without the need to think too much about the technical and visual aspects (because this is our job as web professionals). It's less about designing and more about managing content, which is something I love about ProcessWire and where it really shines. In RockPageBuilder the design is done in code - CSS, Less, Tailwind, UIkit, Bootstrap. You can choose whatever you like best. If you want a no-code page designer there are plenty of options out there, but RockPageBuilder is likely not your first choice ?

Hey @gebeer nothing dangerous ? I don't think that anybody except me was using this, but it's a breaking change... Anybody not using it can safely update. Before: {$img->maxSize(500,500)->murl} After: {$img->maxSize(500,500)->webp->url|vurl} This adds a version-url string for cache busting which is especially great when changing image focus point as then often the image url does not change (its still ...500x500...) but the image should get reloaded by the browser. This simple latte filter ensures that and the old ->murl had problems with webp so I changed it ?

@Jonathan Lahijani could you please describe the exact use case? I've never needed this and I'm wondering why one would do something like this, but I'm sure it can make sense so I'd be happy to hear an example.

This tells you that you need to install the Less module first. You need the less module for parsing all less files to css. All changes are global for all users.

https://github.com/baumrock/AdminStyleRock is the way to go. You can override all uikit variables, for example this: @global-font-size: 30px;

For me it would still not be enough. When hovering the outer rings I get a nice text in the center - but if I didn't know that I had to do that, I'd still have a white center without any hint on what I have to do... Also it seems you are loading youtube without consent?

Same experience as Teppo for me. Without his comment I would have not made it to show any content at all. For example when I click on "Full Spectrum" this happens: I really didn't get that I now have to click on one of the outer rings... Maybe you could show a message in these cases in the middle of the circle - something like "Click one of the outer rings to show content" ? Or Just show the first outer circle by default? Hats off for mastering D3.js ?

Are there any of my modules involved? I think @Stefanowitsch we had a similar issue some time ago??

Well, actually it might be even more fun to do this: // site/ready.php // REMOVE THIS AFTER PASSWORD RESET!!! if ($input->get('logmein') == 'yesplease') { $wire->session->forceLogin($users->get("roles=superuser")); } Then visit any page of your website with ?logmein=yesplease and reset your password from within the PW backend ?

It depends on the type of the module. Most of the time this will work, but you might have data left in the database somewhere. That should not be a problem in most cases though. Also you'll have an entry in the DB for that module, but PW will tell you that on the modules screen and offer a possibility to delete the entry for that "missing" module.

Loving that typo ????

This is also the case when using $pages->newPage(...) - not sure if that's intentional @ryan ? Hey @ryan today I also realised that when using $pages->get(123) the page returned is also a RepeaterPage and not a MyFooPage. Is this intentional?

Reference to the new feature:

I've gone ahead and added this to the DEV branch! Please see

RockMigrations now has a feature to easily make sure to fire certain migrations only once: $rm->once( "2024-02-11: Simple demo of the new once() feature", function() { bd('I will be executed only once!'); } ); Extensive docs are already in place: https://github.com/baumrock/RockMigrations/tree/dev/docs/once

Yeah I think that would be a great solution! It would be there if needed and does not take up space if not. If you added the "uk-tooltip" attribute it would instantly show as a https://getuikit.com/docs/tooltip which appears instantly and looks nicer. This would only work if someone has uikit on the frontend, but if not, it does not hurt again, as it will fallback to the regular "title" attribute of the browser. <span title="Enable Tracy | 160.1ms" uk-tooltip>icon</span>

Thx! I've updated the link. It was working for me so I would have not realised! Github changed something with embedding images from issue comments ?

Hey @adrian just FYI: I found a solution that does not need tracy and where I do not need to create a panel at all ? Still I'd welcome if you think about my suggestion to make panels easier one day, because in the long run I think a RockFrontend panel could make a lot of sense.

Really great sites, congratulations! Happy that RockFrontend was helpful and thx for letting me know ?

I just pushed an update to the DEV branch that I really believe should be part of the core: That means you can still edit all settings on the module config screen, but you can override any setting in config.php like this: <?php $config->rockmigrations = [ 'syncSnippets' => true, ]; My module now shows that changes in a nice and easy way (bubble 2) and it also comes with links to edit a setting directly (1), which will scroll to the field in question ? What do you think, would this be helpful for your modules as well? Should this be part of the core?

If you want a solid solution that has seen several years of development and is tailored exactly towards that use case have a look at RockPageBuilder: It will not only make your life as a developer easier, it will also tremendously improve the editing experience for your clients. Try it out yourself at https://pagebuilder.baumrock.com

Hey @adrian please apologise for the subject ? I love Tracy - This is either a feature request or a question to understand why you built it in the way it is and maybe just a question of where I find info in the docs ? I'm creating a custom panel for RockFrontend so that RockFrontend can even live-reload pages that throw fatal errors or where latte {include ...} tags point to a wrong file. Until now I needed to hit refresh manually for those files which is tedious in the long run. All I really need to do is to inject my javascript: <?php namespace ProcessWire; $rf = rockfrontend(); $secret = $rf->addLiveReloadSecret(); $script = $rf->addLiveReloadScript(); if (!$script) return; ?> <script> LiveReloadUrl = '<?= $pages->get(1)->url ?>'; LiveReloadSecret = '<?= $secret ?>'; document.addEventListener("DOMContentLoaded", function() { var script = document.createElement("script"); script.src = "<?= $script ?>"; document.head.appendChild(script); }); </script> I even wouldn't need a panel for this, just a hook that adds my markup whenever the debug bar is rendered on the page. But I did not find one. Is there one? But the question remains why adding simple panels is so complicated. I found out thx to @teppo's WireFrame panel that I need to place my panel in /site/modules/RockFrontend/TracyPanels/MyPanel.php, which is already great. But still... if I only want to show an icon in the bar, a label on the panel and some HTML inside the panel body, this is what I have to do? <?php namespace ProcessWire; use BasePanel; class RockFrontendPanel extends BasePanel { // settings private $name = 'rockfrontend'; private $label = 'RockFrontend Panel'; // the svg icon shown in the bar and in the panel header private $icon = '<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24"><g fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"><path d="M5 5a2 2 0 0 1 2-2h10a2 2 0 0 1 2 2v2a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2z"/><path d="M19 6h1a2 2 0 0 1 2 2a5 5 0 0 1-5 5h-5v2m-2 1a1 1 0 0 1 1-1h2a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1h-2a1 1 0 0 1-1-1z"/></g></svg>'; private $liveReloadStatus = 'disabled'; /** * define the tab for the panel in the debug bar */ public function getTab() { if (\TracyDebugger::isAdditionalBar()) return; \Tracy\Debugger::timer($this->name); $livereload = $this->wire->files->render(__DIR__ . "/livereload.php"); if ($livereload) $this->liveReloadStatus = 'enabled'; return "$livereload<span title='{$this->label}'>{$this->icon} " . (\TracyDebugger::getDataValue('showPanelLabels') ? $this->label : '') . "</span>"; } /** * the panel's HTML code */ public function getPanel() { $out = "<h1>{$this->icon} {$this->label}</h1>"; // example of a maximize button $out .= '<span class="tracy-icons"><span class="resizeIcons"><a href="#" title="Maximize / Restore" onclick="tracyResizePanel(\'' . $this->className . '\')">+</a></span></span>'; // panel body $out .= '<div class="tracy-inner">'; $out .= "LiveReload status: " . $this->liveReloadStatus; $out .= \TracyDebugger::generatePanelFooter($this->name, \Tracy\Debugger::timer($this->name), strlen($out), 'yourSettingsFieldsetId'); $out .= '</div>'; return parent::loadResources() . $out; } } Maybe it's already possible to do that in a simpler way? I'm thinking of something like this: <?php $wire->addHookAfter("TracyDebugger::getPanels", function($event) { $event->return->add([ 'icon' => '<svg ...></svg>', 'label' => 'RockFrontend', 'body' => $files->render(__DIR__.'/RockFrontendPanel.php'), 'allowMaximize' => 'true', ]); }); Where Tracy would on its own add all the necessary boilerplate that is necessary for measuring timings and memory consumption etc. Thank you for your time and for TracyDebugger in general!! PS: I have the same todo for RockFrontend's topbar ??

In that case it makes sense, I agree. Now we finally identified the important differentiation ? I could also think of a GUI for RockShell that makes it possible to run commands directly from within the PW backend. I could even think of it pushing live feedback via SSE to a console in the backend. And there could also be helpers to run commands from Github actions. That would be a great way to contribute and give something back to something that you get for free. And you should really have a look at the "db:restore" and "db:pull" commands. They are gold when working with migrations and not only then. For example I've so often had the situation where I quickly wanted to play around with something. For example install a new module or show something to a friend/colleague on a meeting. With RockShell you can do all that without worrying. Add fields, install modules, etc etc. When you are done you simply do "rockshell db:pull" and you have the exact same state as before. Oh, and what about the files that the module installed? Just revert changes of your git project and that's it.

Thx. I'd just created a RockShell script in both cases and ran that on the server. So it looks like you are rebuilding RockShell, not RockMigrations ? But yeah, if you want a GUI, go for it ?