bernhard

v1.17.0 adds a nice helper to download webfonts automatically to /site/templates/fonts Austria is hit by a wave of legal letters demanding 190€ from website owners that serve google webfonts from the google servers directly instead of self-hosting them. Selfhosting fonts on the other hand is tedious!! I know there is the google-webfonts-helper, but I wanted something better integretad into my PW workflows. So RockFrontend now downloads all the necessary files for you (eot/woff/woff2/ttf/svg) by sending separate HTTP requests to google with different user agents and saving the fonts with a readable name to /site/templates/fonts Simply paste the url and hit save:

You guess correctly. The init() and ready() methods of a module can only correctly fire on "init" and "ready" if the module is either an autoload module or you load your module early enough in the ProcessWire boot process. If you load your module the very first time in a template file, then you are already in the Page::render() process, so you can't attach a hook to Page::render() since that has already been triggered! Does that make sense? Your module's init() method is called at the moment when you load your module via $modules->get(). That means it looks as if it works properly, but it actually fires a lot later than the autoload ready() and init(). You can check that by adding bd('site/ready.php') in /site/ready.php and the same in /site/init.php; You should see output like this: site/init.php site/ready.php --- Page::render() happens here --- your module's init your module's ready If you change your module to an autoload module (as the docs that you have read suggest ? ) the output should look like this: site/init.php your module's init site/ready.php your module's ready --- Page::render() happens here --- That means the hook that you attach in your module's init() or ready() will be available when the Page::render() is triggered and the hook should fire properly.

That means that your module is initialized 3 times and it does not have the setting "singular" to true. You can have singular modules that should only be initialized once (like rockfrontend for example) or non-singular modules, that can be initialized several times (like for example all the inputfield modules, where you want to use one module several times with different settings). // site/ready.php $wire->addHookAfter("Page::render", function(HookEvent $event) { bd("hook fired"); }); I just tried this hook in ready.php and everything works as expected. Just do that on your end and than change things step by step towards your desired solution. Once things break you know where the bug sits and you can fix it. Or as for help with a more detailed error description. How to you initialise your module? Manually? Or is it an autoload module? Did you read the docs about modules? https://processwire.com/docs/modules/development/

I don't know what the problem is you are describing, it sounds strange. But don't delete those modules!! You need them for the PW backend to work!

First of all the better you describe your problem the better our answers can be ? That's not really a helpful description. But as you don't share more specific infos, this is what I'd do: Inspect the html code of your page and also the network tab and console of your browsers devtools Install TracyDebugger and add this to your ready.php: bd("ready"); You should see the "ready" dump in your tracy debug bar Add >> bd("module init"); << inside the init() method of your module and reload the page You should see the dump in the bar and that confirms that your module loads properly Then add >> bd("inside hook"); << at the top of your hook to make sure your hook code fires properly.

No, sorry. Sometimes I have network problems as well (not related to livereload though) but restarting ddev/docker/my laptop has always helped ? Glad to hear that ?

I've improved the render method even further, so as from version 1.15.7 you don't need to add the |noescape filter any more when rendering a file via the render() method ? Also I've added support for a shorthand variable submission that is very handy for rendering lists (like blog post overview or such): <div class="uk-child-width-1-2@m" uk-grid> <div n:foreach="$page->children as $item"> {$rockfrontend->render("partials/card", $item)} </div> </div> That makes $item available as $page in card.latte ?

Not sure if that is still supported and safe to use? @David Karich ?

Jep, that's the main advantage and it supports short paths like "sections/header". But under the hood it's just using PW's render() method ? Yes, I agree and I'm open to any suggestions for which libraries to use for that purpose as I have no experience with that. For minification of CSS we could simply use the Less module. JS is a different story though...

