bernhard

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

The idea was that RockMigrations could save at least module config settings to yaml files. I'm still not a fan of putting migrations in general into yaml files, because the execution order of migrations can matter and that's not possible to do in yaml while it is possible to do in PHP. But for module configuration I guess YAML would be an easy thing. So one could for example could install tracydebugger, do all the necessary config and hit save. Then all developers working on the project could have the same debugger settings. That might be a good thing (for module settings that need to be consistent across all environments), but it might be something you don't want. Again that's a problem that is not easy to solve and that's the reason why I think it makes the most sense to write migrations by hand.

Yeah I was just hoping you have some experience with it and have done the review before so I don't have to do it ?? Proper image handling is something on my list and it's definitely something that I'd want to have in RockFrontend. The goals is to have a module that makes all the tedious frontend tasks easier and more efficient. srcset would be a perfect example and image handling is on my list for quite some time now, but I don't even have experience with webp at the moment so I might not be the best person to implement such a feature ? Let's see what you guys think of RockFrontend once it is published and then maybe someone wants to contribute... Thx for the suggestions ?