Templating Engine

[KalenJohnson]

Templating engines are being used everywhere, not just in other languages, but nearly all other PHP frameworks and CMS's that are actively maintained. Even Drupal 8 will be rolling out ​Twig integration.

I wasn't able to find an actual discussion about this on Trac, so I definitely wanted to open the discussion. Should WordPress integrate a templating engine?

The benefits are obvious:

• Automatic escaping. No more escaping all the things every single time.
• Easier to read. This is sometimes down to personal opinion, but I and many others do find templating engines much easier to read than PHP templates
• Better separation of logic from templates. This isn't a guarantee, and depends on how strict the templating engine is, but it does help reinforce this.

Cons:

• More to learn. I don't know how much more, but it is something to take into account
• Speed? I haven't looked up benchmarks lately, but another thing to potentially keep in mind
• Backwards compatibility. However this could be mitigated if plugins/themes had the option to use straight PHP or the templating engine.

There are many options available, Smarty isn't widely used anymore, but there is (​http://twig.sensiolabs.org/ Twig) which is probably the most adopted, and (​http://laravel.com/docs/5.1/blade Blade) has become rather popular.

[wonderboymusic]

I encourage this discussion - even if we stick with raw PHP, would love to see our data become more friendly for templateing engines to use

[brentjett@…]

Template syntaxes are a tough commitment. There are some pretty heavy cons to deal with. Here’s how I see it:

Pros:

• Simpler syntax for themers, declarative instead of logical. Themers (the majority) are not programmers and it helps to admit it.
• Secure - Template languages can be sandboxed to prevent bad practices and hacks prone to php files.
• Machine writable - These “tag” driven languages are a lot easier to write programmatically. I’m of the opinion that WordPress should one day become the best environment for creating themes as well as consuming them, and being able to write templates programmatically is a big step toward that.
• A template syntax could be merged with the shortcode syntax so the two become interchangeable which will help end users warm up to theming.

Cons:

• Often template languages are too simplistic. It’s difficult to express complex conditions or prepare data without resorting to a logical language. This has the potential to be severely limiting.
• This requires a different environment from the logical one used to setup theme configuration and define plugins. Forces developers to learn multiple syntaxes. (BTW - Theme configuration like theme supports and enqueuing really SHOULD be moved into a declarative language like JSON)
• Unlike PHP, plain text files like json or twig are publicly accessible without special server setup to block viewing them. Themers would probably need to learn new security best practices.

All that said, twig is a very interesting language, solves several problems, and also introduces some. Squarespace has an interesting syntax (JSON-T) that is paired with JSON data for structure. I’d be interested in working on moving theme configuration settings into a declarative syntax like JSON before really diving into templating langs.

[KalenJohnson]

@brentjett while I agree that it would be great to get plugin and theme meta data out of random css and php files, I'm not sure how it directly relates to a templating engine being integrated.

There is some very good discussion that happened about meta data being moved to JSON over here: https://core.trac.wordpress.org/ticket/24152

[netweb]

Related:

#12877

Modular themes: Apply template hierarchy to folders within a theme

#13239

Filter locate_template template_names variable

#22355

Template stack - Beyond parent/child theme relationships

#31475

Add ability to change the folder location for templates

[tiagofabre]

I am favor of template engine working with wordpress. And I would like to know:

What is the list of template engines compatible with wordpress (license, tech) ?

[rkoller]

Replying to tiagofabre:

I am favor of template engine working with wordpress. And I would like to know:

What is the list of template engines compatible with wordpress (license, tech) ?