v1.15.4 adds support for rendering RepeaterMatrix fields easily: RockFrontend and RepeaterMatrix While you can always render repeater matrix fields manually RockFrontend has some nice helpers. This is the long and manual way of rendering a matrix field: // main.php foreach($page->your_matrix_field as $item) { // render every block and make the $page variable be the current block // instead of the viewed page. echo $rockfrontend->render("/matrix/".$item->type, ['page' => $item]); } // matrix type foo (/site/templates/matrix/foo.php) <h1><?= $page->title ?></h1> Or simply use the shortcut: echo $rockfrontend->render($page->your_matrix); // or in a latte file {$rockfrontend->render($page->your_matrix)} // example matrix block: /site/templates/fields/your_matrix/foo.latte <h1>Foo block having id {$page->id}</h1> Note that when using $rockfrontend->render() to render matrix fields you can also use latte files for rendering and the $page variable in the view file will be the current matrix block instead of the currently viewed page. If you need to access the current page you can use $wire->page instead of $page.

Just added some docs about the render method as @wbmnfktr had troubles using it. Hope that helps: The render() method One of the fundamental concepts of RockFrontend is its render() method. Whenever you want to output markup just use render() and provide the file you want to render as first parameter: <?= $rockfrontend->render('/path/to/your/file.php') ?> If your file lives in /site/templates you can use short paths: // will render /site/templates/sections/head.php <?= $rockfrontend->render('sections/head.php') ?> Your rendered files can be PHP or LATTE syntax. You can add other template engines easily (see below). Variables in rendered files All PW API variables will be available in your rendered files: $rockfrontend->render('sections/foo.php'); // sections/foo.php echo $page->title; echo $config->httpHost; echo $pages->get("/bar")->createdUser; echo $user->isLoggedin(); Custom variables in rendered files Note that render() works different than PHP's include or require! This is best explained by an example: $foo = 'foo!'; include "path/to/your/file.php"; // file.php echo $foo; // echos "foo!" Whereas when using $rockfrontend->render() it works differently: $foo = 'foo!'; echo $rockfrontend->render("path/to/your/file.php"); // file.php Current page id: <?= $page->id ?> // this will work Value of foo: <?= $foo ?> // foo is not defined! But you can provide custom variables easily: $foo = 'foo!'; echo $rockfrontend->render("path/to/your/file.php", [ 'foo' => $foo, 'bar' => 'I am the bar value', ]); // file.php value of foo: <?= $foo ?> // outputs foo! value of bar: <?= $bar ?> // outputs "I am the bar value" You can also make all defined variables available in your rendered file, but note that this might overwrite already defined API variables (like $pages, $files, $config...) so use this technique with caution: echo $rockfrontend->render('/path/to/your/file.php', get_defined_vars());

Hey @Boost it sounds like you have done a lot of research but never installed PW for testing? If so than just do it as this might help in understanding everything better ? ProcessWire has the concept of Pages, Templates and Fields. Note that the term "template" is very different to other systems like wordpress, where a template is an installable design. In PW the template defines the fields that the user can use for storing content. So when creating a new Page, you can select different Templates which means that on the next step the user can populate the fields that belong to the selected template. For example a boat template could have fields "title (name)", "year", "length", "cost" and the template blogpost could have fields "title", "body", "images" The visual representation of the template is done via template files that are stored in /site/templates. So the "boat" template would render the template file "/site/templates/boat.php". So far to the technical background. I guess that your question is not "can I choose different templates when writing a page" but rather "can I choose different layouts when writing a page"? So your client would create a new blog post having template "blogpost" for example. But then he/she can choose between layout1/2/3. You could do that by simply adding an options field holding all the possible options and then in your template file (/site/templates/blogpost.php) you do something like this: <?php include __DIR__."/layouts/" . $page->layout . ".php"; Which would make it render /site/templates/layouts/layout1.php for the selected option "layout1" of your blogpost...

Where? Thx fixed it ? Yeah, that's an improvement ? It's always good to add a note somewhere when doing magic via hooks to make debugging easier!

v1.15.2 exposes all variables defined in /site/templates/_init.php to all your rendered template files (latte/twig...) thx to @wbmnfktr https://github.com/baumrock/RockFrontend#using-the-sitetemplates_initphp-file

