[wp-trac] [WordPress Trac] #33472: Templating Engine

[WordPress Trac]

#33472: Templating Engine
-----------------------------+---------------------------------------
 Reporter:  KalenJohnson     |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Themes           |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  administration, template
-----------------------------+---------------------------------------

Comment (by jarednova):

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

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

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

 {{{
 <?php

 class RollingStone_Post extends TimberPost {

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

 }

 }}}

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

 - ''This requires a different environment from the logical one used to
 setup theme configuration and define plugins. Forces developers to learn
 multiple syntaxes. (BTW - Theme configuration like theme supports and
 enqueuing really SHOULD be moved into a declarative language like JSON)''
 Can't agree more about dependency management. We've long since crossed the
 threshold of multiple syntaxes with PHP, HTML, CSS, JS. I'm not trying to
 say that this shouldn't be a consideration but Twig brings with it a
 comparatively small amount of additional syntax. I've been teaching it to
 co-workers/clients (who are primarily designers) over the last few years
 and everyone is like "whoa! that was easy." With developers, I don't even
 have to train them b/c they've seen virtually identical syntax in
 Mustache, Handlebars, Liquid, etc.

 - ''Unlike PHP, plain text files like json or twig are publicly accessible
 without special server setup to block viewing them. Themers would probably
 need to learn new security best practices.''
 I think this is a very good concern to highlight. While the security
 exploits aren't obvious, I can see how a small risk multiplied by 23% of
 the web could create a major unforeseen gap in security.

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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33472#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform