bernhard

Hey @adrian Today @netcarver requested to make RockFrontend's livereload work on tracy error pages - which is something that has been annoying for myself for a long time: https://github.com/baumrock/RockFrontend/issues/25 The problem is I've really tried hard to do so, but I can't find a way to modify the markup of the rendered page ? LiveReload in RockFrontend works simply by having this markup on the page: <script> var LiveReloadUrl = '{$this->wire->config->urls->root}'; var LiveReloadSecret = '$secret'; console.log('Loading LiveReload'); </script> <script src='$src'></script> Any ideas how we can get this working? I even tried using Debugger::$customBodyStr = "TEST"; and similar, but that doesn't seem to do anything at all, though I see you are using it in your module? I'm totally lost here and hope you have a simple solution to finally get rid of these annoying manual reloads on error pages ? Thx in advance! PS: This is actually the same request as this one just with different wording: https://processwire.com/talk/topic/29555-why-is-it-so-complicated-to-add-custom-panels/ I mentioned in that post that I got it working, but I can't find the working version any more of I just thought it was working but it actually didn't... PPS: I'm talking about these pages:

Hi @incognito.ms thx for using RockPageBuilder ? This is just a shortcut for this: $page->rockpagebuilder_blocks->render(); That means it will render the default RockPageBuilder field that you get when installing RPB. If you add additional custom RPB fields (lets say "foo" and "bar"), you can simply render them like this: $page->foo->render() $page->bar->render() So you could have a 3 column layout like this: <div id="left"> <?= $page->foo->render() ?> </div> <div id="main"> <?= $rockpagebuilder->render() ?> </div> <div id="right"> <?= $page->bar->render() ?> </div> https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/blocks/#rendering-blocks Does that help?

RockPageBuilder has the concept of "Widgets". You can turn every "Block" (similar to a repeater matrix element) into a widget with one click. Then on any other page you can add a widget block and select the original item to be displayed. This is handy for situations where you want to reuse content elements across your site, but want to manage the content at one central place. An example could be a "contact us" element or a "donate now" element where you'd maybe want to display that element on hundreds of pages but want to change the phone number or bank account only once. A RockPageBuilder block can be text but also just an image field. So having an image block, uploading an image and then turning it into a widget would make the use case that you describe possible. As always this comes with a downside. It would then not be possible to show different versions of that block. All would be 100% identical. You could build the same concept on your own with RepeaterMatrix as well. After all it's just a page reference field and an some additional logic to not render the reference directly but render the referenced source. Actually that can get quite tricky, but that's another story ? So as always in ProcessWire it's up to you how you do what you need and it depends on the exact use case what is the best solution. There is no one-size-fits-all solution for what you describe and I think as @wbmnfktr mentioned uploading images multiple times might be the most native solution and is often really not bad and comes with other benefits.

Thx, I've updated the first post and the thread title!

Hi @netcarver thx, this feature has been moved to RockSettings. Could you please let me know where you found the outdated info, so I can remove it?

Hi @netcarver thx for helping to improve RockFrontend ? Done in the latest commit on the dev branch ? This pops up as soon as you add {alfred(...)} somewhere in your markup and the module is not installed. I've also added a note in the docs.

Great to hear that ? This is interesting. I've never really had the need for that - maybe because RockPageBuilder is doing that for me and I don't need it at all on frontend editing - but I'm wondering if a module setting could make sense. I could think of a checkbox "trigger frontend reload on page save", or maybe a config setting. A config setting could have a page selector that checks if the saved page matches the selector and only reloads if it's true. But I'm also wondering how that feature would be used and by whom. Would it be a developer thing? Or could it maybe also be useful for regular site editors? So far Livereload was really only intended for local development, but the technique has been quite reliable and should work with any infrastructure as SSE + JS is available everywhere...

Done

