Part of meta-issue #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1

Spin-off from
- #1382350: [meta] Theme/render system problems
- #1158090: Separate usage of hide(), render(), and other template features from print statements to enable non-developers to create themes
- #1263478: Identify pieces of Drupal that could be replaced by Symfony code

Problem

  • PHPTemplate is based on PHP, and PHP code 1) is complex and 2) can do evil things too easily.

Goal

  • Evaluate whether Twig might be a better default template engine for Drupal.

Details

  • Twig is a template engine that aims to be secure, performant, and to cleanly separate "view logic"/template rendering from functional model/controller code.
  • Twig's syntax is not PHP, but rather compound of a macro language. Its syntax reminds a bit of Smarty (and also JSP), but has been architected and developed from scratch, leveraging latest PHP5 features and modern programming standards in the PHP community.

Tasks

  • For starters, create an actual implementation of the template engine in http://drupal.org/project/twig to see how it would look like and whether it's feasible at all.
Files: 
CommentFileSizeAuthor
#16 Twig for Drupal autoloader2.61 KBReneB

Comments

I don't see how it makes sense to take a php based system and add further abstractions to it. The nice thing about having the whole template system in php is that it's the same kind of material you find everywhere else in drupal. Sure there are ways to improve it but why not focus on that rather than adding new syntax and new complications.

The main motivation behind these type of systems is to hide complexity from the themer. If you post a job for someone who knows CSS / HTML you'll get 100 resumes, if you add PHP to the list you'll get 10.

I personally came to Drupal as a themer not knowing any PHP but having years of experience in HTML and CSS it took me far too long to understand PHP's data structures that could have been mostly hidden from me. Asking someone who doesn't know any PHP to understand $foo->bar['foo']->bar['foo']['foo'] is a pretty tall order. From my experience its not until you start writing and working with those type of structures daily that you can glance at them and understand what you're dealing with.

Also maybe it is possible (?) to allow Drupal user to make/upload their own theme, as it is now, it's like "whut? your own theme, in php? might as well take down my whole server while you're at it".

But you'll still have to deal with loops and variables just not the ones that are used by the rest of the system. You're trading one tool for another but adding another layer of stuff to muddle the waters when fixing and debugging issues. Plus, it's one more thing that needs to be kept current and that will add to drupal's already nearly insurmountable learning curve.

I got half-way there with http://drupal.org/sandbox/robloach/1335328 .

Twig uses the BSD License, would this be a problem?

@lliss It comes down to who we want able to write themes. Right now writing a reasonably complicated drupal theme requires the same skills needed to write a simple module, so every theme developer is a PHP developer whether they like it or not. This means 90% of clients can't work with their own themes and junior devs need to learn a lot of PHP just to work in the presentation layer. If you give a beginner access to PHP they will abuse the features they don't need, Twig walls PHP off completely so you learn Twig's conventions instead of a language you're not ready for, or may have no desire (ability?) to learn.

These arguments all make sense if our goal is to make themers' lives super-easy, but as a themer (with adequate HTML/CSS as well as PHP knowledge already in my "arsenal") that had to go through the (in)famous Drupal learning curve in order to know how to get things done, I can only accept this as a feature request - not a task. Moreover, I believe it should simply be an alternative template engine for starters. Setting it as the default for D8 & replacing PHPTemplate (even suggesting it) personally makes me feel pure frustration. It is unfair to say that I have to learn to speak Twig simply because some people are to lazy to learn basic PHP. It's not like they have to reach guru level before they can achieve all the basic things.

...If you post a job for someone who knows CSS / HTML you'll get 100 resumes, if you add PHP to the list you'll get 10.

Lets see...

- They learn PHP and they will be able to use this "industry standard" almost everywhere ...even to contribute with modules here in d.o some day ...they might even eventually become one of these 10% people that will get the job ;)

- I learn this "exotic" new language and I get what? How many job listings out there require Twig/Smarty/whatever compared to those requiring PHP knowledge?

Please don't get me wrong... I like the features of SASS for example, but I'll use the contrib SASS / SCSS project to get it in Drupal - I won't go suggesting it as the default.

I'm sure it can perfectly live in contrib while we wait and watch its stats. We can then see if it is actually the 90% of drupal users that prefer it and perhaps then we can evaluate it for core.

Thanx for taking the time to read this - sorry for using harsh words like "lazy" and the likes :/

PS: I am aware that theme engine stats are not gathered by d.o, so we can actually look at usage stats, but you can tell quite a bit by the fact that their last commits were 2, 3 or even 4 years ago and by seeing at what rate issues in their queues are answered/fixed.

BSD license is a-OK legally to include in core, like we do for Symfony.

The bigger question here, I think, is that while we claim to support multiple template engines I am not convinced we actually do anymore in D7. The theme/render system has gotten too looped in on itself, and I don't know if it's even possible to use an alternate engine. That is itself a problem.

I think the bigger question is whether we can unravel that spaghetti more easily by adopting a different library and then working around it rather than trying to pull individual strands one by one. I do not know the answer to that question, but I think it's a good question to ask.

(Twig is more than just template replacement tags.)

I guess there is a potential big win regarding #1158090: Separate usage of hide(), render(), and other template features from print statements to enable non-developers to create themes and #953034: Themes improperly check renderable arrays when determining visibility here.

Twig being extensible, we could provide our own logic to unify the "is $foo a string that should be printed, or a render array that should be render()ed" subtleties, hiding the php logic.

For instance (just throwing ideas and syntax without much thought, obviously debatable) :
{{foo}} : "print $foo if $foo is a scalar, or render($foo) if $foo is a render array"
{% if !foo|empty %}<div>{{foo}}</div>{% endif %} : does the correct empty() check depending on whether $foo is a string or a render array (possibly means rendering $foo to see if the result is a non empty string)
{{foo.bar}} : "render($foo['bar'])"
{{foo-bar}} : "hide($foo['bar']); render($foo);"
{{foo|keys}} : "prints the subkeys of the $foo render array is a dsm() or something, for discoverability"

