bernhard

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 != "")

Maybe {$page->SEO|noescape} ?

https://processwire.com/talk/topic/4452-reset-config-appendtemplatefile-for-certain-templates/

Thx @heldercervantes that's interesting to see! What does the migrations menu item do or look like?

This statement is true for almost any use case ? Back to topic: I like your idea! It would be handy for my workflows as well. I'm developing almost anything that I do in a modular reusable way. That's possible and almost as quick as doing it the regular way thanks to RockMigrations. But storing data for non-public data (pages that are not viewable on the frontend) is one of those things that are a little tedious to build. You always have to create a parent template and a child template, then link both together, etc... Though I'm not deep enough in the topic to know how exactly that could work. For example I've never used the ProfieldsTable module which sounds like it's doing something similar? At least for my case I'd also need the possibility to create custom tables, not only read them. Or is that exactly what the table field does and you are talking about only reading existing tables? Couldn't we build somthing that supports both needs? Just brainstorming/asking... ?

RockFrontend will have a render() method that can render latte files. In my setups the main markup file is PHP and there I just use something like this: <head> <?= $rockfrontend->styles('head') ->add('my/theme.less') ->add('foo/bar.css') ->render() ?> </head> <body> <?= $rockfrontend->render('sections/header.latte') ?> <?= $rockfrontend->render('sections/main.latte') ?> <?= $rockfrontend->render('sections/footer.latte') ?> </body> Then I have empty PHP files for each template so that PW knows that these templates are viewable on the frontend. Ugly, but that's how PW works. Latte docs show how you can render latte files here: https://latte.nette.org/en/develop