On his Mdeium.com site Pawel Mikolajczuk has written up a post showing you how to create a custom Twig node and parser to extend the powerful functionality already included in this popular PHP templating package.

If You want to create custom twig node then this tutorial is for You. I will show you step by step how to create custom twig syntax (DSL) called gimme (we build it for our Superdesk Publisher project).

He starts with the required changes to your composer.json file to pull Twig in and a sample index.php file to build the Twig instance and add in the new extension (the "gimmie" handling). He then provides the code needed to create the extension based on Twig_Extension for the new node type. Next is an example of the "gimmie" handling in action in a template, dumping out the user information when the article is requested. He explains what each part of the tag is doing and shares the code to create the parser for its contents. Finally he shares the code required to create the "node" class, converting it over to its parsed PHP equivalent.

On the Omniceps site there's a new post introducing you to Latte, the templating component of the Nette framework that can be used independently.

A PHP templating engine is the one which gives you ability to write html for your clients efficiently using PHP variables.

However, PHP was originally built to be a templating engine, but yet it was never used primarily as a templating engine. There has been so many PHP templating engine so far in the market since PHP evolved, but none of them has made as great impression on us as Latte. Introducing you to Latte, one of the best PHP templating engine you have come across so far. Also Latte protects your web app from vulnerabilities like XSS (cross site scripting).

The tutorial starts with an example comparing "plain old PHP" templating with the Latte version for a foreach loop. Next they show how to install the Latte component and the two different kinds of macros the tool includes. They also talk about filters, performance concerns, context aware escaping and "pretty output" options.

On the SitePoint PHP blog they've posted a tutorial highlighting one of the most widely used templating tools in the PHP ecosystem (that's not locked into a framework) - Twig. In this new tutorial author Claudio Ribeiro introduces you to the tool and what it has to offer you and your application.

Twig is a template engine for PHP. But isn’t PHP itself a template engine? Yes and no!

Even though PHP started as a template engine, it didn’t evolve like one [...]. PHP is a verbose language, and that verbosity is amplified when trying to output HTML content.

Modern template systems will take away some of that verbosity and still add a fair share of functionality on top. Things like security and debug features are mainstays in modern template engines.

Today, we’re focusing on Twig.

He starts off by helping you get the tool installed via Composer and shows it in use to display the values in a hard-coded PHP array. The template (index.html) outputs the result as HTML and shows the use of normal variable output, control structures and filters on the data during output. He then moves on to other topics like working with layouts, caching output, looping, conditionals and filters. The final note is about debugging, mentioning the "dump" function to directly output a value for examination regardless of type.

Over the past months I've been slowly customizing my Sculpin installation for this blog to fit my own liking a bit more. I've added a bit more styling including a beautiful background image and a transparent white background for the content column. Today I wanted to add a bit more. Two things specifically: I wanted to control a bit more about how my blogposts are displayed when they are shared on Facebook [and] I wanted to have an optional image at the top of blogposts to make them look a bit better.

It turns out this was actually quite easy, so here's a short description of what I did to make it work.

He splits the article into these two parts, showing how to add in custom markup and add custom frontmatter to modify the Facebook posts. He then shows how to add a block to the main templates for the highlight image and a small section to credit the photo back to the original.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.

The TutsPlus.com site has posted the third part of their "Dynamic Page Templates in WordPress" tutorial series today. In this latest article author David Gwyer finishes off the series using all that they've shared from part one and part two to create two examples.

In the first two parts of this tutorial series, we covered what dynamic page templates were and why they were needed. We also looked at the code required to implement them.

In this third and final tutorial in the series, I'll be creating two examples of fully working dynamic page templates you can use in your own projects. These were specifically chosen to be easily extendable to suit your own needs, and are intended as inspiration for any other type of dynamic page templates you can think of.

He then walks you through the creation of the two page templates: a Simple Contact Form and a Blog Post Archive. The first allows you to dynamically control the form elements for a UI interface (rather than code) and the second uses dynamic data to display the list of previous blog posts. The tutorial then finishes with a look at how, since WordPress 4.7, you can use dynamic page templates with any kind of post, not just pages.

On the Laravel News site there's a recent post showing a feature coming in version 5.5 of the framework that will help make creating error views easier:

Coming in Laravel 5.5 is a new and improved design for the error pages. The default errors will extend from an errors::layout file and get some small design additions over the current style with flexbox and a vertically centered message.

They compare the older version to the newer, cleaner one and how you can still, even in 5.5, have your own custom error pages named based on the HTTP error code (like 500.blade.php or 403.blade.php). They end the post covering the renderHttpException and how it determines which of the error templates to use.

Fabien Potencier continues his look at what's coming in the next major release of the Symfony framework (v4) in this new post to his site. In it he talks about changes to the default directory structure that Symfony 4-based applications will use.

Symfony 3 came with a slightly different directory structure than Symfony 2. Symfony 4 will also come with a reworked directory structure. Mostly incremental adjustments to support new features and best practices.

The Symfony 3 directory structure introduced a more standard Unix-like directory structure, with less sub-directories. Symfony 4 keeps going in that direction.

There's six changes he mentions specifically, each with a brief summary of what they'll contain:

Tests under tests/

Templates under templates/

Configuration under etc/

Source Code under src/

Temporary files under var/

Web files under web/

He ends the post with a quick note that, while these will be defaults, all of it is optional and these directories will be created automatically if they don't exist.

On the Laravel News site there's a post about an upcoming feature in the Laravel framework's Blade templating functionality: components and slots.

A new feature coming to Laravel 5.4 is the ability for you to add Components and Slots to Blade templates. This feature was inspired by Vue.js and allows you to simplify building HTML elements into reusable areas.

In most applications you have a master layout and then sub views that extend it. [...] Using the new Laravel Blade Components you can create [a template] with a special variable [for easy replacement].

The post then shows how to "reimagine" views using this slots and components functionality in a simple template/view example, replacing data based on names rather than it having to be passed to the view as data.