Bottomline is : all the discussions around "granular rendering" and "render arrays in templates" since the last 3 years or so have gone in circles around the intricacies of the PHP syntax for strings and arrays and how we have tried (and failed ?) to ease the differences. An expressive, extensible, non-PHP syntax would make that a non issue.

Or perhaps it's an indication that our rendering is just too granular to be useful in the first place, and we need to accept that and back off from nono-templating with render arrays entirely?

@Crell : and go back to people manually dealing with raw field values, wrongly sanirizing in 95% cases, if they want to isolate a field in a separate div ? Please no, i've seen too much of this in d6.

Or find a better way to solve that problem than the most memory-inefficient data structure in all of PHP... I'm sure we can do better than that, whether that means Twig or something else.

Twig (or something like it) would be great. Like the Twig site says "The PHP language is verbose and becomes ridiculously verbose when it comes to output escaping". Twig would give us less intimating templates to newcomers and a a nicer syntax for people with more experience.

Reading the (short) Twig homepage, http://twig.sensiolabs.org its hard to see what's not to like :)

In addition to http://drupal.org/sandbox/robloach/1335328 there is also http://drupal.org/sandbox/ReneB/1075966 to see how feasible it is.

On a practical note, getting twig templates to be correctly handled in code editors is quite a hassle. On Eclipse, for instance, you need the latest unstable builds to be able to run a specific plugin. Now if only they hadn't chosen such a file naming convention...

StatusFileSize
new2.61 KB

First of thanks to @sotak to tweet me about this :) We (that is my former employer and I) are using Twig in Drupal environments for quiet a while now with rather great success. Or at least I would like to think so. Twig as a template engine brings much more to the table then just a replacement for phptemplate, but I guess Fabian can do that talk much better then I can ;)

Any the more recent version of Twig for Drupal 7, since I kinda lost interest in the D6 version, is the one located at my github account because do to the license issue I think stopped pushing it toward drupal.org

https://github.com/renebakx/twig-for-drupal/tree/Drupal7

The documentation of that version is also a little off, but in the latest build I added a method to auto-render content by using the node traverser build into twig and swap out the twig_print objects for tfd_print objects. I started to convert MortenDK's mothership towards twig to be used as some sort of twig boilerplate,starting point, mainly cause I support his and i guess most of Frontend United's "kill the DIV movement"

<header class="cf" role="banner">
    {% if logo %}
    <figure>
        <a href="{{front_page}}" title="{{'Home'|t}}" rel="home">
            <img src="{{logo}}" alt="{{'Home'|t}}"/>
        </a>
    </figure>
    {% endif %}
    <hgroup>
        <h1>{{site_name}}</h1>
        {% if site_slogan %}
        <h2>{{site_slogan}}</h2>
        {% endif %}
    </hgroup>
    {% if page.header %}
    <div class="header">
        {{page.header}}
    </div>
    {% endif %}
</header>

This is just a small snippet from the page.tpl.twig, but as you can see there is no real need to call something like {{page.header|render}} in your template. Twig for drupal figures that out but it self, and returns either the rendered array, object or plain strings.
This behavior is not obligatory, as i also implemented twig filters for both render and hide methods. And a few others as well. Just check the code in /TFD/Extension.php

TFD however needs a autoloader to function properly, so I took the basic autoloader and APC aware ones from Symfony2 and merged those together into a single file autoloader. I attached that autoloader to this post as well.

Usage of this version of TFD is rather easy.

Create a folder in sites/all called libraries and in that folder create one called autoloader. This made the most sense to me as other projects also added vendor libraries into sites/all/libraries/

Unpack the autoloader, and add a single line into your settings.php

require_once DRUPAL_ROOT.'/sites/all/libraries/autoloader/Autoloader.php';

This included the autoloader at bootstrap level, which is needed to use twig in case of an error.

Add the Twig folder from the twig project into that same libraries folder (https://github.com/fabpot/Twig/tree/master/lib) and finally get the TFD project from my above mentioned github and place the content into /themes/engines/twig (This is on the same level as where drupal phptemplate is stored)

TFD creates a cache folder to store it's compiled templates in your current enabled sites/../files folder (normally sites/default/files) but the engine is fully multisite compatible.

TFD, has fallback for missing .tpl.twig files, so there is no need to convert all contrib tpl.php into twig variants. But you could if you wanted ;)

And finally, to use the twig engine, simple replace the engine = statement in your theme.info file for

engine = twig

If you have any questions on the subject of using twig in Drupal, just poke me,tweet me (@renebakx) or send me a mail, I'am more then willing to get this into drupal as I strongly believe that drupal could and would benefit from a great template system like Twig :)

I don't know if we gain all that much by adopting twig. Why would we want to invest in a php specific templating engine as the web is moving more towards client side rendering?

What's important here is that we can support templating engines that aren't rendered by php, so people could use mustache, handlebars, jquery templates, or whatever. As pointed out in this thread, it means getting rid of things like render(), hide(), etc in templates.

This is certainly one of those places where you don't have to choose either or. You can have both.

It certainly sounds like @ReneB is already making good use of Twig.

Technically, we've had that ability to have multiple engines since as far back as I can remember - but the arrival phpTemplate in 4.5 meant practically nobody ever looked at another Smarty or Xtemplate or other template file since.

There is not barrier to adding twig to core. The only 'hard part'™ is winning hearts and minds and convincing people to provide twig templates for their modules. This is not a technical problem (particularly since we do have autoloaders in core now).

Odd coincidence... I was reading about FluxBB today and ran into: http://fluxbb.org/forums/viewtopic.php?id=5141 . Just thought it might be of interest to this discussion.

Michelle

There is not barrier to adding twig to core. The only 'hard part'™ is winning hearts and minds and convincing people to provide twig templates for their modules. This is not a technical problem (particularly since we do have autoloaders in core now).

That is a mission impossible, and I personally gave up on that mostly because those discussions end up in 80+ page long 'he said, she said' with no real conclusion discussions.

In a ecosystem like Drupal having the option to use your own preferred way of handling your view logic is in my opinion a great plus and should be cherished and not ruled out or forced upon developers. If people don't see the advantage of separation of concern between php and view logic, OO styled templates and other goodies systems like twig can bring to the table, then let them use phptemplate. Don't force them to use system X or Y, give them freedom and tools to make their own choice based on what's good for their business.

