tpl.phps are not templates

Drupal's template files (*.tpl.php) are not really templates. This is what my DrupalCon core developer summit submission is about. The slides briefly explain why tpl.phps are not real templates, what real templates are, why this is a problem for the Drupal project and community, and mentions some possible solutions to the problem. It also provides some basic guidelines as a starting point for tpl.php standards, should that be pursued.

Download the slides here.

AttachmentSize
Drupal tpl.phps are not templates.pdf294.24 KB

Comments

I actually like Drupal's

I actually like Drupal's standard template system, because it reflects PHP's original intention of being a presentation language. Of course, PHP has evolved since, and from a designer's point of view Drupal templates aren't easy to handle.
I don't think that Smarty, which I very much dislike, is a viable alternative for anything, because you have to learn Smarty's ugly syntax and you can use loops, control structures, and even pure PHP code within {PHP} tags anyway. Please show me one Web designer who thinks Smarty templates are easy to work with.
I think the Django template language http://docs.djangoproject.com/en/dev/topics/templates/, which is similar to Smarty in some respects, is a good example of a template system that doesn't suck completely. It won't execute arbitrary code expressions as opposed to Smarty and offers very useful features, such as Template inheritance, which allows for using a base template that can be overridden by child templates.
I hope Drupal will continue to support PHPTemplate and not adopt Smarty in core. A system similar to that of Django templates could solve some of the problems you mention, but I don't think any solution will provide for a complete separation of logic and markup.

You could still use XTemplate

It seems you are advocating going back to a past we thought long gone, with XTemplate and Smarty. PHPTemplate has arguably simplified themeing, by removing the need for a special half-baked grammar.

If you look at Django, for instance, they've had (arguably because Python is not free-form like PHP) to recreate all basic control structures in their template language, because, as your last slide suggests, there is really no place to "draw the line". Just because .tpl.php can be abused, as in many cases they are, does not mean they should be replaced by a less powerful solution. Or should they ?

Hey Bevan, are you aware that

Hey Bevan, are you aware that Smarty and a number of other template engines were distributed with Drupal in the 4.6 days?

http://drupal.org/project/theme+engines

exactly

I started out building blogs/websites with Greymatter, moved on to MovableType, early Wordpress and then Drupal. Especially MovableType (I only worked with 1.x and 2.x releases) had a very themable template system with easily readable functions and variables. Wordpress introduced more actual code but due to limited functionality in earlier releases, still quite understandable. Digging into Drupal was quite a shock and actually prevented me from taking Drupal to where I wanted it to go. As other parts of my life became more important and asked for more of my time, my time for Drupal became less and less and even with prior templating skills, I never got around to properly skin a Drupal site as I wanted to.

Yes. I was not involved in

Yes. I was not involved in those decisions and changes, but read some of discussion and reasoning at that time. It would be important to look back at those changes and the reasons behind them in order to have this debate.

I am not advocating anything.

I am not advocating anything. I'm merely stating a problem and suggesting some possible fixes. I don't know if any of them are better (on the whole) than PHPtemplate. I've heard good things about Django's templating system from various sources and suggest it's something we look at a little closer to learn from.

I like PHPtemplate too — but

I like PHPtemplate too — but I don't like most tpl.phps. I only like tpl.phps which are a well-formed markup files.

Thank you for clarifying some of the issues with Smarty. I doubt that Drupal would adopt smarty in core.

Your presentation doesn't

Your presentation doesn't mention the other big disadvantage of PHP template systems, which is that it is waaaay too easily to accidentally introduce XSS vulnerabilities. This is a only way off (in term of possible core inclusion), but looks pretty interesting from that point of view:
http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-writ...

The other template system I have heard people talk about is:
http://phptal.org/

Thanks for reminding me of

Thanks for reminding me of PHPtal — this is one I really really like, but haven't had the opportunity to try or play with. I forgot about it when writing the slides.

XHP looks interesting. It seems vaguely similar to an idea I present in the slides which involves parsing tpl.phps as PHP strings. E.g.

  <h2>
    <a href="{$url}" title="{$title}">{$text}</a>
  </h2>

Know your history before you discuss the future

First off anyone thinking and talking about template systems in Drupal and phptemplate in particular should read Brian Lozier's article from circa 2003, you can find it on his own site or reprinted on Sitepoint (with better formatting but more adverts - take your pick!).
This article was the inspiration, and the initial code base Adrian Rossouw worked from (with Brian's permission) to create the first phptemplate for drupal.

Smarty is no answer at all. It's so complicated it basically boils down to learning smarty braces vs php braces. It keeps designers in a designer ghetto, they'll never learn php, never find themselves delving into template.php and acquiring a bit more power. Also the smarty theme engine exists already smarty, has done for as long as I can remember – why is it not more popular if it's a good solution?

phptal is more interesting. IIRC Adrian Rossouw looked at implementing that around the same time as phptemplate and found phptal too slow. But time moves on, we're at least one major php version down the road, it could be worth taking another hard look at phptal – once again it's already available for drupal, so go download phptal do some benchmarks and let us know. Contrib is the place to find the way forward.

You're right that it's best practice to keep logic in modules or template.php, you're right that best practice is not always followed in the Drupal community, but I think that's a matter of education and policing, rather than a different templating system. You're suggestion of coder module is good, if it can be made to work.

I agree it's important to

I agree it's important to look at the history of theme engines of Drupal past. I have not done this. Thanks for your comments on smarty and phptal. phptal requires parsing template files into xml objects and manipulating the DOM server-side — which is generally quite expensive and unperformant. I agree more testing would be great.

Wednesday 11am, room 212 DrupalCon San Francisco




UPDATE:

I've scheduled this presentation and discussion on tpl.phps are not real templates as a BoF session on Wednesday at 11am in room 212 at DrupalCon San Francisco.





Iterations and display logic

It's ok for a template to have logic but it should be display logic. I've implemented both Smarty (with php tag disabled) and php templates in non-Drupal systems for extensive use by groups of people at different skill levels. Over time, the php templates degenerated in ways that the Smarty ones didn't (due to developers helping out at times and abusing the php templates under normal commercial pressures).

Having said that, I don't use Smarty in Drupal due to the fact that phptemplate has been adopted as standard and portability between devs/providers is more important.

One thing to consider in a templating system is how to handle iterations. If you take a purist approach where there are no loops and any iteration uses a placeholder plus inner template, it can be very difficult to translate from an html mockup - this is a 'pinhole API' and is a bit like putting a ship in a bottle. http://www.phpwact.org/pattern/template_view has more about this.

As the author of PHPTemplate and the theme engines

I can tell you that there is some logic in templates that will always be necessary.

I built the preprocessing etc. layers to try and separate as much of the code out of the templates as possible, and in the original documentation and templates i was adamant about not making ANY function calls other than print() inside the template files.

But all this is is semantics. The most we can do is try to make it as easy as possible to not want to cheat and add business logic to your template file.. and there are some templates that make it ridiculously hard to achieve that (see: theme_table). Changing the template language isn't going to make that problem any less complex.

most other template systems work by creating a custom parser, and then interpreting the templates in real time (slow), or by compiling the templates to php, which is potentially faster but you end up with caching issues.

Implementing a new template engine is as simple as re-implementing 2 or 3 functions, and then providing a new set of default templates (the real hard work). The fact that 'phptemplate' is the de-facto standard is proof that php itself is sufficient to solve the problem. The issues we have with phptemplate are actually issues we have with PHP itself (ie: no sandboxing and so forth).

I personally _LOVE_ phptal, and I think it's the correct solution to the problem. if it wasnt for the php4 performance issues (that might be less in php5), i would have put all my efforts behind it. I was able to take any existing site on the net and turn it into a working drupal template just by adding some tags to the final markup the site produced.

It's one of the few template engines that could lead itself being an isotemplate engine (ie: you have a single template file to edit) as you should be able to just add some METAL tags to an HTML to define which theme hook you want to define - http://phptal.org/manual/en/split/metal-define-macro.html, and your template file is your live preview. It also enforces you to use proper XML (which could be seen as a bad thing too).

But really what it comes down to in the end is that any templating engine that is sufficiently powerful to solve the issue we have, could be used to develop these templates you hate so much. and changing language limits the amount of people who can solve the problems.

A correction

Adrian Rossouw tells me that the article wasn't inspiration for his work on phptemplate for drupal. The article still explains the phptemplate ethos though.

Thanks for your input Adrian.

Thanks for your input Adrian. This confirms that there is still not a good solution for this.