I recommend starting with uikit ? Note that this post is not intended to start a fight on which one to use as this is always a matter of preference, but here are my pro's for using uikit ? You have plenty of ready to use ui components (as with any other framework): https://getuikit.com/docs/introduction You can use RockFrontend to get a 1-click-downloader as well as a solid setup and an example video to get you started: https://www.youtube.com/watch?v=7CoIj--u4ps The PW backend does also use UIkit, so knowing UIkit will help you a lot when customizing the PW backend to your needs (either via CSS/LESS or when implementing custom admin pages) UIkit has longer release cycles than bootstrap for example so for mee it just feels more solid than bootstrap for example, but that's very opinionated of course...

Extending on this... Would it be possible to get the API for this into the core? So that others can build modules that benefit from this feature? Like page builders for example? Hope I'm not asking too much here, but just wanted to say that this could be a quite helpful feature for my upcoming page builder module... Though I'm really not sure, as I don't know the module at all and how it works, so take this with caution ? Maybe we could have the API in the core for others to build on top of it (like adrian with his forms and me with my page builder) and for everybody just wanting a plug and play "page-edit-notifications" there would be the pro module?

Yeah it got 5 changes in your example! Can you try to exclude those files/paths in livereload.php in your pw root? <?php namespace ProcessWire; $exclude = [ 'your/path1', 'your/path2', ]; include __DIR__."/site/modules/RockFrontend/livereload.php"; Does that work?

Welcome to the forum! I hope you enjoy Processwire as much as I do ? That's a little hard to say... In general you can build great websites without any paid pro module. ProcessWire is at its heart a content management framework that helps us developers build what our clients need and Ryan is always happy to put everything into the core that is necessary to make that work. Pro modules are in general either making things easier for us devs (so instead of coding something on our own we can just pay some money and get the result instantly) or make things more performant, for example my only paid (almost)must-have module is ProCache: https://processwire.com/store/pro-cache/#procache-html-output-caching-xml-or-json-too Have fun ?

Thx @Spiria for your kind words ? ? I'd need more information for that... What OS are you using? What browser? What does the devtools say? etc... Are you working with DDEV? XAMPP? Laragon etc..?

v1.15.0 improves debugging even further and shows where the assets have been injected ? <!-- loading /var/www/html/site/assets/RockMatrix/matrix/QuoteSlider.less --><!-- RockFrontend.module.php:365 --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Spacer.less --><!-- RockFrontend.module.php:365 --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Team.less --><!-- RockFrontend.module.php:365 --> <link rel='stylesheet' href='/site/templates/bundle/head.css?m=1660221858'><!-- less compiled by RockFrontend --> <link href='https://use.typekit.net/zeg8qpc.css' rel='stylesheet'><!-- _main.php:5 --> <link href='/site/modules/RockFrontend/Alfred.css?m=1660215428' rel='stylesheet'><!-- RockFrontend.module.php:152 --> <!-- DEBUG enabled! You can disable it either via $config or use $rf->scripts()->setOptions(['debug'=>false]) --> <!-- autoloading of default scripts enabled - disable using ->setOptions(['autoload'=>false]) --> <!-- rockfrontend-scripts-head --> <script src='/site/modules/RockFrontend/livereload.js?m=1660249767'></script><!-- RockFrontend.module.php:197 --> <script src='/site/templates/uikit-3.15.2/dist/js/uikit.min.js?m=1659941286' defer></script><!-- _main.php:8 --> <script src='/site/templates/uikit-3.15.2/dist/js/uikit-icons.min.js?m=1659941286' defer></script><!-- _main.php:9 --> <script src='/site/modules/RockFrontend/lib/alpine.min.js?m=1660215427' defer></script><!-- _main.php:10 --> <script src='/site/modules/RockFrontend/RockFrontend.js?m=1660215468' defer></script><!-- _main.php:11 --> <script src='/site/modules/RockFrontend/Alfred.js?m=1660250581'></script><!-- RockFrontend.module.php:151 -->