A little history on my twig implementation
At my former employer we piloted drupal 6 for a project about 2 years ago and after a brief but hard and not so pleasant encounter with panels, context and views we came to the conclusion that this was not the way, we as developers wanted to build and maintain projects. About the same time Fabien resurrected the twig project from Armin Ronacher and we almost knew that this was more of our way we wanted to do theming in Drupal. So on a sunday afternoon I wrote the first version of TFD, showed it the other developers at the studio the next week during our weekly tech-meetings, and well we never looked back at phpTemplate (and context,panels) again.

Some examples of sites we made in D6 with Twig : http://www.zicht.nl/, http://www.concertgebouw.nl/ http://vuconnected.nl/and http://www.groningermuseum.nl/

Hopefully I will find some time to work on my TFD project in the next weeks or months, but this is going to be a spare time project as my new job (started a month ago) at this moment does not involve drupal at all. But still, i would LOVE to work on the D7/D8 version of the twig.engine.

First up, like I said is a fork of mothership into twig, and ironing out some issues with the transition from the old 1.3 based D6 version to newer 1.6 version, mostly todo with the syntax change for sandboxing variables. Oh and write proper documentation for the drupal specific functions/hooks in the twig.engine.

Don't force them to use system X or Y, give them freedom and tools to make their own choice based on what's good for their business.

AGREED!!

I used Twig in my own custom scripts. IMO, it's Good for developers, bad for designers/themers. Drupal / Wordpress / .....and many use PHP as templates. Designer / Themer come from other background able to theme it. :)

+1 for #10, introducing more helper functions. I love DOT natation so much.

http://kohanaframework.org/3.0/guide/api/Arr

// Get the values of "color" in theme
$colors = Arr::path($array, 'theme.*.color');

+1 for Twig in CORE as an alternative engine.

What's important here is that we can support templating engines that aren't rendered by php, so people could use mustache, handlebars, jquery templates, or whatever. As pointed out in this thread, it means getting rid of things like render(), hide(), etc in templates.

There is a client side templating solution for twig (https://github.com/schmittjoh/twig.js) but you right it would be good to support a variety of client side templating.

Title:Evaluate Twig template engine for Drupal core (as a replacement for PHPTemplate and possibly even theme functions)Evaluate Twig template engine for Drupal core (as an alternative for PHPTemplate and possibly even theme functions)

Yeah, as many of us said: another alternative - not a complete replacement. We didn't just spent so much time, effort + money on books/tutorials to learn theming the old way to simply find that we can't use what we've learned when the new version of Drupal comes out. Perhaps #304486: Theme Engines as Modules is the answer here.

But personally I don't think it should go in core as second engine. Either we swap out phptemplate for twig or twig remains contrib. To much unused stuff in core that is just better of in contrib then in core.

And if we indeed decide that twig should become the defacto standard template engine for drupal, we as community should really work on removing all the inline HTML cruft in theme_ functions into decent template code and or twig macro code like symfony2 does (see form customizing for example)

But given the timeframe and the amount of work that is going to bring, I don't that is doable for D8. Most contrib maintainers barely got a decent D7 release out of their projects, and already feel the pressure of D8 API changes breathing down their neck. I don't think is a human thing to enforce them to rewrite their theme support. Although for some modules, and yes I am looking at you views, I personally think that theming could be a great deal simplified by NOT having every single element in a separate theme function and start looking at blocks. But that is something I personally handle with twig and render arrays. It's a bit more work, and it rules out the drag'n'drop options for end users to use systems like swentels excellent display suite, but hey there's a market and use for everybody. That flexibility is what I love about drupal. You can start with drag'n'drop and slowly move in the more complex do everything yourself way of theming, with engines like twig for example :)

Anyway.. I saw that Sun also mailed me about cooperating with Rob on getting Twig to work in drupal, but I dare to say that I would prefer to use my version as it's clearly a working version that already proved it's handling in several Dutch projects.

Perhaps we should rule out my autoloader for a more generic autoloader, in order to make it more compatible with other solutions. But I would like to drop the dependency on Symfony framework for just the twig part and make a composer/drush make system for easier setup :)

You know, I'm going to take a slightly different angle on this question. Back in #16, Andre said:

Technically, we've had that ability to have multiple engines since as far back as I can remember - but the arrival phpTemplate in 4.5 meant practically nobody ever looked at another Smarty or Xtemplate or other template file since.

There is not barrier to adding twig to core. The only 'hard part'™ is winning hearts and minds and convincing people to provide twig templates for their modules. This is not a technical problem (particularly since we do have autoloaders in core now).

Class loaders are a non-issue, let's not worry about that. The bigger issue is this part: "convincing people to provide twig templates for their modules".

As Andre noted, no one has really bothered with anything but PHPTemplate in years. I would actually say that Durpal 6 was the death knell to other template engines for exactly the reason that Andre notes. In Drupal 5 and earlier, all template files were provided by the theme. The theme was specific to the theme engine, so the theme engine could handle templates in some other fashion if it wanted to. All core did was provide theme functions! Template of any form were a hack on top of theme functions that a particular engine could implement or not.

That changed in Drupal 6. As of Drupal 6, core has not one but TWO output renderers: Theme functions and templates. That means that suddenly, as of Drupal 6, module developers could provide their own template files for the first time ever. And many many did, and the kittens looked upon them and smiled, for that was good.

However, and this is key, they were all PHPTemplate templates. I do not know of one single module that has provided templates for any other theme engine out of the box. To be honest, I'm shocked that Rene was able to get anything working using some other engine at all. I cannot imagine the amount of work that must have taken.

So yes, to be able to leverage Twig, or Smarty, or whatever else as anything other than an after-thought third-class citizen that only a few die hards use we would need to get not just core but major contribs to provide two (or more) versions of their template files. That is, you're asking module developers to do double work, for absolutely no benefit to them.

So "convincing people to provide twig templates for their modules" is a non-starter. Speaking as a module developer who barely takes the time to maintain his modules now, there's no way I'm going to bother providing 2, 3, or dear god 4 versions of the same template in different formats. Ain't gonna happen.

That leaves us with only two viable approaches:

1) Take templates back from modules. Don't let modules provide templates, only theme functions and preprocess (or similar), and put all of that work on the theme (and theme developer), not the module developer. That is, go back to Drupal 5.

2) Admit that multiple theme engines are a thing of the past, their time has passed, and stop pretending that we support multiple template engines. Then get one that is really really rockin good, whether that's a cleaned up PHPTemplate or Twig or something else.

Consider the question from that perspective. Once again, we cannot have our cake and eat it too. We have to make a decision.

Minus a gazillion on #1. That would be putting a knife in any attempt to make Drupal have decent forums. I backported a good chunk of Drupal 6's theming to D5 just to get something usable for AF back then.

#2 sounds fine to me. I like PHPTemplate but wouldn't be crushed if we switched to something else. As long as we only switched to one something. As you said, I'm not gonna make templates for multiple theme engines.

Michelle

Well, #1 is not a good option. Just look at the sheer number of modules that provide templates.

I'd say let's go with #2. I don't think it really matters which template engine we include, just as long as it's awesome. I'm torn, because we've had phptemplate for a long time and a lot of Drupal developers are familiar with how it works. On the other hand, if we can use external libraries, we should: it's much more likely that a theme engine that's jointly used and developed by more than one project will be awesome, than having an awesome template engine that's specific to our project.

I'm shocked that Rene was able to get anything working using some other engine at all. I cannot imagine the amount of work that must have taken.

Don't be shocked, it just a mather of writing/mapping theme functions to use templates if possible and some regx magic here and there. But most importantly and at the same time very time consuming in D6, create a lot of node_.tpl.twig files. And that was where twig and the {%extends node %} together with {% block %} comes in. We only needed to find and theme the right field values from $variables or $node in the template files. Not ideal, but atleast it gave us the much needed freedom to create cruft-less HTML5 with D6

Oh and two of my colleagues wrote a internal qeury tool to load data from the system without going trough most theme functions. Real codestuff, not that drag'n'drop stuff most drupal people use.

But in D7 things actually got a lot easier with the introduction of render arrays because all the raw variables are present in one place, it's just a mather of knowing how to overload theme functions or create your own theme functions.

And thats why I said that no mather how much I would love to have twig in core, it is not realistic given the timeframe and workload already on most contrib maintainers. To be really usefull we need to change a lot of theme functions and rethink the entire smallest first way of theming content in drupal.

@Crell: At this point, a Twig engine is kinda vaporware, so I don't think that black and white thinking is appropriate. Let's not block this thread before it even started.

The first and foremost thinking we should respect and get behind is that the target audience of the theme system are themers, and this API/system is primarily for them. Putting on my developer hat, I'm merely trying to point out possible options to themers, and capture and interpret their feedback. In the end, themers need to decide, not developers.

#25 1) would basically mean to remove all default template files from core (and move them into individual core themes instead) - until now, I haven't heard any themer mentioning or favoring this option; existing feedback rather sounds like themers don't really have a problem with default templates.

Regarding module/template maintenance, I don't really see an issue. Needless to say, there could be helper scripts to semi-automate PHPTemplate conversions.

True... Conversion scripts could work... But i don't want to look at the converted code ;)

Personally all i need is a good base to start from, and that is one of the primary reasons I am looking/converting Morten's Mothership to twig theme for my personal D7 project.
Morten like a true danish King, removed a lot of the div/span cruft from the majority of modules I use. Yes I use, cause I do know that my point of view is a very superdeluxe position. I don't need to think nor care about 10K plus of user contrib modules, only the 10 maybe 15 non core modules I use for projects. And that makes my life with twig a lot easier :)

And to put a little oil on the fire, perhaps D8 would be a great moment to actually archive all D6 and lower modules ;)

Agreed entirely about the primary audience here being themers. That said, the API for developers providing data TO themers has to be usable, too, and right now I don't think it is. I haven't worked with Twig myself so I don't know if it's better.

I'm actually not trying to block this thread at all. I think it's a very good discussion to be having. I'm just saying that, as a practical matter, multiple first-class-citizen template engines is not a viable approach, and we should not spend effort trying to make it so when we should instead be spending it on building, adapting, or adopting one really really good template engine, whatever that is.

my depest wish since i know and do drupal:
a template engine
* that has parsable templates that can be automatically validated
* that helps us get rid of non-sanitized output
@ReneB: can twig help us with this?

Could you please specify what you mean by automatic validation? If you mean syntaxed checked, yes you could. Twig throws errors if a template could not be compiled. Not that it would be of much use in Drupal because there is as far as is know, no way to redirect output nicely if a theme generates a parse error.

As for escaping, yes.. It comes with the autoescape extionsion : http://twig.sensiolabs.org/doc/tags/autoescape.html

That operates in two modes, with block tags to escape only certain parts of your template, or you can turn on escaping global and everything is escaped. Which I personally do not like nor find very usable. I rather control output myself with the blocktag/filter aproach.

@ReneB #33 "automatic validation":
from other frameworks i know if your templates are valid html/xml and machine-parsable this opens up sexy new workflows.

one: automatic validation for html5 compliance, accessibility etc.

another (amongst many more) which i remember from the plone world:
* template files are parsed and enriched with some "source info"
* designer takes the browser page html and changes the design
* script automagically updates the template files from the new design html file

compare it with the "machine readability" revolution of semantic web.
or said differently: believe me, machine readability is something you urgently want even if you do not know it yet ;-)

@34,

XML based templates ? closed to Magento Commerce. 101% not themer friendly IMO.

