[meta] Should we keep / improve multiple theme engine functionality?

Given the comment in the other issue, perhaps that should be, "How many people do you know that use non-PHPtemplate engines in Drupal 7?" :)

I'm +1 for this. I don't want to have to think about more than one engine in my modules. I've put "requires phptemplate" on there in the past only to have users be confused as to whether they could use it because they had no idea there was more than one engine. LOL!

That you think it is pointless, does not mean that everybody else thinks the same. To me this issue is a rather ignorant way of forcing a choice, or forking the same disccussion into yet a other issue. I favor in closing this issue, and concentrate on more important things to clean up in the render pipeline than deciding wich lingo to use as a endpoint template system.

I agree with cweagans. This feature is 99% dead already.

Hmm, it looks like there's at least some alternate theme engines available for Drupal 7 (i.e. last commit to PHPTAL was 8 weeks ago), whether anyone's using those is a different question of course, http://drupal.org/project/theme%20engines

Without answering for ReneB it looks like they might have misunderstood the purpose of the issue. The idea here is not to commit to using PHPTemplate and nothing else, it's to remove the feature in core to run multiple different theme engines simultaneously.

So if we moved away from PHPTemplate to Twig that wouldn't be impacted by this issue either way - it'd just mean you wouldn't be able to choose a different template engine other than Twig in Drupal 8.

While the code supporting this is quite old afaik, and doesn't really use any of the patterns we have elsewhere for pluggable functionality, IMO it's not really something that comes up often in terms of 'features in core that give core developers a headache', there's plenty of stuff that's much more of a pain to deal with. Would be interesting to see how much could actually be simplified by removing it, or possibly if there's way of making it pluggable (plugins, variable includes) that could be less embedded.

The output engine is NOT the big issue here, and yes people besides me are using alternative engines in production environments.

The 'overhead' of having the ability to use a different way of getting variables into HTML is a small
pebble compared to the enormous rock called render array. And removing the option to call a different render() method is not making that problem magically disapear.

In a decent controller-view application, the controller (drupal core) gathers data and hands that over to the view method (render engine) without being aware what view is. Because a view should be de-coupled with a single point of entry.

But let me turn the question around, what is the gain of removing that decoupled option to run a different theme engine? And if the answer is that it is easier for contrib authors to maintain templates. Well then rethink your answer, because people like me who volunteerly choose to use a different system then phptemplate never asked contrib authors to support our theme engines by enforcing them to deliver twig, smarty or what ever templates. All we need is proper document _theme() methods or even better a tpl.php for the output instead of deciding what mark-up elements should be used for us by returning fully rendered HTML, so we need to use massive amounts of regular expressions, str_replace etc. in template.php to regain control over our output.

So yeah, here is the challenge convince me and the other non phptpl users, what do we REALLY gain by removing engine support from D8?

It seems to me that a time at which we're considering changing our theme engine completely is one at which the ability to have more than one would be useful.

If D8 changes to twig tomorrow, then a lot of theme projects on d.org are not going to make the upgrade to D8, or will take even longer. Allowing them to upgrade less painfully to D8-Phptemplate, and then perhaps later on to D8-twig would help matters, I think.

And if like catch says there aren't particular developer headaches here, I think it makes sense to keep this around for now at least if it can help ease the transition.

If D8 changes to twig tomorrow, then a lot of theme projects on d.org are not going to make the upgrade to D8, or will take even longer. Allowing them to upgrade less painfully to D8-Phptemplate, and then perhaps later on to D8-twig would help matters, I think.

That is one of the major reasons I would like to have the option to run different theme engines. I don't think enforcing a template engine is the smart way forward for a product like drupal, whom tends to become more decoupled with the embedding of several symfony components.

But then again, there is always to option to fork Drupal with a different template engine if needed :)

Could anybody do a very basic investigation / rough patch how many pieces in core the proposed multi-engine removal simplifies? Even when we never commit it, this execrise helps to understand better the problems in theme layer.

Same goes for the proposed plugin-based approach.

The support for multiple/concurrent theme engines is essential for supporting alternative theme engines. That is, because an alternative theme engine may provide theme function and template replacements for Drupal core, but it is impossible to provide replacements for 13,000+ contributed modules.