Take e.g. a look at Timber. It is using Twig as templating engine and is already available as a WordPress plugin ( ​https://wordpress.org/plugins/timber-library/ ) under the GPLv2 license

[andreasnrb]

The main issue with theming and WordPress in general is the highly coupled nature with the globals, loop and post object also the nature of template including. You can use template engine with WordPress as is. Of course you need to transpile the templates yourself but its possible.

If it was possible to hook into https://core.trac.wordpress.org/browser/tags/4.2.2/src/wp-includes/template-loader.php#L74 and instead of including directly having a callback there it would make it possible for people to add any template engine of their choosing without need to transpile before release.

[jakkub]

Take e.g. a look at Timber. It is using Twig as templating engine and is already available as a WordPress plugin ( ​https://wordpress.org/plugins/timber-library/ ) under the GPLv2 license

I think Timber is really good example, both in concepts and in execution. It makes theme development much faster and more joyful. And Timber/Twig templates can happily coexist with traditional templates, so no problem with backwards compatibility.

About learning curve - well, you have to learn at least some simple basics of templating engine and you have to understand how Wordpress and The Loop works - but it worths.

[SergeyBiryukov]

Previously: #5

[jarednova]

Funny to see that this is a continuation of #5. That said, so much has changed since then. 11 years ago Craft and Squarespace didn't exist. Nor did Twig or Blade. I want to address the cons brought up by @brentjett@:

- Often template languages are too simplistic. It’s difficult to express complex conditions or prepare data without resorting to a logical language. This has the potential to be severely limiting.
The design of Timber (and what I would recommend for a future standard WordPress templating structure) encourages complex logical code to live in an extension class of the TimberPost. For example, on a music website:

{# single.twig #}
{% for artist in post.artists %}
<p> {{ artist.role }} : {{ artist.name }}</p>
{% endfor %}

<?php

class RollingStone_Post extends TimberPost {

  function artists() {
    $artists = array();
    // do some complex code here to fetch the artists that are mentioned in this post 
    // or retrieve from a custom field repeater
    return $artists;
  }

}

I see overlap with #24672 and the [WordPress-Objects](​https://github.com/humanmade/WordPress-Objects) GitHub project. 90% of Timber's code is really just making WordPress object-oriented.

Yes, if someone uses JUST the twig templates they are limited. But that said -- let's embrace the fact that many projects require only access to the templates to apply classes and maybe some simple conditionals to make them work.

• This requires a different environment from the logical one used to setup theme configuration and define plugins. Forces developers to learn multiple syntaxes. (BTW - Theme configuration like theme supports and enqueuing really SHOULD be moved into a declarative language like JSON)

Can't agree more about dependency management. We've long since crossed the threshold of multiple syntaxes with PHP, HTML, CSS, JS. I'm not trying to say that this shouldn't be a consideration but Twig brings with it a comparatively small amount of additional syntax. I've been teaching it to co-workers/clients (who are primarily designers) over the last few years and everyone is like "whoa! that was easy." With developers, I don't even have to train them b/c they've seen virtually identical syntax in Mustache, Handlebars, Liquid, etc.

• Unlike PHP, plain text files like json or twig are publicly accessible without special server setup to block viewing them. Themers would probably need to learn new security best practices.

I think this is a very good concern to highlight. While the security exploits aren't obvious, I can see how a small risk multiplied by 23% of the web could create a major unforeseen gap in security.

... I think @matt was correct to close this in 2004. But a lot has changed since then. I think we should take advantage of the lead WP has by investing in where the market is going. I'm very proud of Timber, but I'd be even more proud of rebuilding the templating structure for WordPress in a way that the entire community can get behind.

[KalenJohnson]

Thanks for jumping in, @jarednova ! I was hoping you would, since Timber is the most popular implementation of a templating engine in WordPress currently.

Often template languages are too simplistic. It’s difficult to express complex conditions or prepare data without resorting to a logical language. This has the potential to be severely limiting.

I agree with what Jared already pointed out above. Templating engines aren't simplistic, rather, they are encouraging you to prepare and set up your data before getting to the actual template. WordPress themes in the past have not really enforced this, and in actuality, has encouraged relatively complex logic in theme templates with functions that do much more work than they should.

The reality though is that while this was accepted practice years ago, it's no longer the preferred or accepted way to handle content in the rest of the web development world. Templates should not contain much logic other than if statements, and loops. And templates should certainly not be making database calls.

I think this is a very good concern to highlight. While the security exploits aren't obvious, I can see how a small risk multiplied by 23% of the web could create a major unforeseen gap in security.

I just took a look at the ​Twig docs, and they actually seem to use .html files for templates:

$template = $twig->loadTemplate('index.html');

So that would most likely be much better covered on web hosts. Also I know that Laravel Blade still uses the the PHP extension, but templates files are structured as index.blade.php. So I think we could still keep it secure on all hosts.

I think we should take advantage of the lead WP has by investing in where the market is going.

Couldn't agree more. WP is certainly doing this in many areas: Customizer, heavy JavaScript usage (including templating!), automatic updates, etc. Themes are one of the things that has been sort of left behind, I think simply because it is relatively open ended and up to the theme developer to employ best practices. However, again, a templating engine enabled by default would encourage best practices and get a major part of WordPress up to date with the rest of the web development community.

Hoping to have some comments from core team soon :)

[xavivars]

I've started to use Timber for a couple of projects recently, and it makes amazingly simple to write WordPress templates.

One of the projects is being built from scratch with Timber (we started from plain static HTML files, and we've been integrating it with WordPress while building the twig templates), and it's much easier and the result is much cleaner than what would be using "standard" WordPress templates.

For the other project (which, in fact, was like the proof-of-concept of the second) we took an existing website and started migrating one template at a time the existing theme to twig (through Timber). Thanks to the backwards compatibility, we could do that incrementally, and we even published intermediate versions of the theme where only a few templates were using twig, and the others were still standard WordPress templates.

I'd love to see Timber becoming WordPress native.

[francogilio]

Do any of you guys tried out Sprig by Zach Adams: ​https://github.com/zach-adams/sprig ?

It's got some interesting concepts and uses Twig as the Templating Engine.

Replying to xavivars:

I've started to use Timber for a couple of projects recently, and it makes amazingly simple to write WordPress templates.

One of the projects is being built from scratch with Timber (we started from plain static HTML files, and we've been integrating it with WordPress while building the twig templates), and it's much easier and the result is much cleaner than what would be using "standard" WordPress templates.

For the other project (which, in fact, was like the proof-of-concept of the second) we took an existing website and started migrating one template at a time the existing theme to twig (through Timber). Thanks to the backwards compatibility, we could do that incrementally, and we even published intermediate versions of the theme where only a few templates were using twig, and the others were still standard WordPress templates.

I'd love to see Timber becoming WordPress native.

Wow, I didn't knew about that deep backwards compatibility. I'm eager to try it out!

[schlessera]

I think that any templating engine would probably provide many benefits compared to the raw PHP approach we have now, if only to push developers into using a more structured approach, properly separating the concerns.

However, I would much prefer not focusing this discussion on "What templating engine should we use?", but rather on "How should we extend WordPress so that we can smoothly drop in different templating engines?". This is a much more future-proof approach, and whatever the current trendy engine of choice is will not limit us in a few years.

So, how would we go about molding the current filters and data structures into something of a "Templating API" that can use different implementations depending on a site's needs? This "Templating API" could still provide a backwards-compatible standard implementation shipped with WordPress, and it would make it trivial to build additional, reusable templating engines that can be installed/used when required.

I know that WordPress advocates the "decisions, not options" approach. I think this is a good approach for end-users, but the changes we are talking about here are targeted at developers. Developers drive innovation, and it should be in WP's best interest to not unnecessarily block that innovation with arbitrary choices.

[andreasnrb]

Replying to schlessera:

So, how would we go about molding the current filters and data structures into something of a "Templating API" that can use different implementations depending on a site's needs? This "Templating API" could still provide a backwards-compatible standard implementation shipped with WordPress, and it would make it trivial to build additional, reusable templating engines that can be installed/used when required.

I completely agree which is why I made the suggestion earlier in this thread to add a filter in the template loader for a callback to be used instead. https://core.trac.wordpress.org/ticket/33472#comment:7

[swissspidy]

However, I would much prefer not focusing this discussion on "What templating engine should we use?", but rather on "How should we extend WordPress so that we can smoothly drop in different templating engines?". This is a much more future-proof approach, and whatever the current trendy engine of choice is will not limit us in a few years.

What would be some first steps to do this? Which limitations currently exist? Note that there are now more filters in the template hierarchy, and plenty of developers already use Twig or similar in their custom themes.

Btw, I think with the REST API now in core, we're going to see more sites with a decoupled frontend and JavaScript-heavy themes. Even without the REST API, you can totally use WordPress for the backend and something completely different in the frontend.

[wujek_bogdan]

+1 for Timber.

IMO it's better to use a good, tested, well documented and widely adopted tool than re-inventing the wheel. Timber is a great tool. I've been using it for a while and I will never go back to plain PHP templates.

[SergeyBiryukov]

#41911 was marked as a duplicate.

[olegkhorev]

I saw WP has no templates engine. I was developed my own templates engine just simplest to understand ever. It is just standard PHP but with { } tags. Please, see details here
​http://demo.ajax-cart.com/page/templages-engine.html

It's free download
​http://ajax-cart.com/page/ajax-cart-download.html

I am open for any questions.

[iandunn]

Automattic escaping

That's one of my favorite things about React (well, JSX really). Output is secure by default, and you have to use dangerouslySetInnerHTML() to output raw data. It's intentionally named to make it obvious that you should really know what you're doing if you're going to use it.

Using it also serves as a signal that the dev is intentionally outputting unescaped HTML. That cuts down on false-positives in linting tools, making it easier to ​integrate into workflows and saving time during peer-review.

Since the transition for plugin/theme authors seems relatively painless, XSS could almost be eliminated in plugins/themes that adopt it.

---

focus this discussion on "How should we extend WordPress so that we can smoothly drop in different templating engines?". This is a much more future-proof approach, and whatever the current trendy engine of choice is will not limit us in a few years.

I agree, and like ​the approach that Gutenberg took with abstracting React. We're ​kind of already doing something similar with Underscore templates. The engine could change as long as the syntax didn't.