This is mainly an argument against making Twig the default template engine:
So instead of front-end developers practicing their PHP to possibly evolve into module developers, you want everyone to learn a new syntax to keep the front-end developers separated from the module development world? Yes, problems arise with using PHP, but then you fix them and learn from it. I think PHPTemplate is an important stepping-stone for beginner PHP developers. It's part of one possible progression into a web development career, going from HTML/CSS, to JavaScript, to PHP. I'm afraid that this is just going to cause there to be more mediocre theme developers, since they'll rely on a syntax that's only used in their theme directory and never brave out into the module directory. I was a front-end team lead for a large Drupal platform. I interviewed and trained a handful of front-end developers in Drupal, and I don't think they would have progressed as quickly into taking charge of editing modules and other PHP files, if all they had to work with was Twig or Smarty and stuck in their HTML/CSS world. I'd be okay with Twig being a second, optional template engine for those that are afraid of writing and learning PHP. Also, once your site is built, think about the people that are going to inherit the code. Now there's an additional dependency on someone that knows Twig.

Every time this discussion (php vs other template engines) comes back to focus I remember this article (http://www.massassi.com/php/articles/template_engines/) which explains why many of us don't get the point about using template engines when php itself is a template language.

Inspired by that article, pure php template engines were created as independent projects and later implemented in Drupal as phptemplate.

"The point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code."

Exactly - introducing a new template system with its own syntax that compiles down to PHP anyway is not desirable, IMO. I worked with Smarty for years, and eventually found it to be cumbersome and unnecessary.

PHP code can be complex, but much of that complexity should be handled via Drupal APIs so that themers don't feel the need to implement that complexity in their preprocess functions or worse, templates.

So instead of front-end developers practicing their PHP to possibly evolve into module developers, you want everyone to learn a new syntax to keep the front-end developers separated from the module development world? Yes, problems arise with using PHP, but then you fix them and learn from it.

I completely agree. Learning the PHP syntax is a bigger win for a new themer than learning a non-PHP syntax.

@Crell : and go back to people manually dealing with raw field values, wrongly sanirizing in 95% cases, if they want to isolate a field in a separate div ? Please no, i've seen too much of this in d6.

Sticking the render API directly inside the template wasn't the only way to solve that problem. IMO, putting show/hide/render in templates without any ability to know which things could be shown/hidden/rendered was a huge mistake. I argued that they should be rendered in the _process functions and just remain strings inside the template file, but I learned about the Render API transition after it was 90% done and couldn't get any backing on that idea. I would however strongly urge us to consider this again.

Variables in template files should be simple things so we can apply simple PHP to do our work. Complex things like breaking a variable up into parts should be left in the preprocess functions.

Completely agree with #39.

+10000 on #39. While I was a coder before Drupal (VFP), I learned PHP by first trying to understand theme snippets and, eventually, turning all my theme changes into the Advanced Forum module.

As for the render() stuff in the templates, I just really don't get it. I understand wanting to be able to change things at the last second but why in the .tpl file? Why not in the (pre)process code? I like the templates themselves to be simple print this print that. Maybe a little if/then logic if needed but I try to eliminate as much of that as I can as well by ensuring variables always exist and such. To me, it is much easier to look at a template and understand the structure if it has as little non-HTML as possible.

Michelle

So instead of front-end developers practicing their PHP to possibly evolve into module developers, you want everyone to learn a new syntax to keep the front-end developers separated from the module development world? ... I'd be okay with Twig being a second, optional template engine for those that are afraid of writing and learning PHP. ...

That pretty much sums it up. That's why back in #23 I've changed the issue's title to replace the "as a replacement for PHPTemplate" part with "as an alternative for PHPTemplate".

It's not like the rest of us don't want twig support in. In fact we don't seem to mind at all: #304486: Theme Engines as Modules ...but we cannot simply sit back and watch as this discussion goes on about completely replacing the default PHPTemplate engine. It ain't the same as going PHP5 or HTML5 that are newer versions of broadly accepted standards in the business.

Here's a "battle plan" in order to do this in a just way:

1. #304486: Theme Engines as Modules
2. Twig for Drupal in core ...as an optional/alternative theming engine.
3. #1273344: Establish heuristics for core feature evaluation
4. Then we collect some stats to see how many installations have it enabled. If it proves to be more popular than the current default PHPTemplate, then Twig becomes Drupal's default theming engine and PHPTemplate the alternative. Hell, if it becomes so much popular, we even move PHPTemplate out of core and into contrib.

How does that sound?

Before we do ay of these though, I'm sure that you'll need to prove its acceptance by getting the usage counter of the Twig for Drupal (or whichever project evolves to be the most popular/stable/robust implementation of Twig) to a respectable number first. Then work on documenting it all in detail and perhaps also getting a few good books/tutorials out there on Drupal advanced theming based on the new Twig engine. Lots of work to be done first! So, I'd mark this as "postponed" till some serious work's been actually done towards that direction.

I completely agree. Learning the PHP syntax is a bigger win for a new themer than learning a non-PHP syntax.

I am not so sure.

This is definitely true at the moment when do to any almost any theming you need to learn to mess with PHP sooner rather than later.

But as part of a changed themer experience where we separate out (in some way) the job of editing template files and tweaking HTML from doing PHP type stuff I think a more concise and less intimidating default template could go along way.

@ReneB Did you find any uses for some of the features in twig? I'm thinking things like Template Inheritance.

I've been thinking about this for a few days, and I think I've decided that I'm very much against this idea. Here's why:

1) The idea that we support multiple theme engines is a fallacy. We pretend to, but we don't. IMO, that part of Drupal should be ripped out and we should go with ONE theme engine and make it awesome. It'll remove a layer of complexity from Drupal, and in doing so, I suspect that we'll get a lot of performance gains.

2) While Twig is a great syntax for theme develeopers, we should consider that we are a community of PHP developers. Introducing a non-PHP syntax for theme development is going to further separate theme developers from module developers. The fact that our templates are complicated for non-PHP developers is, in my opinion, irrelevant. I've never understood the argument that non-PHP developers are going to be working with Drupal, so we need to support them. The thing is, this is a PHP CMS, so I think that the expectation should be that if you're going to do anything crazy with it, you should know some PHP. That's why it's called web development.

We should be focusing on making the theme layer (and Drupal as a whole) less complex and more performant, and in my opinion, this is doing the opposite of that.

...I think a more concise and less intimidating default template could go along way.

...there's that word that pisses me off again: "default" ?!?