Thus, an alternative theme engine is only ever possible with the concurrent theme engine support built-in.

Furthermore, AFAIK, the concurrent theme engine support allows to mix and match themes with base themes, regardless of the theme engine they're using.

The code for multiple theme engine support is not easily identifiable. Grepping theme.inc for "engine" yields the affected code, which is not much, and which also does not really add much complexity. The complexity of the theme system lies elsewhere.

I do admit, however, that it appears that the entire functionality is not really backed by tests in any way. Since alternative theme engines are rarely used, there also seems less of an interest by Drupal core developers to work on the topic.

But since the functionality most probably could not be replicated in contrib or without hacking/forking Drupal core, I do not see sufficient reasons for dropping it.

people like me who volunteerly choose to use a different system then phptemplate never asked contrib authors to support our theme engines

At the moment, using an alternate engine is fairly obscure and takes a lot of work in general. If it were to become more popular, I guarantee you that contrib maintainers would be getting pressured about it. Even with it not being popular, I've had plenty of confused users who have tried to use my modules with non-PHPTemplate themes who simply didn't know anything about theme engines and didn't know it wouldn't work.

If what is in core to allow it is functional and needs minimal care then I'm with Sun and say just leave it be as is. I could have sworn. though, it was discussed at Drupalcon as being broken. If that's the case, then keeping it means more work. Unless someone is stepping up to volunteer for the job, I'd say let it go.

To clarify because there's a disconnect between me saying it's a pain and then saying it was done accidentally, the accidental ones occurred in previous versions when there was non-PHPTemplate still in core. Chameleon, I believe it was?

As mentioned in #10, the compelling reason for keeping it is that an alternative theme engine is only possible with the concurrent theme engine support built-in.

Without that, it wouldn't be easily possible to experiment with a new Twig engine for D8, or the hypothetical Santra engine for D9 (or on custom D8 sites).

It is true that various people stated that alternative theme engine support would be broken since D7, but I've yet to see actual bug reports about that. Also a bit confusing, since @ReneB seems to successfully use his Twig implementation on Drupal sites. So the "broken" is most likely limited to certain engines only. Without concrete bug reports to analyze, this point is a bit pointless.

The size/maintainability/performance arguments are a bit moot at this point. The functionality is only a few lines of code, so size is no argument at all. Lacking proper bug reports, the functionality seems to work and does not really add much complexity to the theme system, so it is maintainable. And based on the code the grep yielded earlier, I don't think that there's any performance penalty involved with the functionality.

sun: Furthermore, AFAIK, the concurrent theme engine support allows to mix and match themes with base themes, regardless of the theme engine they're using.

That actually works in Drupal 7, just tested that for my Frontendunited talk Saturday, the only problem is if you use a php-template theme as base, the first time the child theme is scanned it is scanned for php.tpl files. Then the theme files are stored in the theme registry and the 'overhead' cweagans seems to insist on having is removed.

Then in _drupal_theme_initialize in theme.inc is fired to init the theme engine.

if (isset($theme->engine)) {
    // Include the engine.
    include_once DRUPAL_ROOT . '/' . $theme->owner;

    $theme_engine = $theme->engine;
    if (function_exists($theme_engine . '_init')) {
      foreach ($base_theme as $base) {
        call_user_func($theme_engine . '_init', $base);
      }
      call_user_func($theme_engine . '_init', $theme);
    }
  }

And in the theme() method this list part is called to actually render the template.

