Tomas Votruba has a new post to his site about an update that's been made on Statie, a static site generation tool, to support Twig templates natively.

Statie supports YAML and Symfony Dependency Injection for some time. But you wanted more! You wanted Twig. Sculpin and all the other PHP generators have it.

So there you go! Enjoy.

He shares the three steps needed to set up a sample Twig template and have it rendered as easily as the normal Statie templates:

1. Prepare Layout _layouts/default.twig
2. Create Template contact.twig
3. Enable Twig

Template contents and configuration change examples are included as well as instructions on how to update to this latest (v5.4) version. He includes tips on the naming and locations of the template files as well as a mention of his package to help translate from Latte to Twig templates.

Tomas Votruba has a post to his site sharing a method for translating Latte templates to Twig templates with the help of the Simplify tool.

Statie - a tool for generating static open-sourced website like this blog or Pehapkari.cz - runs on YAML and Symfony DI Container. That way it's easy to understand by the PHP community worldwide.

But there are some pitfalls left. Like templates - being Latte the only one is a pity. Twig is often requested feature and one of the last big reasons not to use Statie.

Well, it was. Statie will support both Twig and Latte since next version. Are you a Twig fan? As a side effect, I made 27 regular expression to handle 80 % of the Latte to Twig migration for you.

He starts with a bit of explanation of how to the project started and his goals ("investing 5 hours to automate 30-minutes manual work under 10 seconds, so no-one else will have to do that ever again"). He covers the installation of the Symplify tool and how to execute the latte-to-twig-converter on a directory of Latte templates. He also provides some snippets of code you can use if you want to reverse the process and go from Twig to Latte.

On the Symfony Finland blog there's a new tutorial posted sharing the results of their effort to get React.js to play nice with Twig, a popular PHP templating library, via a server-side generated template.

React.js is a JavaScript view library that allows developers to create interfaces is a structured way based on a hierarchical component structure. React can either create the DOM structure from scratch, or attach to an existing one rendered by the server to speed up the first load.

If you create Twig templates that match the React rendering, you can take advantage of this feature without a complicated rendering setup.

While there were other methods created to try to solve the problem (rendering the React.js template on the server side) they show a better way via React.js 16 and Twig templates. Code is included showing how to create a simple React application, and how to hook in Twig via a "hydrate" call to pull in the content. React.js has a bit of an issue by default but a little extra work on the Twig side fixes that (see the post for the solution on that one).

Rob Allen has a quick post for the Twig and Zend Expressive users out there showing how to display errors if you're not using the Whoops error handler.

If you're not using the Whoops error handler with Expressive and are using the Twig renderer, then you are given no information about the problem that occurred, even in debug mode.

He includes the Twig template to output the error message and, if the application is in "debug" mode, show an optional block of extra information. This provides details about the exception thrown and some of the previous errors. The previous errors are looped about output to provide more context around the failure.

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.

In this post to his Medium blog Pawel Mikolajczuk shares some helpful tips for getting the most performance out of your Twig output with some custom caching techniques.

In Superdesk Publisher we have implemented Mutlitenancy with possibility to have multiple themes (but one activated). To make process of switching, uploading and updating themes for tenant we had to came up with solution to clear cache only for one particular theme not the whole instance (with many organisations and tenants).

To achieve that we created custom Twig Cache class.

He then shares the code for the class, extending the base Twig filesystem caching, to work with the multi-tenant architecture. It ensures that the output from one account is completely separate from another, preventing concerns of the wrong data being shown to the wrong user. He also shows how to enable it in the application configuration (Symfony) and a custom "compiler pass" class to finish the integration.

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.

The SitePoint PHP blog has a new tutorial posted by author Claudio Ribeiro looking at how to "tame the snoo" - using PHP to work with the Reddit API via an OAuth application.

Reddit is a social networking, entertainment, and news website where the content is almost exclusively submitted by users.

[...] Reddit also offers its own API. This way, we can use all the information available on Reddit to enrich our own websites or build our own Reddit clients. In this article, we will tackle some basic Reddit API usage with PHP.

The tutorial starts with a brief overview of the Reddit API and the functionality they're focusing on: the "search" method. Example URLs are included showing the searching of terms, pagination options, sorting and other restrictions. They then bring PHP into the mix, using the Guzzle HTTP library to create a basic "Searcher" class. They also use the Twig templating system to output the results (simple template included). Finally they show how to make the OAuth application on your Reddit account, pull in the "adoy/oauth2" package and the code to connect your service via OAuth to the Reddit API.

The Symfony Finland site has posted a new tutorial showing you how you can share state in a Symfony application between Twig, React and other Javascript-based applications.

Front end development has certainly grown up in the last few years. UI logic is increasingly being moved to the client side, but the traditional server-rendered views aren't going anywhere soon. And they shouldn't.

The two methods will live alongside each other and you'll have to work with two worlds. Let's explore an idea how to make this pleasant to work with, by sharing state between Twig templates and JavaScript.

The post starts with some background on a case where this kind of sharing was a requirement and, while the initial version was scrapped, a prototype application was born. He details what this prototype showcases (which JS libraries) and links to the Javascript involved over on GitHub. They then get into the code examples showing the creation of an AppState object that handles the serializing of the state information and store the result in the database via a Doctrine connection. This value is then output to the pages that require it, making it available to the frontend application (Vue.js, React or plain Javascript).

On the Symfony Finland site they've posted an introductory article showing you how to implement accelerated mobile pages (AMP) in an application based on the ez Platform CMS.

Accelerated Mobile Pages is an initiative from Google to speed up mobile browsing. AMP is an open standard based on HTML. It enforces performance by limiting functionality and includes remote caching.

Given Google's continuing dominance search both publishers and CMS vendors need to take AMP into account. In this article you'll learn the basics of how to implement AMP with eZ Platform CMS and Symfony.

The post starts out with a bit of background about AMP and how it relates back to the main content of the site. With that knowledge in place the author moves into the code, showing how to use annotations to create the route, building and returning the template including the meta and link tags required to link this AMP version back to the main content page.