I don't understand the question and it's probably a bit offtopic for a "why I love latte" thread ? But you can use regular PW API inside Latte. That's why latte is so great, it parses templates to regular PHP so you can do anything that PHP can do. Though this should be used with caution, as you should also try to keep your latte files clean, so whenever you need more complex logic use custom page classes and put the logic there in a custom method, so you can do {$page->my_custom_dropdown_value()} for example. If it's simple you can do {$page->parent->dropdown_value} instead.

Thx @Entil`zha I've added a warning to the docs which will be visible soon on my website. Could you please change the topic title to [solved] ... ? Thx and have fun using RockPageBuilder ?

Me too, thx ? I have to get used to these new nullsafe operators ?

Hi @Entil`zha, sorry for the trouble! Do you have frontend editing permission? It looks like you don't, so ProcessWire will not load jQuery and all the suff necessary for the modal to pop up.

You have to check what $page->category->value actually is. You can do that with {bd($page->category->value)} If that outputs "" or null, then you can do n:if="$page->category->value" Likely it will be something else that only looks like a string when using "echo" but behind the scenes it's actually a PHP object. For example the root page in PHP is a "Page" object but echo $page prints "1". This is an exact match, maybe it already works if you use the != operator instead of !== That would tell the comparison to allow the value being converted to "string" before comparison, because you compare it with a string. The same happens if you do this: $page->template === 'foo' will always be false $page->template == 'foo' will be true if the name of the template is "foo"

Thx, I've added this to the module's info.php as requirement Thx, I've pushed that "fix" to the module ?

Hey @FireWire thx for your message! What you are seeing here is the RockFrontend topbar. That is coming from RockFrontend, not RockPageBuilder. Where do you render that formbuilder form? What kind of iframe is that? It looks like a modal. Do you show a form in a modal popup? The topbar is added here: https://github.com/baumrock/RockFrontend/blob/67fcccee9295c81716c133f9ac28ce3ff3b5dcba/RockFrontend.module.php#L278 You know more about FormBuilder than I do, so if you tell me how we can identify that we are in a FormBuilder iframe than we can catch that situation and prevent rendering the topbar. Maybe we can even find a more general idenifier that also works for other situations like iframes in general, as you mentioned. Input/Ideas welcome ?

The RockFrontend site profile for ProcessWire offers a unique combination of benefits by integrating UIKit and TailwindCSS, making it an appealing choice for developers looking for both robust UI components and extensive customization capabilities. Here are some key advantages: Rich UI Components from UIKit UIKit is known for its comprehensive collection of high-quality, ready-to-use UI components. This integration in the RockFrontend site profile allows developers to quickly implement complex components like modals, accordions, and sliders that are visually appealing and functionally robust. Flexibility and Customization with TailwindCSS TailwindCSS is a utility-first CSS framework that provides high granularity in styling elements. It allows developers to build custom designs without stepping out of the framework’s constraints. This can significantly speed up the development process, as it eliminates the need to write custom CSS from scratch. Setup Setup is as simple as these 3 steps: Download the profile Install ProcessWire and choose this profile Follow the instructions on the welcome screen Github: https://github.com/baumrock/site-rockfrontend Modules Directory: https://processwire.com/modules/site-rock-frontend/

Your version of PW seems to not have versionUrl on the $config variable. Can you update PW to a recent version?

Great so see someone else working with ReactPHP as I'm also evaluating it for a new Project ? Thx for sharing! Though I feel a little tracked now ?

Hey @Klenkes thx and sorry for that, forget to check a checkbox after the RockForms update ? It should be working now, please check!

Hey @iank sorry for ignoring this post for so long and thank you very much for the great feedback. Really glad you like it and hope you still do ? Thx to @FireWire the latest version of RPB v5.3.2 contains a fix for that issue ? For anybody interested: The reason for the issue is that whenever a RPB item is saved we need to also process all changed items. I was doing that by adding all block-fields to an InputfieldWrapper element and then calling ->processInput($wrapper). This worked well, but it does not support showIf, as FireWire explained to me. So he changed it to use InputfieldForm instead and now everything works as expected. Let me know if everything works and please mark the topic as [solved], thx ?

