Leaderboard

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 ?

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.

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...

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());

The module provides a list of PageTable based content elements. It enables the backend user to easily create, publish, move, delete, copy and paste content elements. The rendering logic of the module is detached from the ProcessWire backend scope via Shadow DOM and allows the elements rendering identical to the front end. It ships with some helper functions that simplify the handling of content elements. Download/Install Github: https://github.com/neuerituale/PageTableNext Module directory: https://processwire.com/modules/page-table-next/ Composer: composer require nr/pagetablenext

Maybe you could use AIOM+ if it's installed?

In case you want a copy paste version to use RockFrontend with RepeaterMatrix from within a .latte file: {* templateExample.latte *} {foreach $page->repeaterMatrixField as $block} {$rockfrontend->render("fields/repeaterMatrixField/" . $block->type , ["block" => $block])|noescape} {/foreach} {* blockExample.latte *} <div> <h1>{$block->headline}</h1> {$block->body} <img src="{$block->image->url}" alt="{$block->image->description}"> </div>

I set it up. I'm simply a slow learner. ? But you are right. The more I experiment with it, the clearer things become. Thank you for your response.

Hi, maybe it's because your class isn't really... a class but a full inline style ? have you tried 'class': 'your_class' and then setting the syles in your css? have a nice day

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...

You can either use the $sanitizer->truncate() in your template file or set a character limit from within your template settings. For the second option go to: Setup > Templates > Your Template Click on the textarea field (summary) > Switch to Tab: Inputs > Set character limit

To limit how many characters can be input, to go the field settings and set "maximum length" in the Input tab to a value greater than 0. You can also do this per template if you switch to a template using the dropdown in the upper right corner. Or you can go to the template settings and click the field there. To shorten the string during output, you can use WireTextTools: WireTextTools::truncate() method - ProcessWire API

I'm not sure if this should be considered a bug, a feature, or just something to be aware of, but I came across this behaviour today: Scenario: I have a 'body' field which is a CKEditor textarea field. I'm using $sanitizer->truncate() to output a truncated summary of the body for use on a parent 'list' page; e.g.: $sanitizer->truncate($page->body,200); Everything worked fine. Longer body content is truncated, shorter (<200) is output in its entirety. I then enabled the PageFrontEdit module for the site, and allowed the body field to be automatically editable (Option A). Suddenly, all the shorter body fields were being duplicated in the output. For example, when the body field contains just this: <p>More information will be coming soon...</p> The output from the above $sanitizer->truncate() call was this: More information will be coming soon... More information will be coming soon... After some investigation, I realised this is because the formatted value of the body field in this scenario looks like this: <div id=pw-edit-2 class='pw-edit pw-edit-InputfieldCKEditor' data-name=body data-page=1115 data-lang='0' style='position:relative'><div class=pw-edit-orig><p>More information will be coming soon...</p></div><div class=pw-edit-copy id=pw-editor-body-1115 style='display:none;-webkit-user-select:text;user-select:text;' contenteditable><p>More information will be coming soon...</p></div></div> ... including all the PageFrontEdit wrapping context. When stripped of the html tags the text appears twice and still being less than 200 characters, is output twice. Solution: It's easy to fix in this particular example. Just get the unformatted value before sending to $sanitizer->truncate(): $sanitizer->truncate($page->getUnformatted('body'),200); I don't know if this should be opened as an issue, since $sanitizer->truncate() doesn't know the context of what it's receiving; it's just a string. Maybe this can help others who might run into this problem.

You can create different templates that have different designs (templatename.php) The author must select which template/design to use when creating a page. A template defines which fields are available on a page and which template file (/site/templates/templatename.php) is used. The content/text is then defined on a page.

Is there any way with PW to do environment-specific robots.txt, i.e. to block robots from staging sites without having to manually edit files in different environments?

Solved!!! Answer was in the .htaccess file. Remove reference to robots.txt being a physical file on the system. #RewriteCond %{REQUEST_FILENAME} !(favicon\.ico|robots\.txt) RewriteCond %{REQUEST_FILENAME} !(favicon\.ico)

Here's how you might dynamically create it with ProcessWire without tinkering with .htaccess files. Create a new template, call it robots, and set its URLs > Should page URLs end with a slash setting to no, and Files > Content-Type to text/plain. You should tick disable Append file and Prepend file options as well. Optionally set its Family > May this page have children to no, and Family > Can this template be used for new pages to one. Family > Optionally Set allowed templates for parents to home only. Create a new page under homepage, set its template to robots, and name as robots.txt. Create a new template file at /site/templates/robots.php, inside it you type <?php namespace Processwire; // render different robots.txt depending on your own conditions. if ($config->debug) { // use PHP_EOL to create multiline strings echo <<<PHP_EOL User-agent: * Disallow: / PHP_EOL; } else { echo <<<PHP_EOL User-agent: * Disallow: PHP_EOL; } and done. You should be able to see robots.txt at the url /robots.txt.