bernhard

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

I don't think there's a plug and play solution, but you might be able to (ab)use ALFRED for that scenario... So you could just develop the display part via regular PHP/HTML and the edit part via quick-edit-links from ALFRED:

FYI RockFrontend is finally there ?

RockFrontend is finally there ??

Modules Directory: https://processwire.com/modules/rock-frontend Github: https://github.com/baumrock/RockFrontend

Ok thx for clarification ? That sounds like it's something out of the scope of rockfrontend, but it also sounds like it's nothing that I really have to worry about...

I have tried that twice. The first try was for a client and I implemented everything in PHP. That kind of worked and it still works... But I don't really like the solution because it feels very old-school. The second one was a great implementation using alpinejs for reactivity for the cart, very similar to snipcart. Very nice gui and look and feel (using uikit). I wanted to use snipcart first, but I was not able to get that running with things that seemed to be quite common requirements. So I started building my own solution. But the project was never finished. So we kind of failed with that second try. What I realized: I totally underestimated all the things that are necessary to build such an "easy cart + checkout" thing... And I guess it was the same thing for padloper1 (which was abandoned) and padloper2 (which was delayed for a year or so?). That's no offense in any way, it's just a warning that you might be underestimating things as well ? Take the screenshot below: What if the user wants to change the cart at that step? What if he/she enters wrong details? What if you need coupons? What if the payment fails? What if you need multiple languages? etc etc... But if you want to build it, go ahead. I'm always a fan of doing things on your own. I just have a feeling that this statement is a little... underestimating things... that's all ? I guess that both snipcart and padloper are easily worth their price ?

Hey @MoritzLost that statement confuses me a little bit. What I'm doing is simply having a main markup file in PHP (_main.php) and from there I render template files (LATTE, Twig...). That's a super simple setup and I can't see any reason why this should break with any future PW update. All the other template engine modules for PW seem to use a different approach, more or less completely replacing the rendering strategy of PW if I understood that correctly? Do they? I don't really understand what's going on there to be honest, as I've only been using my simple approach which has worked extremely well. Though I might be missing something important here? There might be a reason why a more complicated approach is preferable over my slimmed down one? I have the same problem with translating strings, but there are easy workarounds (either manually or there is also one built into $rockfrontend->x('my_translatable_string')). Thx for your insights!

@wbmnfktr FYI I've just added support for Twig in RockFrontend <?= $rockfrontend->render("sections/header.twig") ?> It will also be easy to add any other template engine: // put this in site/ready.php // it will add support for rendering files with .foo extension // usage: echo $rockfrontend->render("sections/demo.foo") $wire->addHook("RockFrontend::renderFileFoo", function($event) { $file = $event->arguments(0); // implement the renderer here $event->return = "Rendering .foo-file $file"; }); I swear I'll release it very soon ?

It still looks like it's doing the exact same thing to me? {dump $site} {bd($site)} I'd hoped that your version might make the click below the dump work so that I end up at the correct line in my latte file, but it always leads me to the cached/compiled version of latte...

No, because $block is a rockmatrix block having an items() method but not having an items property. Same goes for content(). The whole block will only render if there are items using RockFrontend's renderIf() method: $rockfrontend->renderIf("sections/newsitems.latte", $block->items()) Thx for letting me know ? Though personally I don't see any benefit in using another syntax if I can simply use plain PHP (which I already know)...

Usually methods do something and properties hold a value. So $pages->count() would be a method whereas $page->id would access the id property of the page object...

You don't know what to use when because ProcessWire does some magic here to make both versions work most of the time. For example the method to get children of the current page is $page->children() (https://processwire.com/api/ref/page/children/) but $page->children will work as well. ProcessWire does that using magic methods (https://www.php.net/manual/en/language.oop5.magic.php) so when you request $page->children it will check if a method "children" exists and will call that method for you even though you are accessing it as a property and not as a method. So requesting the method directly might be slightly more efficient, but in most cases I guess it will not matter. And imho using the "property syntax" like $this->wire->files->render() is cleaner than always using methods. $this->wire()->files()->render()...

Also note that modern IDEs do that automatically for you once you start writing "new Client" in your code ?

We do ? Sometimes. It has pros and cons. The problem with clients uploading logos is that it can make troubles (eg rendering SVGs in different browsers). The safe way is to put it into something like /site/templates/img/logo.svg and use that logo instead. That also has the benefit of having the logo in version control, as it's imho more part of the software than user content. But I guess there is no right or wrong here...

Want to share some examples with us? ?

Nice, thx for sharing! Just played around a little with your code example... This version is using array-syntax ? $find0 = $pages->findIDs("title*=home"); $find1 = $pages->findIDs([ ["title", "*=", "admin"], ["id", "!=", $find0], ]); $find2 = $pages->findIDs([ ["title", "*=", "modules"], ["id", "!=", array_merge($find0,$find1)], ]); $final = $pages->find(["id.sort" => array_merge($find0, $find1, $find2)]);

I think you could also hook Field::getInputfield() instead of Inputfield::render() and set your options there. They should then also be available in processInput, but I have not tested what I just said so I might be wrong ?

https://stackoverflow.com/a/200666 Thanks for forcing me to look that up, and I'm happy I'm safe with my preferred way of writing php using <?php and <?= ? Update 08/2022: Now my favourite way is using LATTE via RockFrontend: {$page->title} instead of <?= $page->title ?> ?

I'm not sure if that is possible with a selector, but a workaround would be to add a second hidden field to your template and create a hook that populates that field on save or saveReady. Then you can simple use a selector like this: $pages->find("template=yourtemplate, your_hidden_reference_field=$yourpage");

Hey @Greg Lumley I wanted to finish my video about RockFrontend last week or weekend, but it turned out to be a lot more time consuming that I thought ? Yesterday I even realised that some parts of RockFrontend could be improved even more, so I decided to do some important updates before finalising the video. I love those new additions ? To get live reloading for example is now really just installing the module and adding "$config->livereload = 1" to your PW site ? No injecting of scripts whatsoever... Back to topic: Today I had to build an accordion content-element: <ul> <li n:foreach="$block->items() as $item"> <a href="#">{$item->title}</a> <div>{$item->content()|noescape}</div> </li> </ul> IMHO it can't get any cleaner ?

great site, thx for sharing ? congrats to the lighthouse score ? maybe add a little spacing here?

The docs say $page->seo and not $page->SEO https://processwire.com/modules/seo-maestro/ Other than that I have no idea what could be going on ? Though tracy debugger helps a lot in such cases using bd()

There is no "blank" keyword in PHP Try this: if($page->hp_content_rep != "")