This issue is about introducing another theming template engine/language in core. Proposing this for D8 while there is not even a well-supported and broadly-used project in contrib to test things first and expecting broad acceptance is futile. This issue should be set to "postponed" until such a project exists. If people keep insisting that we should replace PHPTemplate I'm gonna start insisting that it is instead set to "closed (won't fix)". You cannot simply "give the finger" to all the D5/6/7 themers and book authors out there by making a 180o degrees turn.

Specifically concerning Twig: sure, it might be very-very good, but it is not the holly grail of all problems in Drupal theming. We cannot keep debating over if Twig is more useful/robust/safe/easy than PHP. You know what? It might be. So, instead of simply evangelizing Twig's features, why don't you prove this by providing hard evidence:

- make the sandbox a full project and give it a release
- create thorough documentation about using Twig for theming Drupal (I guess if it is "so easy" you won't have to do much work here)
- leave it there for some time for the word to test it
- let some new kick-ass themes be created and gain enough popularity (user adoption)
- let old themes & starter themes be converted to use Twig (themer adoption)
- let 3rd parties write some books/tutorials

You do get the point. Right? Proposing such a dramatic change so fast is (excuse me but...) plain stupid.

klonos, could you please dial it back a notch? :) We are in code thaw. That means it's totally open season for whatever wild and crazy ideas people have, and everyone gets the opportunity to throw them against the wall and see what sticks. It's sounding more and more like this idea is not very sticky, and you gave some good actionable steps for someone who wants to see people change their minds about that, but we shouldn't ever discourage people from proposing ideas.

Seconding what @webchick said.

Also, again, I want themers to decide how they want to work. While the expressed arguments about PHP, multiple templates, and whatnot are sound, I've the impression that most of them were raised by developers. The stated arguments may not be so important for themers - they may very well have different priorities. I want themers to be happy. They are the primary objective and target audience — developers, OTOH, can cope with pretty much everything (you know, they're even able to make sense of the current utter nonsense ;)).

Like I said im #20 discussions about PHP and template engines always come done to this part. Discussions that PHP is a template engine and you don't need an engine in a engine. But thats fine with me, cause I do. I like to have seperation of concerns and just display logic in my templates, not having to worry about PHP code in it, and a easy to learn syntax. Each to its own I guess. Just as long as drupal keeps an option to use a non phpTemplate system you wnt't hear me.. And if drupal decides to drop plugable engine support well.... their loss i guess :)

End of discussion for me, I still keep on working on my Twig for drupal,even nobody else except me is using it, simply cause it fills my personal need :)

@Edward_nor, yes... Template inherentance is one of the main reasons we choose twig in D6, one base node template with defined blocks, and for every variation, a extend from that base and just replacing the block that is different. Much more efficient then render modes, and clearly readable in template code what happend. No magic shizzle from the database needed to render a variation :)

Just for the record. Although I don't support using other template engines inside Drupal I think phptemplate could be a lot simpler.

Maybe we need an issue to discuss ideas on how to make phptemplate easier and more similar to other template engines.

I don't know how much is relevant 8 years later but I thought I'd point to this interesting slice of history: http://drupal.org/node/7133 While pondering the possibilities of changing or augmenting the template engine, you can see how we got where we are today. :)

Michelle

Status:Active» Postponed

We'd first have to clean up the template system first to make it clean, pluggable, swappable, etc. Maybe consider touching it up with Symfony Templating, which supports PHP Template out of the box, and has extended support for Twig. I'm setting this issue to post-poned until that happens.

symfony != symfony2, so what is the gain of introducing a 'old' template system into a 'new' drupal?

symfony != symfony2, so what is the gain of introducing a 'old' template system into a 'new' drupal?

Meant to link:
https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Tem...

Another thought, since Drupal becoming OOP (we need the autoloader), doesn't that mean an increase in learning curve?

I think I found C++ codes more difficult to understand compared to C codes.

It's not just about a simple array, there's also object and properties, overrides, object inside object, their definition lies on separate files, if the object inherit from parent, that parent definition also on separate files.

Providing a shield to themers from those things that php programmers need to deal with might be a good option.

I think I found C++ codes more difficult to understand compared to C codes.

I'd actually argue the opposite. With the addition of the Standard Template Libraries, you can save yourself much more time in C++ than in C (like using "proper" strings, associative array maps and linked lists).

If done right, themers won't have to worry. They'll just know they can do more with it, and I'm all about empowering themers. If anything it will be easier to use since it would be removing lots of the business logic that's currently embedded in the rendering system.

The question however is, are themers ready to be empowered with all sorts of things that are way out of their current comfort and work zone?

The idea of opening them up to PHP, so that they become future developers sounds intressesting from a developers point of view. But I personally know quite a few frontend developers that have no aspiration at all to become PHP developers and are perfectly happy with a 'simple' template language like twig to get their daily job done.

re: #57: I tend to agree with that thinking. Personally came to PHP via Smarty - which is similar to (but not the same as) Twig in that it uses an abstracted macro syntax/language, that's easy to understand and use. IIRC, I solely worked within that layer for 2-3 years (and I was happy). Contrary to Twig, however, Smarty allowed for baked-in/inline PHP within the Smarty templates. Once I hit the limits of Smarty (obviously not knowing/understanding that the entire syntax/macros can be extended), it was that support for mixing in PHP code into templates, which allowed me to do my first baby steps in PHP in order to achieve the themed output I wanted. Fast-forward 13 years, and witness the utter mess that resulted in (aka. me, today)... ;)

That said, I think there could have been plenty of other ways and possibilities for stepping into PHP. Not to mention, the system back then wasn't Drupal, so I didn't have the additional facilities and easy ways for simply adjusting what I got in the theming layer via configuration. If I had, then I might even have not wanted to get familiar with PHP in the first place (and instead might be a creative designer/themer and much more relaxed today :P)

In the end, I don't really think the "get to learn PHP" argument sticks. It can be a beneficial side-effect, but front-loading the argument and forcing themers to learn and use PHP isn't the right way to approach the theme layer question.

I have to agree that using templates as a "gateway drug" to get themers into PHP is not the right approach. That is predicated on the assumption that "Real Men(tm) Write PHP", which rather denigrates our purported primary target audience of clicky-click site builders.