Thx @iank and @Klenkes please grab version 5.3.2 which has the fix provided by @iank - thank you very much!!! ? PS: Please mark the topic as [solved] again, thx ?

Hey @protro thx for mentioning Consenty and nice to see it in action ? I've checked your site again and you are still connecting to a youtube server even though consent is not given. The reason is this code: <template consenty-if="!youtube-inline"> <div class="uk-inline"> <img src="https://img.youtube.com/vi/JJmsPuB1NxE/sddefault.jpg"> ... </div> </template> This markup gets loaded if we do NOT have consent for "youtube-inline". But as you are embedding the thumbnail from the youtube url you are sending data to them without users consent. I know it's annoying... ?

Ok, sorry, clickbait ? Hooks are great! But sometimes, there are even better solutions: I'm cleaning up RockForms to finally release it ? I have some pages that are only for storing data (like form entries and such), so I don't want them to be editable, not even for superusers, as I control them solely via code in my module. -- Solution 1 -- With a regular hook that would look like this: <?php // site/ready.php $wire->addHookAfter("Page::editable", function($event) { $page = $event->object; if($page instanceof \RockForms\Root) $event->return = false; }); That's quite nice, but this approach has some drawbacks: First, sooner or later you might end up with hook-hell in ready.php; That's not ideal and really hard to debug on more complex projects. Second, as we are defining the hook with a callback in a non-OOP style these hooks get a LOT harder to debug! Have a look at tracy's debug panel: The second highlighted hook is the one coming from ready.php and it does not show any helpful information whereas the first one does show clearly that the hook is attached in RockForms\Root in the method "hookUneditEntries" (it should be hookUneditRoot, but I made a mistake when copy-pasting, sorry ? ). -- Solution 2 -- So the next best solution IMHO is using custom page classes! Then you get OOP style and a lot better structure for your project with really very little effort! Just create a file in /site/classes and that's it. Now to attach hooks directly in custom page classes you have to do one additional step. You can watch my video about this if you are interested. If not, head over to solution number 3 which is even simpler ? This solution might look something like this: <?php namespace RockForms; use ProcessWire\HookEvent; use ProcessWire\Page; use RockMigrations\MagicPage; use function ProcessWire\wire; class Root extends Page { use MagicPage; public function init() { wire()->addHookAfter("Page::editable", $this, "hookUneditRoot"); } protected function hookUneditRoot(HookEvent $event): void { $page = $event->object; if (!$page instanceof self) return; $event->return = false; } } This might look like a lot more code, but it's a lot better in the long run in my opinion as things that are related solely to the root page are inside the Root.php file of my module/project. -- Solution 3 -- But then I remembered: As our "Root"-page is a custom page class and PW checks if the page is editable or not by calling $page->editable() we can simply override this method like so: <?php namespace RockForms; use ProcessWire\Page; class Root extends Page { public function editable() { return false; } } You don't even need to make it a "MagicPage" because you don't need an init() method to attach any hooks. Now it's only very little additional code compared to a hook in ready.php but with a lot cleaner setup ? It's not a new invention, but I thought I'd share it nevertheless. Maybe it's helpful for some and maybe it's a good reminder for others, that even hooks are sometimes "overkill" ?

Have you ever had to revive an old project for whatever reason? Was it a pain to get it up and running, because you switched to a totally new laptop in the meantime? I had this situation today and it was no problem at all thx to DDEV ? --> got an error that DDEV can't boot up the project because the path changed from /my/old/laptop/projectX to /my/new/laptop/projectX But it also showed the solution: And then again: --> Browser popped up, table xy not found - well yes, obviously I don't have the database on my new laptop! Boom, everything works! With a quite old project with a quite outdated version of PHP ??