Leaderboard

->find() checks the access control/page status (contrary to ->get()) and repeater templates are hidden to guest users. Just add "include=all" to your selector and it should work.

@Alpine418 In PHP, classes are loaded with an autoloader that you can manage via composer (this is the common way). And ProcessWire comes with a composer.json file that you just have to edit, for example I edited mine like this: "autoload": { "files": [ "wire/core/ProcessWire.php" ], "psr-4": { "Rfro\\Rfrorga\\ProcessWire\\": "site/templates/", "ProcessWire\\": "site/classes/", "Rfro\\Rfrorga\\WebApi\\": "webApi/", "Rfro\\Rfrorga\\Cron\\": "cron/" } }, Now I can use any of this namespaces everywhere. In my custom classes I use base classes and traits located in site\templates\Php\CustomPage\Page\.

Hello and welcome to processwire! The short answer is there is no recommended way. Processwire leaves that completely open to the user. Some like markup regions, I don't. Some use template engines like latte or twig, others don't.

At first I used regions, then markup regions, and I found that I wasn't happy about performances. I did some benchmarks and noticed that the time consumed to render the page was growing faster than the amount of data to render. For example, if I double the data, rendering may take 3x the time (just a random number, I don't remember values, but I think I saved them in a text file). That's why I switched to Twig, Twig is slower for small content but is robust with big content. And I like how it's easy with Twig to write clean readable code, reuse twig fragments several times, import, extend, include, embed... there's a lot of choice, and no performance issue when including twigs into twigs. For very small html snippets that I use everywhere in the site, and are closely related to a page/template, I also have a method on my custom page classes, that calls a "Renderer" instance associated with this page and print some HTML. I use it for example for the user cards that are displayed on almost all pages of the previous site I did: <div>{{user.renderer('card')}}</div>

@YipperI struggled on this topic in my first project too. I used delayed output strategy for the first prototype. Then I did a rewrite over a weekend with all the stuff I‘ve learned in the meantime and restructured code into Page Classes and switched from PHP templates for the view part to Latte template engine where it made sense. Fun fact. To overwrite some template parts (e.g. navigation, footer) until guests logged into the frontend, I used Markup regions on the login page to overwrite the default template parts, which shouldn‘t be visible for guest or spam bots. Lessons learned. It‘s more important to get started then overthinking which strategy to use. You will learn a lot and some of the available strategies may come handy later, once you know, how and where you can make use of it.

Thank you @monollonom!

Version 1.0.2 Add composer support Add missing audio mime types Add clear buttons in process view Optimize xml handling Fix Error messages and SSML empty input detection

I would recommend Markup Regions over storing markup in PHP-variables, because then you can work with actual markup and have good code highlighting and autocomplete. Also, try using custom page classes for the business logic of your templates. This was a huge game changer. And you could also use RockFrontend and LATTE - which I would recommend, because in my opinion it is better to use a "real" template engine and not PHP for writing markup.

@netcarver Have you tried using boot.php? In site/config.php $config->statusFiles = array( 'boot' => 'boot.php', 'init' => 'init.php', 'ready' => 'ready.php', 'finished' => 'finished.php' ); and in boot.php <?php namespace ProcessWire; wire('classLoader')->addNamespace('Wireframe\Blocks', paths('templates') . 'blocks/'); wire('classLoader')->addNamespace('Wireframe\Traits', paths('templates') . 'traits/'); I don't remember if I used traits in pages classes or in some other parts of the code, but you can try.

Another way? // Make all field inputfields non-editable in Page Edit $wire->addHookBefore('ProcessPageEdit::execute', function(HookEvent $event) { if(!$event->wire()->user->hasRole('read-only')) return; $event->wire()->addHookAfter('Field::getInputfield', function(HookEvent $event) { $event->return->editable(false); }); }); // Remove the Settings tab $wire->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { if(!$event->wire()->user->hasRole('read-only')) return; $form = $event->return; $tab = $form->find('id=ProcessPageEditSettings')->first(); $form->remove($tab); $event->object->removeTab('ProcessPageEditSettings'); });