many people say though, that a template language should have only have a well-defined and limited set of data processing power - so that the tempation of doing logic that belongs somewhere else is minimized. there are quite some templates around that validate this assumption.

Status:Postponed» Active

I don't know why this is postponed...

I'm not sure if this belongs here or in #1382350: [meta] Theme/render system problems, but I'll put it here since it relates to earlier in this thread and people can cross link if needed.

I had a call with Mark Sonnabaum earlier this week, and he made a good point. One of the new-fangled things that is up and coming on the web is full client-side rendering. Ship content to the browser in JSON form, render with client-side templates, done. Very low bandwidth. Of course, that means you need a client-side template of some kind.

PHPTemplate is, of course, completely useless on the client side. See this article for an example of why that's relevant:

http://echodittolabs.org/blog/2012/02/introducing-backbone-module-drupal

While it can do all client-side rendering, all of the theme code has to be completely reimplemented in the browser.

Should client-side support be a consideration when looking at what we want to do for templating? How important is it that we use a template system that can be used both server-side and client-side, so that people doing cool new stuff don't need to re-implement every single theme function or template? I'm not sure, honestly, but I do know that it's non-zero.

One of the new-fangled things that is up and coming on the web is full client-side rendering. Ship content to the browser in JSON form, render with client-side templates, done.

I've been doing this with the Services module for a few years, and had been wanting to push it in to Drupal Core via #145551: Enable loading and rendering into multiple formats (html, xml, json, atom, etc.). The template system is just too much to work with in its current state though.

And that is why this issue is postponed. There is LOTS of spaghetti code that needs to be cleaned up before we can even consider bringing in another theme engine. Lots of business logic embedded straight into theme rendering. If we get to a point where swapping out templates and engines is sane, then we could consider bringing in Twig, or switch to a JSON renderer and have client-side rendering. Talk to anyone who's worked with the template engine system before, and they will agree that it is pretty wonky. Even the HTML5 initiative has run into a few overwhelming quirks. I'm 100% in agreement that we should use something already invented though.

Hence my postponing this issue until we fix up #1382350: [meta] Theme/render system problems. I outlined a few issues in my comment over there.

Status:Active» Postponed

We don't want to force anyone into one way of doing something. And that is another reason why we need to clean and abstract this. Jacine would absolutely explode if you tell her we're forcing them to do rendering on the client-side, haha. #1382350: [meta] Theme/render system problems is where our focus should be.

+1 for client side support as a big issue in templating, as stated by crell in #61.
noone knows how fast this comes but without that i see it likely that drupal is knocked out of many use cases in say, five years.

@Rob, I don't think persisting and jugling the status of this issue is going to help in getting things done ;(

Should client-side support be a consideration when looking at what we want to do for templating? How important is it that we use a template system that can be used both server-side and client-side, so that people doing cool new stuff don't need to re-implement every single theme function or template? I'm not sure, honestly, but I do know that it's non-zero.

Well there is a port for twig to javascript (https://github.com/fadrizul/twigjs) but that is a implementation to be used in nodeJS, which is still serverside. As far as I can see, the porting or creation of a template engine to a generic server and client-side solution is going to a endless task with much hurdles to take. And definitally not something that should be desired imho.

Twig syntaxed is derived from Django, and there are a few implementations of that syntax for client-side javascript available. The biggest hurdle to take is finding a way to get the added logic from the serverside to the clientside. For example in my current twig implementation I wrote a filter to create a drupal URL out of a NID by mapping the url() method

<a href={{node.nid|url}}'>Clickeeee</a>

Or creating/getting a image from image-cache preset on the fly

<img src='{{node.fid|image_url('preset')}}'>

I know that normally the render method on a render_array would handle that, but I personally prefer to handle elements like this in my viewcode in order to keep my desired fine-grain support over the output :)

Anyway, getting logic like that to the frontend would mean to either pre-process all the data that is going to be send in order to create the urls, images and what not. This would generate some overhead and I think would totally remove the speed-up of having the front-end generate the views.

A other solution is to create a JS equivalent of the mapped functions, but that leaves us with two codebases to support. Not a good option IMHO.

I think that withing D8 transition from being a HTML based system into a REST based system, we should consider moving the 'template' engine to that layer. Pure data is gathered together trough the entire request, a bit like the current render_array and then based on the request type or paramaters should be transfered to a render layer that could transform the data into a JSON object, HTML or whatever kind of dataformat a developer needs/dreams/builds for the application.

Don't enforce a single 'template' language, embrace flexibility, but move it to the right tier in the drupal application stack. Because isn't that where the request/response from symfony2 combined with the excellent flexibility drupal gives us comes from?

transfered to a render layer that could transform the data into a JSON object, HTML or whatever kind of dataformat a developer needs/dreams/builds for the application

That was the theory behind the render API. It doesn't work, because the "abstracted" form for HTML and JSON is just too different. And it introduces a host of other brain-breaking problems, too.

I don't believe that a single rendering system with swappable tag libraries can actually handle the variance of different output types, and we shouldn't spend time trying to fit that square peg into a round hole.

As for the template library, my previous statement still stands: Module developers are not going to provide multiple templates for different template engines. It's simply not going to happen. Whatever core defaults to is what 98% of people will use, and everyone else will be a second-class citizen. That's already happened.

In theory the render api works, however in practice it seems that some developers still have markup in the render array. And that is something you can not change unless you enforce it in someway. Swappable functions that is a different ballgame. Personally i do not care about the #metadata like which theme_ method to use, but I can imagine that for other developers or themers it is support important.

As for multiple engines in core, no way that should happen. You are 200% right, people are not going to write templates for multiple engines and I can not blame them :)

But i do believe that in order to become a first classs HTTP response citizen that markup should be done at the last moment, and not like some contrib does with inline HTML in php code that is not a overwritable theme_ function. (preg_match hell) But based on the response needed it must be possible to create that from the render array, which i think should become a render object so we can properly overload, itterate, and inject that into decorators or output engines. Where the output engine handles the transformation into the needed response.