Counter-question: Are you sure you want to have that setup on the backend? In my experience it is much easier to just save all events under one single parent (eg Events / EventItem) and just let every event have one date field. Then you can easily sort by this date field and do filters etc (like showing only future events). Also changing the date for example would be much easier than changing the date of the event and then additionally having to move the page in the page tree to not get false results (eg an event from august showing up in july)...

What do you think about adding a feature to merge scripts and styles? Is that something we should have? Or is it even bad to have since HTTP2 can download multiple assets in parallel?

Thx to another request by @wbmnfktr and issues that I had on my own project I've improved asset handling, autoloading and debugging in v1.13.8 It also adds a new method to prepend() scripts and styles (like uikit.theme.less in the example below). Adding something like addAfter('mystyle.css', 'theme.css') is on my list... A default <head> can now look like this (note all the html comments that should be quite helpful): <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <!-- RockFrontend SEO by baumrock.com --> <title>Home</title> <meta property="og:title" content="Home"> <meta name="description" content="Home"> <meta property="og:description" content="Home"> <meta property="og:image" content=""> <meta property="og:image:type" content=""> <meta property="og:image:width" content=""> <meta property="og:image:height" content=""> <meta property="og:image:alt" content="Home"> <script>let rf_livereload_secret = 'rDksCMGEMFs87mNq3WrTaVug1tfeldQ0r9L4kUkfqghS'</script> <!-- DEBUG enabled! You can disable it either via $config or use $rf->styles()->setOptions(['debug'=>false]) --> <!-- autoloading of default scripts/styles enabled - disable using ->setOptions(['autoload'=>false]) --> <!--rockfrontend-styles-head--> <!-- loading /var/www/html/site/templates/uikit-3.15.2/src/less/uikit.theme.less --> <!-- loading /var/www/html/site/templates/layouts/_global.less --> <!-- loading /var/www/html/site/templates/sections/footer.less --> <!-- loading /var/www/html/site/templates/sections/hero.less --> <!-- loading /var/www/html/site/templates/sections/job-footer.less --> <!-- loading /var/www/html/site/templates/sections/menu.less --> <!-- loading /var/www/html/site/templates/sections/rocket.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/FactsBar.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/IconBox.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/IconRow.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/PagesGrid.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/QuoteSlider.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Spacer.less --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Team.less --> <link rel='stylesheet' href='/site/templates/bundle/head.css?m=1660204105'> <link href='/site/modules/RockFrontend/Alfred.css?m=1660124218' rel='stylesheet'> <link href='https://use.typekit.net/zeg8qpc.css' rel='stylesheet'> <link href='/site/templates/sections/foo.css?m=1660207177' rel='stylesheet'> <!--rockfrontend-scripts-head--> <script src='/site/modules/RockFrontend/Alfred.js?m=1660123300'></script> <script src='/site/modules/RockFrontend/livereload.js?m=1660123300'></script> <script src='/site/templates/uikit-3.15.2/dist/js/uikit.min.js?m=1659941286' defer></script> <script src='/site/templates/uikit-3.15.2/dist/js/uikit-icons.min.js?m=1659941286' defer></script> <script src='/site/modules/RockFrontend/lib/alpine.min.js?m=1660123300' defer></script> <script src='/site/modules/RockFrontend/RockFrontend.js?m=1660203134' defer></script> </head> ? v1.13.10 makes sure that LESS is forced to recompile on modules::refresh

As soon as you want to add fields to templates you need to work with fieldgroups, as fieldgroups are the thing that connect templates with fields. I think the fact that many modules don't use fieldgroups is that - as you have realised - it is not that easy to create fields/templates/fieldgroups via API as there is a lot of things you need to take care of and that are not obvious and make things tedious. That's only one example of what I said above. But there are modules that create fieldgroups, of course. For example here: https://github.com/kongondo/Blog/blob/master/BlogInstallWizard.php The frustration you are going through is exactly the reason why I built RockMigrations...

I don't see that the docs say anything different: https://processwire.com/api/ref/page/parents/ You can use parents("status=1"), but that might also exclude other pages (like pages having errors after save). Or you do a foreach and check $page->isHidden() for every item.