Friday update

[ryan]

For the most part I've been working to wrap up a client project this week, running in ProcessWire of course. At this point I'm using markup regions exclusively on new projects, as they really add an element of fun while also simplifying development, at least in my case. Admittedly, when we first introduced markup regions, I thought they'd be a good alternative for new users (who might otherwise use direct output), and didn't think I'd be using them myself. I was wrong. After I started using them, quite awhile ago, I've found that I rarely want to use anything else. I enjoy using them, whether developing something new, or going back and modifying an existing site that's using markup regions. I'm curious if other people have also taking a liking to them? There have been some commits to the core this week, as well as some other not-yet-committed updates on the dev branch, but not enough to warrant a version bump today. So we'll save the 3.0.99 version for next week. I have been getting lots of good reports on the current PW master version, very few issue reports, and feel we've got a really good solid and stable version on our master branch right now. Just in case there's anyone that's not yet using it, I recommend the upgrade. Thanks for reading, hope you all have a great weekend. 

[cb2004]

I wouldn't use any other method now markup regions exist. Love them. 

[flydev]

Stuck to delayed output for a while before using to a template engine, I really should give a try to markup region with it.

A quick ref for myself:

• https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/
• https://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/

[horst]

I really like them and uses them since the first minute. Mostly in the functions style.

That's how my _init.php looks like

<?php namespace ProcessWire;

$homepage = $pages->get('id=1');
$kontakt = $pages->get("template=cfg")->kontaktdaten;

// der Seiteninhalt:
region('header+', '');        // fixed header
region('nav+', '');           // ist im header
region('hero+', '');          // heroimage
region('main+', '');          // bodycontent
region('footer+', '');        // footer

// alle JS codes die innerhalb document.ready am body ende ausgeführt werden sollen,
// nachdem jQuery u. main.js schon geladen sind:
region('JSdocReady+', "");

// DebugAusgaben am Ende der Seite
region('debug+', '');

If you wonder why I initially define the regions with a + (plus sign), it's because sometimes one may end up with a site that do multiple calls of template render functions on one page, what results in multiple includes of _init.php in the chain. This is to avoid an override of previous values. Of course one of the rare use cases, but not impossible.

[tpr]

I will not be too popular with this but looking at the example above I won't be happy if I would inherit a project with such code. I have dealt with some unusual template syntax recently and from a team and maintainability POV the best is to stick with tools that most developers know, or is understandable at first sight. Of course it's only my thought but I always felt markup regions is a dead end. There are already lot of tools/languages to learn, why add another one to the stack that you can't use anywhere else? (and when there are many alternatives) 

[Macrura]

Looks cool, but I'm sort of addicted to the WireRender Pattern now...

https://github.com/NinjasCL-processwire/wire-render-pattern
https://medium.com/@clsource/the-wire-render-pattern-806bf6d6097a

[dragan]

Personally, I also don't think I would ever use PW regions. I just don't like to mix up backend and frontend code. HTML/CSS IDs and classes shouldn't be related to anything else than HTML/CSS/JS.

[cstevensjr]

I'm just glad that one has a choice with ProcessWire.  We are not mandated to use a particular way of website building.  It's always good to read about the distinctly different uses of the platform.

[nfil]

this is a good introduction to markup regions! I found it very useful:

https://github.com/ryancramerdesign/regular

[Robin S]

11 hours ago, tpr said:

from a team and maintainability POV the best is to stick with tools that most developers know, or is understandable at first sight

I had the same thought initially when Markup Regions were introduced, but after thinking about it some more I don't know that this amounts a good reason not to use something. Because you could actually say the same thing about most aspects of the PW API and therefore never start with PW in the first place.

Take $files->render() for example. If you're coming in cold knowing nothing about PW you're not going to instantly understand how this works, what variables will be in scope, etc. You have to take a bit of time to become familiar with the method, read the documentation, test things out. So really no different to Markup Regions. Once you read the introduction and try out Markup Regions it starts to make sense very quickly.

Personally, I think Markup Regions are a fantastic feature and I have used them on every new site since they were introduced.

[cb2004]

19 hours ago, tpr said:

I will not be too popular with this but looking at the example above I won't be happy if I would inherit a project with such code. I have dealt with some unusual template syntax recently and from a team and maintainability POV the best is to stick with tools that most developers know, or is understandable at first sight. Of course it's only my thought but I always felt markup regions is a dead end. There are already lot of tools/languages to learn, why add another one to the stack that you can't use anywhere else? (and when there are many alternatives) 

I do see your point, but after inheriting some WordPress sites this year which are absolute horror shows, it has proven to me that any project without code commenting could take some time getting to grips with. So a few small comments in the template files explaining markup regions is what I add. 

[ryan]

Quote

I will not be too popular with this but looking at the example above I won't be happy if I would inherit a project with such code. 

The example you are referring to was not markup regions, but region() function calls. They are very different things. I think Horst may have thought I was talking about region() functions since the terminology is similar.