Twig syntaxed is derived from Django.

There're more context on that in Fabien Potencier VS phpTemplate, oops, wrong url title (ღ˘◡˘ღ). And in response to that Eli White VS Fabien Potencier, another bad choice of words for a title.

Also if you use backbone.js as your js client, which depends on underscore.js, you can override the template settings (see the last paragraph in the url under that heading/subject) to accept both twig macro syntax and phpTemplate macro syntax, using regex, er, I think. *untested*

There are Drupal functions available in php and js, like the t() function, that can be used in template as both php implementation and js implementation, but in js it is Drupal.t(). So it's possible to have template that lives on both world but the available functions that can be used is limited.

Edit: oh, and last I check $variable is a valid javascript variable name. Dunno if that mean anything (not a practitioner).

I'd like to make a note here that a change in PHP 5.4 will make templating a lot nicer:

http://php.net/manual/en/migration54.other.php

<?= is now always available regardless of the short_open_tag setting

The syntax would look like this (this is the Omega html.tpl.php converted to use the new syntax):

<?= $doctype ?>
<html lang="<?= $language->language ?>" dir="<?= $language->dir ?>"<?= $rdf->version . $rdf->namespaces ?>>
<head<?= $rdf->profile ?>>
  <?= $head ?>
  <title><?=$head_title ?></title>
  <?= $styles ?>
  <?= $scripts ?>
  <!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
</head>
<body<?= $attributes ?>>
  <div id="skip-link">
    <a href="#main-content" class="element-invisible element-focusable"><?= t('Skip to main content') ?></a> <!-- not sure if this would work or not -->
  </div>
  <?= $page_top ?>
  <?= $page ?>
  <?= $page_bottom ?>
</body>
</html>

Perhaps it's a little more readable. Perhaps not. Thought I'd note it here, though.

Status:Postponed» Closed (duplicate)

Agreed on #39 too

Another plus 1 for #39. Default should remain as PHPTemplate maybe with Twig as an option. I am a developer and I actually really like the way themes work now and think they just need a little tidy.

When I look at Joomla & Wordpress I see a lot more themes but I also see a more significant amount of entry level / amateur web designers. This makes WP and Joomla a good fit for low budget 5 page broucheware website.

I dont think we should be gearing Drupal towards this with a less complex solution to encourage these type of projects because it is not a natural fit. Case in point, Rocket Theme tried Drupal themes but it did not have the market - while Joomla & Wordpress thrive.

Also Drupal IMO has been more successful in Enterprise / larger projects because it has attracted higher skilled developers and professionals. We should be aiming towards improving in this area and anything for new comers should be secondary.

PHPTemplate maybe with Twig as an option

We need to get rid of this idea. We have had the option of PHPTemplate or some other template system/theme engine for a while now, and nobody did anything with it. We need to stop dragging along old code that isn't necessary, bite the bullet, and make an assumption. Assume that developers will use a certain template syntax and run with it. I don't care if it's PHP or Twig, but we just need to decide.

+1 to #73. Multiple tempate engines are a non starter because you are doubling (or more) the work of any contrib maintainer that has a theme-interacting project. Usually choice is good; in this case, it's not. Pick one and run with it.

We have had the option of PHPTemplate or some other template system/theme engine for a while now, and nobody did anything with it.

I have a D5 site using phptal that begs to differ :-P

That said, supporting multiple engines out of the box is IMHO a waste of the community's limited time.

Fair enough using a single engine makes sense. However, replacing PHPTemplate with Twig entirely... this seems pretty drastic to me and maybe, it risks alienating the existing Drupal community, who have learnt PHPTemplate.

My concern, is PHPTemplate future-proof? I can see client side templating becoming increasingly important... What can we do to clean it up and make it nicer to play with? If the answer is Twig then fine.

However, for the argument of Twig for its more HTML/CSS syntax, I am not so sure a little PHP is really that much more difficult. Could PHPTemplate not be improved to be comparable eg <?= $var ?> vs {{ var }} ?

Why would it be a good thing if you had devs who work on modules in PHP and themers who work on themes in Twig? Surely we will just lose the benefits of a consistent language between themes / modules and the flexibility for people to cross over (in both directions).

Maybe Twig should exist in contrib until it has had some more exposure to Drupal?

before we as community decide if a engien should be swapped for a more modern system like twig, i think it is a beter idea to answer the question Dries also mentiones http://drupal.org/node/1499460#comment-5887630

WHAT is the target audience... themers who code, or builders who point and click and move the rest in order with some CSS?

Oh and like I tried to explain before, there is more to twig then just the basic {{var}} stuff.. Read a manual before jumping conclusions please..

My assumptions are that most themers are going to be graphic designers. Or at least that graphic designers should be able to theme a drupal site. (drag and drop site building is available with themes like mayo)

The idea that themers will want to use {{}} seems a little strange.

Their tools are setup to theme html/xml and php because wordpress/joomla/drupal/every other php based cms/ will require themers knowing
<?php if ( $ElementToPrint) { ?><div>My element</div><?php } ?>

I personally like joomla's xml parser of which allows a first theme to be created with no php, but you can use <?php as often as you want. This also has the advantage the dreamweaver support was just a matter of teaching dreamweaver about the <jdoc:include > tags.

The big hurdle for me creating my first drupal theme was the lack of a single file to start with. The tpl.php soup has power but it comes at a cost when getting your first theme setup.

I honestly wonder if a dreamweaver extension that auto breaks and assembles a drupal themes tpl.php files wouldn't be a more productive path for increasing the number of graphic artists that are willing/capable of creating a drupal theme?

I know of no graphic artists that list a templating engine on their resume, so I would postulate that using twig or smarty actually reduces the willingness of graphic designers to design for drupal (just checked the posted resumes of five graphic artists that I know).

See comment below.

My apologies, I just posted this, believing this was the right place, but now I see it is marked duplicate.
Removed comment, and posted it at:
http://drupal.org/node/1499460#comment-6625008

And if that isn't the right place either, I would really appreciate a place where people can voice their opinion on this issue. Feels now like where directed all over the place. ;)

Issue summary:View changes

Updated issue summary.