{
    // Default render function and extension.
    $render_function = 'theme_render_template';
    $extension = '.tpl.php';

    // The theme engine may use a different extension and a different renderer.
    global $theme_engine;
    if (isset($theme_engine)) {
      if ($info['type'] != 'module') {
        if (function_exists($theme_engine . '_render_template')) {
          $render_function = $theme_engine . '_render_template';
        }
        $extension_function = $theme_engine . '_extension';
        if (function_exists($extension_function)) {
          $extension = $extension_function();
        }
      }

All the other 2700+ lines in theme.inc are used by drupal to generate various other theme stuff, and that my friends is way more overhead then simply supporting a non php-template theme engine. Not to mention the endless amounts of contrib _theme() methods with alter hooks and more.

Can we close this non issue now please, because in all reasonability there far more important issues to discuss about then this one :)

I tried implementing a theme engine in D7 because there is no XSLT processing. The theme engine API is not well organised and could use a clean up. The model works for MVC but breaks down when working on HMVC. I stopped working on the XSLT engine because it could not cleanly accomplish what was needed.

Responsive design is one of those areas where HMVC is preferable to MVC. If there was a project to change the code in the template engine API area, there are things worth changing without stopping one site from running PHPtemplate while another uses a Twig engine and another uses an XSLT engine.

@ReneB: Why do you want to shut down conversation? Just because you disagree with an issue doesn't mean it needs to be closed. It seems to be generally leaning in the "won't fix" direction but the issue has only been around for 2 days and you were already trying to shut it down one day in. If you aren't interested in discussing further, you can always unfollow.

For me, my main dog in this fight is to not be put in a position of being expected to support multiple engines. I don't think that will be a big issue with the barely working stuff in there because so few people attempt to use anything else. If it gets fleshed out more than that and multiple engines become truly viable, I hope something will be put in place to make it easy to support multiple engines within the same module without a lot of extra work.

Make themes assume that they are going to use PHPtemplate - only specify if you want to override it

Not sure which Drupal you're using, but my Drupal does that already ;)
http://drupalcode.org/project/drupal.git/blob/HEAD:/core/modules/system/...

Since Drupal 6, if I'm not mistaken.

Rename "Theme engines"

The primary use-case is templating, yes, but theme engines participate in the entire rendering/output process of the theme system. A mere rename doesn't make much sense to me, as it would potentially involve API changes due to renamed hooks and callbacks.

We want twig and phptemplate in D8. It's not hard to do it's not worth the debate to remove it.

Setting this active because I think there's more discussion needed here. If you object to the topic change, I won't fight a change back. I'm just trying to spin this into more of a discussion than a task until we have some sort of a consensus that this is wanted with all parties having a clear idea what's at stake.

There's some questions that need to be answered (feel free to add any I missed):

1. Do we want the ability to have multiple theme engines provided by core?
2. Is it possible to do in contrib? (I'm thinking it's not but here for completeness)
3. Do we want core to provide multiple engines if it provides the ability to use multiples?
4. Which engine(s) will core provide?
5. If multiple engines become popular, how will that be handled in contrib?
6. How much work is involved in keeping / improving this in core? Who's stepping up to do it?

Some of these, especially #4, are out of scope for this issue but I'm just trying to see the big picture here. #4 has a big impact on #5. If core provides multiple engines, it will be a lot harder for contrib to get away with catering to only one.

I edited question #3 after cweagans posted because I realized the way it was worded made an assumption that #1 was yes.

1. Do we want the ability to have multiple theme engines provided by core? - YES
2. Is it possible to do in contrib? (I'm thinking it's not but here for completeness) - We will investigate the possibilities. Would be good. Edit: I mean, providing engines in contrib. I am not going to bend over backwards to make this possible or easy. If it can work, it can, if not, then that's it. If you need a PhD to write a new one, then that's it. I hope this is crystal clear. Also: I do not expect this to be so bad. I need fabpot to make sure however.
3. Do we want core to provide multiple engines if it provides the ability to use multiples? - I would like phptemplate to stay.
4. Which engine(s) will core provide? - Twig and phptemplate.
5. If multiple engines become popular, how will that be handled in contrib? - You can write your theme using any of them.
6. How much work is involved in keeping / improving this in core? Who's stepping up to do it? - Me for the keeping part.

We will clearly document that Twig is the secure (and if our guesses are correct then sometimes faster) choice but not providing any choice is not a good idea. We will strive to keep some of the security advantages (obviously, impossible to keep all) available to PHPtemplate as well.

re #27: As you say, you cannot mix template engines, so it seems to me that there are only 2 possible answers to that question:

1. We remove support for multiple engines as you have championed in this issue
2. We keep support for multiple engines but we choose one to be the defacto standard the way English is the defacto language in Drupal but we offer tools to change that. This way if we choose Twig, then all core and all contrib will supply twig templates and the onus will be on the site builder who wants to use smarty (or whatever) to convert all the templates (s)he needs.

It seems to me that for many of the reasons described by sun above in #10, we should be going with #2

== my 2 cents

Oh, module authors. Module authors should provide Twig templates. End of story. We will make this clear.

Sorry. I forgot. You can mix templates based on extension. You could always mix ever since merlin wrote this in, I dunno, 2007 or something. Edit: indeed 2007, #130987: Create a registry for theme functions and theme templates.

Based on using twig, Smarty etc, elsewhere, you still have to provide some of the template.php equivalents elsewhere, probably hooks. If you are doing that for Twig, the PHP template system could be changed in parallel so that level of processing is the same and PHPtemplate themes are simplifies to just .tpl files.

Ok, I'm withdrawing my dog from the fight. :)

I was confused by #29 thinking that meant that a module could provide both twig and phptemplate template files to satisfy both engines, which is what I was trying to avoid doing. After chatting on IRC with chx and a few others, I finally understand that I, as a module author, can provide templates for just twig and people using phptemplate won't be screwed. Since this won't be doubling my workload to keep both camps happy, I'm just fine with leaving it in.

First, how much line of code this will remove?
@cweagans I think if you want this issue stay productive you should provide a patch than prove (or not) than the theme layer become a lot simpler if we remove this feature... (I really don't think so).

JFTR:

So, what about PHPTemplate? Well, it turns out the PHPTemplate engine is only about 30 lines of code: [...]

+

This sprint was a wild success for several reasons.

1. We proved that using Twig with Drupal is actually Possible.
2. We think that using by using Twig we may make Drupal faster.
3. We discovered that by using Twig, we could make 100% of all themes more secure.
4. We discovered that by using Twig, we could reduce the complexity of the theme layer.
5. And Lastly, we realized that we could find a way to keep PHPTemplate around for those who don't like change. (probably)

via Write Up: Twig theme sprint @ Chapter Three

Also: Write Up: Twig theme sprint @ Twin Cities Drupal Camp

However, while that is true that we can do this, there's the very real danger of keeping PHPtemplate will keep people from upgrading their templates to Twig and demand tpl.php templates from contrib authors. This is what Michelle was against and I get it finally. Needs consideration.

@chx some people will not and lot will be very excited to use twig for new project. Team using Symfony and Drupal are going to jump on twig for drupal :). I you are force to use twig, upgrade to D8 is going to be very painful. So no upgrade at all.

If you remove this from core, is going to be in contribs. I don't care if we don't have PHPTemplate anymore, as long as you can still plug an other template system so we can support PHPTemplate in contrib.

The only *pragmatic* question is "this really simplifying the code of core?". Apparently the answer is no.

When i saw module like statistic, dashboard and even overlay in core... discussion to remove *simple* and *extensible* functionality potentially very useful in migration time make me crazy. And even more when @cweagans arguing than is going to make the theme layer way simpler without providing a patch.

Don't get me wrong, if it will remove hackish code, complexity or lot of lines.. I will be the first to consider this.

I have being toying with the idea of saying "PHPtemplate is insecure" and shutting it down as an insecure project if anyone puts it up as a d.o. contrib. I am an evil man.

@chx Truly evil. Although if one of the D7 Twig projects works and we can work on changing themes to Twig in D7, removing the PHPtemplate theme engine from D8 would be much easier and your change would no be so evil.

peterx++

I'd happily start a new branch of the themes I maintain for twig compatibility, and that'd give me some time to get familiar with Twig, as there's nothing like actually digging into something and making it work to learn how it works...

phptemplate is not very much code. I think we should keep it in.

If we do, it will still be VERY DIFFERENT than PHPTemplate was in D7, so those who "don't want to learn something new" won't really have a choice. Twig will probably be easier to learn than PHTemplate in D7 (no need to learn OOP for twig). But those who are hardcore PHPheads and want their complete unsanitized objects and crazy function calls in the template files would be able to have them.

If you want to see some psuedocode for what PHPTemplate might look like in D8, check out the example at the bottom of this post.

As for other theme engines, I think having both twig and PHPTemplate (which we may be able to do by simply extending the twig engine) will serve as a great example of how easy it might become to add more theme engines.

edit: Also, adding PHP function calls inside templates in D7 sortof broke the pluggableness of our template engines, so I don't think we should use D7 as a good measure of "how many people are using something other than PHPtemplate".

Re sanitised/secure, both Twig and PHPtemplate let you display unsanitised data. The only difference is Twig defaults to unsantised and requires 4 extra characters in a token to display unsanitised data.

Based on all the examples I see and all the documentation on the Twig site, Twig is only half of PHPtemplate, the .tpl part. You still need the template.php part and that is where you would normally make your data safe for display. We will still need the dangerous Twig raw to display some data. If you receive AHAH, you do not want double escaping. There are many areas where Twig will produce the same as PHPtemplate and protect only against accidental display of inappropriate raw data. that is one reason for giving everyone a long lead time to practice with Twig.

So, anyone who wants to be evil can still be evil. Twig is just saving people from being accidentally evil.

Separate to everything else, has anyone twigged to the performance difference? This is worth a separate discussion. Twig compiles templates to PHP code similar to the code we enter by hand into .tpl files. Has anyone compared a twig to a .tpl for code performance?

I'm a bit late on this discussion and I must say I haven't read _all_ the posts and all the details, but I must say I've been playing around with a theme engine that let's me render haml templates to php using the MtHaml parser (that also supports parsing to twig, but I haven't explored that area yet).

My code is based on CitizenKane's (http://drupal.org/user/120977) peroxide engine that got me started working on this.

The beauty of Drupal's engine system is that it is quite simple to create a new engine and that you don't have to rewrite all the core or contrib templates to work with it, templates you define in your theme in haml, will be rendered with the engine defined in your theme, other templates, core PHPtemplate rendering - it all renders to html at one point and works great!

So I'm strongly for that we keep Drupal's support for alternative theme engines.

That said, I've uncovered a small bug (in D7) that makes it impossible to use template suggestions if you're engine's extension doesn't have a .tpl.[myextension] in it. I'm currently looking if there's an issue related to that and that is how I found this thread.

I have a patch for this core bug, so if anyone knows if there's already an issue where I could contribute this, some help or a link would be appreciated.

EDIT: I apologize if this is a bit of cross-posting, but I've opened an issue with a patch since I haven't seen anything related to my issue: http://drupal.org/node/1678808

Thanks.

Twig is currently on its way into core, and temporarily, PHPTemplate and Twig will both be valid engines. At some point, sooner than later we hope, PHPTemplate flies will be removed from core. What stands to discuss now, is whether, when that time comes should we generalize the code so that themes for d8 will still work if someone wants to write their template overrides in HAML (or something else)? Or are we abandoning all hope, and forcing modules and themes for D8 to adopt Twig only.

References:

* #1696786: Integrate Twig into core: Implementation issue
* #1697854: Allow modules to provide both .twig and .tpl.php templates temporarily until twig is the default engine -- merged into ^
* #1805592: Remove static double theme engine code once all module provided .tpl.php files are converted to twig and twig is default

There is no point in nuking multiple engine functionality. The supporting code for that is not a hell lot. We now know that merlinofchaos put a sane limiter in there which forces modules to provide their default markup via the default engine (phptemplate until now, twig soon). This limiter will be back before release and theme authors but not module authors can use whatever engine they like. Best of both worlds. No change and no need for change.

For anyone interested, there may be at some point an effort to turn the theme engine functionality into using the Plugin system, you may wish to follow #1685492: Convert theme engines into services (currently postponed).

Changing this to a meta issue, just to be clear.

My 2 cents: Twig is relatively new. While it is the bee's kness right now, we might bump into an even more awesome template system during D8 lifetime. Contrib developers will want to have it ready for use as soon as possible.

(Javascript community has zillions of template systems and they're still figuring out when to use one or the other).

I wanted to add that Symfony 3.0 is removing PHP templates support https://github.com/symfony/symfony/issues/12897

I was under the impression that PHPTemplate was dead! Sad to hear is still in Drupal 8. I've read some blog posts out there saying PHPTemplate is gone, but not.

People using PHPTemplate will need to sanitize data the old way. This is a security issue, that needs to be documented well in Theme Guide
https://www.drupal.org/node/1918824

This example by Jen: https://groups.drupal.org/node/234793 (How to use sanitized output in PHPTemplate is still valid? )

Wow, interesting find regarding PHPTemplate, @corbacho.

There's a recently-filed issue about this at #2528284: Document that alternate Drupal 8 theme engines must implement auto-escape or they are not secure so I linked to your comment over there.