Though I can also recommend region() / wireRegion() function calls (even if I don't often use them myself), as they are also quite useful, and I would certainly be happy to inherit a project using them. Depending on your code editor used to edit site files, they may be preferable to traditional delayed output. 

Quote

Personally, I also don't think I would ever use PW regions. I just don't like to mix up backend and frontend code. HTML/CSS IDs and classes shouldn't be related to anything else than HTML/CSS/JS.

What you've described is not consistent with markup regions. You mentioned you would never use them, but I recommend enjoying some time with them before coming to that conclusion because I think you may view them as something different than what they are. Just like in any other methodology, it's your decision as to how you delegate front-end or back-end code, markup regions dictate nothing about that. Markup regions merely designate the target for markup, and are not really any different than delayed or direct output in that respect, other than that it's a little bit simpler to use, and a little more flexible in practice. Markup regions do not use class attributes. You can use id attributes if you want, but using pw-id attributes is independent of whatever is used in the markup. Of course, everyone prefers different methodologies, not to mention different projects have different needs, so there is no one-size-fits-all. PW supports a lot of different options, use whatever works best for your context.

 

[StanLindsey]

I've just started using MarkupRegions and I think they are fantastic. It is basically identical to the Delayed Output strategy but you are able to focus on the markup instead of various php variables. 

Definitely give it a try before you write it off.

[Noel Boss]

I ? markup regions. I found Processwire arround a year ago when they where introduced and used MUR exclusively since. I use it like a template engine with layouts like this:

//1. Append file
app/index.php > Append file, init, loads Component() & Snippet() Methods
app/theme/componen.php
         /snippet.php

// 2. ProcessWire Template, extends layout
Template.php > extends markup regions, can define layout or false

// Template uses Components and Snipptes:
src/components/component/component.php
                        /component-varian.php
                        /component.js > compiled by gulp
                        /component.scss  > compiled by gulp
src/snippets/snippet/snippet.php
src/snippets/snippet/snippet-varian.php
                    /snippet.js > compiled by gulp
                    /snippet.scss  > compiled by gulp

// 3.1 Layout
app/layouts.php > Prependfile Handles include of layout:

// 3.2 Load markup region layout
src/layouts/default.php > Markup Regions
           /Template.php  > Markup Regions

Example Template, can assign a $page->layout variable or set it to false. I use custom Component and Snippet methods to render Parts that I use multiple times:

<div id='pw-author' pw-remove></div>

<div id='pw-header' pw-replace>
	<?= Component('header', 'profile') ?> // loads src/components/header/profile.php
</div>

<!-- Adding class to main -->
<div id='pw-main' class="uk-padding-remove-bottom" pw-append></div>

<div id='pw-body' pw-append>
	<?= Component('profile', 'page'); ?> // loads src/components/profile/profile-page.php
    <?= Snippet('buttons', 'logout'); ?> // loads src/snippets/buttons/profile-logout.php
</div>

<div id="pw-more" pw-remove></div>
<div id="pw-aside" pw-remove></div>

 

Prependfile: app/layout.php > this file loads a layout, if there is a layout file with the same name as the Template or a set $pages->layout variable:

$layout = isset($page->layout) ? Wire('config')->paths->templates."src/layouts/$page->layout.php" : Wire('config')->paths->templates."src/layouts/{$page->template->name}.php";
$default = Wire('config')->paths->templates.'src/layouts/default.php';

switch (true) {
	// layout like Page-Template exists
	case is_file($layout):
		include $layout;
		break;

	// default template
	case is_file($default):
		include $default;
		break;

	default:
		return "<div class='uk-alert uk-alert-danger'>could not find layout. Searched for $layout / $default.</div>";
		break;
}

Component Function: app/template/component.php – components should never be nested, can contain snippets (css & js namespaced)

namespace ProcessWire;

function Component($component, $variation = '', $vars = [])
{
	if (is_array($variation)) {
		$vars = $variation;
		$filename = $component;
	} else {
		$filename = $variation ? $component.'-'.$variation : $component;
	}

	$file = Wire('config')->paths->templates."src/components/$component/$filename.php";

	if (is_file($file)) {
		$vars['skin'] = isset($vars['skin']) ? $vars['skin'] : '';
		$vars['class'] = isset($vars['class']) ? $vars['class'] : '';
		$out = wireRenderFile($file, $vars);
		return $out;
	}

	wire('log')->error('Could not find '.$file);

	return null;
}

Snippet function: app/theme/snippet.php – can be used inside components (css & js namespaced)

namespace ProcessWire;

function Snippet($name, $file = null, $vars = [])
{
	if (is_array($file)) {
		$vars = $file;
		$file = $name;
	} else {
		$file = $file ? $name.'-'.$file : $name;
	}

	$file = Wire('config')->paths->templates."src/snippets/$name/$file.php";
	if (is_file($file)) {
		return wireRenderFile($file, $vars);
	}

	return "<div class='uk-alert uk-alert-danger'>could not find $file.</div>";
}

 

[bernhard]

Same here: I think they are really great!  It makes the setup so much cleaner and more readable and also more flexible. For example I'm using a region "scriptsbottom" at the end of my <body> and whenever an included section needs some javascript I just write the markup and append the script to that region:

// _main.php
<region id="header"></region>
[...]
<script><region id="scriptsbottom"></region></script>

// slider.php
<section id="header">... my great slider markup ...</section>

<region pw-append="scriptsbottom">
  $('#slider').init();
</region>

IMHO this is much more readable than using delayed output with php variables and then "messing" around with $config->scriptsbottom .= '$(\'#slider ... ' (doing some crazy escaping or ob_get_clean() or the like.

 

[Sebastian]

I'm with @Macrura as i'm using wireRenderFile() extensively with a dedicated /views/ folder where I can organise my output in components / atoms / whatever you want to call it, using templates (and sometimes /fields/field.php) more or less as controllers.

@bernhard brings up some good points I haven't thought of though, especially the JS part - I awkwardly tucked that into wire('config')->scripts, which isn't as elegant / nice.

Anway, it's great having the flexibility and options to use PW as you see fit Quite liberating.