bernhard

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 ?

Thx for trying to explain the details. I understand you well. This is why I built RockMigrations. On the last sentence I'm losing you. I'd still be interested in a detailed example of what you are doing and where this is necessary and why. You are explaining extensively the same workflows that I'm using and then you suddenly state that something is missing without going into detail. For example: How to you execute these snippets? Who does it? Did you think of any different approaches? Why do you think this has not been an issue for me so far?

Sounds cool! I understand the need for what you are working on and I'd even be happy to add such features to RockMigrations, if you want and think that could make sense, but more on that later ? That was confusing for me because it's wrong ? Not trying to be know-it-all but it might be interesting for you to know that I tried to put all the method arguments in the order of how the method is named, so add-FIELD-to-TEMPLATE means field first, then template. Using PHP8 with named arguments that not that important any more, though. So back to topic. What you are trying to do have actually been my very first approaches when working with migrations. That's how they work everywhere after all. RockMigrations1 even had downgrade() and upgrade() methods and some version_compare to see if migrations should run or not. The reason why I completely removed that was because it has been so much more productive to use just config-based migrations in my daily work. Rather than writing all the logic around the actual migration to make sure migrations are only executed once I made sure that no matter how often they run they produce the same result. That works great in 99% of my use cases, though there are situations where it does not and I admit it's not terribly beautiful ? So for example if you have fields added via RockMigrations that you don't need any more you'd do this: <?php public function migrate($rm) { // cleanup $rm->deleteField("old_fieldname"); // actual migration } So while this would just work it's really not beautiful and it would log "Field old_fieldname not found" on every run. You can prevent that by adding TRUE as second parameter, but it's still not really beautiful. I've also thought of adding something like this: <?php public function migrate($rm) { // cleanup $rm->once(function($rm) { $rm->deleteField('old_fieldname'); } } The problem here is: How does RM know, what that "once" means? What if it fails? What if inside the once was multiple steps like in your example, for example looping over 100 pages and after 50 it breaks? What do you in your module in such a case? What I've done in such cases was to create an import script based on RockShell that I could run whenever needed. Manually. In the best case only once ? I could also run this script locally as often as I want, try everything out, see the result, and if it's not working I'd just do "rockshell db:restore" and try it again. Once everything works I push to production and run the script there. This is what your script would look like in RockShell: <?php namespace RockShell; use function ProcessWire\rockmigrations; class DemoMigration extends Command { public function handle() { $rm = rockmigrations(); $rm->createField('richtext', [ 'type' => 'FieldtypeTinyMCE', // ... ]); $rm->addFieldToTemplate('richtext', 'basic-page', 'textarea'); $pagesToUpdate = $this->wire()->pages->find('template=basic-page'); foreach ($pagesToUpdate as $pg) { $this->write("Updating page #$pg ..."); $pg->setOutputFormatting(false); $pg->set('richtext', $pg->textarea); $pg->save(); } $rm->removeFieldFromTemplate('textarea', 'basic-page'); $this->success("Hooray - we are done :)"); return self::SUCCESS; } } Put that in /site/assets/RockShell/Commands and you are good to go. I'd also really be interested in how you work with docker. I've seen https://github.com/poljpocket/processwire-docker and your statement sounds very interesting. So I'd love to hear more about that if you find time.

Hey @adrian could tracy show the execution time of the page even when tracy is toggled off? I think it would be nice to see this to get a feeling of how fast the website is for public users. Tracy and all the panels sometimes make sites a little slower, so I sometimes toggle it off completely, but then I don't see the loading time any more. Would that make sense? What do you think?

I've literally yesterday thought of adding this to RockFrontend! I thought I'd add /site/templates/htmx and whatever file you place there would be available as yourdomain.com/htmx/[filename] So for example placing modal.php there you could use hx-get="/htmx/modal" What do you think? Not sure what you mean by JSON api support. Maybe I'm missing something?

This feedback is so great, I have to share it with you ? Thx so much @FireWire and thanks for brilliant fluency module!! Just pushed v5.2 to the main branch!

Yeah, with more complicated things stackoverflow is often still nicer, because you often see that some solutions are outdated and there are better solutions in 2024. You often don't see that in AI, as it just presents you the solution that it thinks is the best. But for things like "oh yes, 644, why did I even ask" it's a lot more efficient to ask the AI inside cursor and not Google. From my first month of using cursor I'm a little shocked how much I am using it and how much I must have been googling before ?

Of course you have to check. It's the same with any source... AI, web, manual, other devs... You always have to think about what they tell you and then you have to decide what you do and take the responsibility for your actions. Cursor gives you the option, it does not fire the command by itself. If it did I wouldn't use it.

It really helps with all the little annoying time consuming tasks. Ever forgot what the chmod command is to set permissions to "-rw-r--r--" ? Or even faster: Just hit CMD+K and type this: It will present you with this terminal command: Hit CMD+Enter and done ✅

What would happen if anybody uploaded such a zip to a regular user's file field? It would still be a zip, right? Isn't there a setting to automatically unzip on upload? Would that be a problem? I guess no, right? It would just unzip it and then we'd have a .php file in the field, but I think that would need to be allowed in the field settings. And even if allowed I don't think pw would at any time execute this file?

Using RockFrontend you could also do this, for example inside a saveReady hook: <?php use Wa72\HtmlPageDom\HtmlPageCrawler; $dom = rockfrontend()->dom($page->body); $dom ->filter("a") ->each(function (HtmlPageCrawler $node) { $href = $node->getAttribute("href"); if (!$href) return; if (strpos($href, "http://") === 0) return; if (strpos($href, "https://") === 0) return; $https = rtrim($this->wire->pages->get(1)->httpUrl(true),"/"); $node->setAttribute("href", $https.$href); }); $page->set('body', $dom->html()); I've added docs for it on the dev branch: https://github.com/baumrock/RockFrontend/tree/dev/docs/dom

Hey Ryan, thx for all the updates and congrats on the launch! I am seeing a horizontal scrollbar on screen sizes around 850-900 in chrome, but only when I size the window without devtools!