Drupal 8 Theme System Sprint: Day 1

chx's picture

As jacine with angelic patience has explained her concerns over the last few weeks and suffered through my blundering over trying to solve them, I arrived fairly prepared for the theme sprint and we have agreed on a lot more than we disagreed. Actually we didn't need to debate over anything at all! :)

  1. On the caller side, we are going to go with something like

    $list1 = new Template('list', array('items' => array('listitem1', 'listitem2')));

    Of course, this can be made recursive:

    $list2 = new Template('list', array('items' => array('listitem1', $list1)));

    The Template class will have a __toString() method and that's how the recursive printing will work: automatically. This data structure will contain no caller-added HTML (ie do not add HTML to your modules) but it might contain user input HTML (for eg from the database). The templating engine needs to be responsible for making it secure.

  2. Speaking of security, on the templating end, we have agreed on that the templating provides a default escaping which is adequate for HTML text and passable for HTML attributes (although you probably want to strip tags instead of escaping tags for attributes). Text which should be run over check_markup will be carried in another class which has a __toString method which does the filtering automatically upon printing. So templates will never be required to specify escaping in order to handle security. In some cases, templates will want to print a variable that contains HTML in an attribute value or <title> tag, and therefore strip tags from it, and they'll have an easy way to do so, but not doing so will simply result in some markup appearing where it shouldn't, not in a security vulnerability. Currently we do escaping in preprocess and we do it poorly as we try to have one variable which fits. This is somewhat impossible as you might want to print the same thing inside a <h1> check_markup'd, inside a <title> strip_tag'd.
  3. Mostly because of security, we do not want templates to contain raw PHP. Basically the moment JohnAlbin stood up in Denver and said "We hand themers a loaded gun and tell them to hammer in a nail with it. Oh, and be careful" phptemplate was finally dead. Finally because the security team was thinking for many year on how to make PHPtemplate secure...
  4. Now, among the non-PHP solutions we really like Twig. It's extensible, security-focused, fast and it's what Symfony uses and we seem to want to woo Symfony developers.
  5. Coding commenced at http://drupal.org/sandbox/chx/1541306

Comments

template engines

old_dog's picture

Disclaimer: I know very little about theming and have zero experience.

To a mere mundane like myself, the engines Twig and Smarty seem like the same thing but with different numbers of these: {{}}.
Reading no.4 above and listening to the core conversation from Denver, I get the impression that while Twig is acceptable, Smarty is to be avoided like the plague. Smarty seems to very popular in other communities, so is there something about Drupal that doesn't play well with it?

hey, where's Day II and III ?

kika's picture

hey, where's Day II and III ? :)

Any update on this?

kika's picture

Any update on this?

Working on it!

JohnAlbin's picture

Been super busy. Sorry!

I'm going to force myself to make time tonight and write it up.

  - John (JohnAlbin)

How is it going? Likely next

kika's picture

How is it going? Likely next week?

Theme development

Group organizers

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: