Now that the new theming system is basically in (I have one outstanding patch and 2 more in the hopper that are not yet at patch level, but they shouldn't affect this), we now need a coordinated effort to properly .tpl-ify the majority of Drupal's theming functions. At the same time, I think we should also be looking at what isn't themable enough in Drupal and try to correct that at the same time. And this is a good place to try and correct Drupal's HTML/XHTML code to conform to the proper standards. The Themer Pack project was started as a gateway to this, and it hasn't been entirely successful (though I give HUGE HUGE HUGE kudos to dvessel who did a LOT of work on the themerpack, and calebg who started to but got busy).
Hey, From someone who hasn't really been following the changes, but who really hates PHPTemplate (which is designed more toward developers, rather than graphics artists and end users IMHO) and would much rather use Smarty... Will Smarty still be available as an option in 6? AKA. Will theme engines support still be there? Robin On 5/3/07, Earl Miles <merlin@logrus.com> wrote:
Now that the new theming system is basically in (I have one outstanding patch and 2 more in the hopper that are not yet at patch level, but they shouldn't affect this), we now need a coordinated effort to properly .tpl-ify the majority of Drupal's theming functions.
At the same time, I think we should also be looking at what isn't themable enough in Drupal and try to correct that at the same time. And this is a good place to try and correct Drupal's HTML/XHTML code to conform to the proper standards.
The Themer Pack project was started as a gateway to this, and it hasn't been entirely successful (though I give HUGE HUGE HUGE kudos to dvessel who did a LOT of work on the themerpack, and calebg who started to but got busy).
-- Robin Monks @ www.civicspacelabs.org @ www.gmking.org Fax: (419) 791-8076 "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC
My understanding (and merlin will no doubt correct me if I'm wrong) is that while theme engines have been there for a while no one actually used one besides PHPTemplate. Smarty and PHPTal were used as tag libraries on top of PHPTemplate. So what's happened is that the engine portion of PHPTemplate has been absorbed into core (with various refactoring to make it faster, better, stronger). I believe swappable tag libraries (named engines, technically wrongly at this point) are still possible if the maintainers of those engines choose to upgrade. (As an aside, I really think Smarty is overkill if it's just used as a tag library. Smarty's big benefit would be in pull-based templates, whereas Drupal, like most web apps, uses push-based templates. I now step down from the soap box.) On Thursday 03 May 2007, Robin Monks wrote:
Hey,
From someone who hasn't really been following the changes, but who really hates PHPTemplate (which is designed more toward developers, rather than graphics artists and end users IMHO) and would much rather use Smarty... Will Smarty still be available as an option in 6? AKA. Will theme engines support still be there?
Robin
On 5/3/07, Earl Miles <merlin@logrus.com> wrote:
Now that the new theming system is basically in (I have one outstanding patch and 2 more in the hopper that are not yet at patch level, but they shouldn't affect this), we now need a coordinated effort to properly .tpl-ify the majority of Drupal's theming functions.
At the same time, I think we should also be looking at what isn't themable enough in Drupal and try to correct that at the same time. And this is a good place to try and correct Drupal's HTML/XHTML code to conform to the proper standards.
The Themer Pack project was started as a gateway to this, and it hasn't been entirely successful (though I give HUGE HUGE HUGE kudos to dvessel who did a LOT of work on the themerpack, and calebg who started to but got busy).
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Robin Monks wrote:
Hey,
From someone who hasn't really been following the changes, but who really hates PHPTemplate (which is designed more toward developers, rather than graphics artists and end users IMHO) and would much rather use Smarty... Will Smarty still be available as an option in 6? AKA. Will theme engines support still be there?
Robin
In fact, I believe that smarty will be better (assuming someone maintains it and ports it to Drupal 6) due to these changes. The actual code in phptemplate.engine has been vastly reduced, and much of what it does has been made inherent to Drupal, and it the PHPTemplate renderer has been made the default renderer. Theme engines tell Drupal to use a different renderer (and, if they like a different extension). Additionally, theming with templates has been broken up into two sections, one for pre-processing, which is designed to transform data into something more suited for presentation (i.e, business logic), leaving the actual presenting to the template (presentation code). If you're familiar with the _phptemplate_variables() function in PHPTemplate, what we've done is made it so that *every* theme template gets one (actually, a series) of these in order to massage the variables so that the template itself can do as little as possible. Let's take a fairly minor example: Grabbing a theme function from aggregator module: function theme_aggregator_feed($feed) { $output = '<div class="feed-source">'; $output .= theme('feed_icon', $feed->url) ."\n"; $output .= $feed->image; $output .= '<div class="feed-description">'. aggregator_filter_xss($feed->description) ."</div>\n"; $output .= '<div class="feed-url"><em>'. t('URL:') .'</em> '. l($feed->link, $feed->link, array('absolute' => TRUE)) ."</div>\n"; if ($feed->checked) { $updated = t('@time ago', array('@time' => format_interval(time() - $feed->checked))); } else { $updated = t('never'); } if (user_access('administer news feeds')) { $updated = l($updated, 'admin/content/aggregator'); } $output .= '<div class="feed-updated"><em>'. t('Updated:') . "</em> $updated</div>"; $output .= "</div>\n"; return $output; } That's not terribly bad on its own, but it has a couple of things we really don't like to see at the theme layer, particularly that filter_xss, which is a real bear when using an alternate theme. The way this will look in Drupal 6 will be, approximately: /** * All arguments sent to the theme template will be in $variables. The only * argument this template accepts is 'feed', so we'll look there. */ function template_preprocess_aggregator_feed(&$variables) { $feed = $variables['feed']; $variables['feed_icon'] = theme('feed_icon', $feed->url); $variables['feed_image'] = $feed->image; $variables['description'] = aggregator_filter_xss($feed->description); $variables['feed_url'] = l($feed->link, $feed->link, array('absolute' => TRUE)); if ($feed->checked) { $variables['updated'] = t('@time ago', array('@time' => format_interval(time() - $feed->checked))); } else { $variables['updated'] = t('Never'); } if (user_access('administer news feeds')) { $variables['updated'] = l($updated, 'admin/content/aggregator'); } } And then, aggregator_feed.tpl.php will look like this: <div class="feed-source"> <?php print $feed_url ?> <?php print $feed_image ?> <div class="feed-description"> <?php print $description ?> </div> <div class="feed-url"> <em><?php print t('URL:') ?></em> <?php print $feed_url ?> </div> <div class="feed-updated"> <?php print t('Updated:') ?></em> <?php print $updated ?> </div> As you can see, this template can be in almost any language, with the exception that it probably should somehow support t(). However, it doesn't have to, because we have preserved and improved the old _phptemplate_variables() functionality. You can create this function: phptemplate_preprocess_aggregator_feed(&$variables) { ... } Or phptemplate_engine_preprocess_aggregator_feed(&$variables) { ... } Or garland_preprocess_aggregator_feed(&$variables) { ... } Note that the engine gets its very own preprocess function if it needs it. This isn't used by PHPTemplate at all, at this point, but other templating engines may need it to do auto-transformation should they so desire. }
Sounds good! Keep up the good work ;-) Robin On 5/3/07, Earl Miles <merlin@logrus.com> wrote:
Robin Monks wrote:
Hey,
From someone who hasn't really been following the changes, but who really hates PHPTemplate (which is designed more toward developers, rather than graphics artists and end users IMHO) and would much rather use Smarty... Will Smarty still be available as an option in 6? AKA. Will theme engines support still be there?
Robin
In fact, I believe that smarty will be better (assuming someone maintains it and ports it to Drupal 6) due to these changes.
The actual code in phptemplate.engine has been vastly reduced, and much of what it does has been made inherent to Drupal, and it the PHPTemplate renderer has been made the default renderer. Theme engines tell Drupal to use a different renderer (and, if they like a different extension).
Additionally, theming with templates has been broken up into two sections, one for pre-processing, which is designed to transform data into something more suited for presentation (i.e, business logic), leaving the actual presenting to the template (presentation code).
If you're familiar with the _phptemplate_variables() function in PHPTemplate, what we've done is made it so that *every* theme template gets one (actually, a series) of these in order to massage the variables so that the template itself can do as little as possible. Let's take a fairly minor example:
Grabbing a theme function from aggregator module:
function theme_aggregator_feed($feed) { $output = '<div class="feed-source">'; $output .= theme('feed_icon', $feed->url) ."\n"; $output .= $feed->image; $output .= '<div class="feed-description">'. aggregator_filter_xss($feed->description) ."</div>\n"; $output .= '<div class="feed-url"><em>'. t('URL:') .'</em> '. l($feed->link, $feed->link, array('absolute' => TRUE)) ."</div>\n";
if ($feed->checked) { $updated = t('@time ago', array('@time' => format_interval(time() - $feed->checked))); } else { $updated = t('never'); }
if (user_access('administer news feeds')) { $updated = l($updated, 'admin/content/aggregator'); }
$output .= '<div class="feed-updated"><em>'. t('Updated:') . "</em> $updated</div>"; $output .= "</div>\n";
return $output; }
That's not terribly bad on its own, but it has a couple of things we really don't like to see at the theme layer, particularly that filter_xss, which is a real bear when using an alternate theme. The way this will look in Drupal 6 will be, approximately:
/** * All arguments sent to the theme template will be in $variables. The only * argument this template accepts is 'feed', so we'll look there. */
function template_preprocess_aggregator_feed(&$variables) { $feed = $variables['feed']; $variables['feed_icon'] = theme('feed_icon', $feed->url); $variables['feed_image'] = $feed->image; $variables['description'] = aggregator_filter_xss($feed->description); $variables['feed_url'] = l($feed->link, $feed->link, array('absolute' => TRUE)); if ($feed->checked) { $variables['updated'] = t('@time ago', array('@time' => format_interval(time() - $feed->checked))); } else { $variables['updated'] = t('Never'); }
if (user_access('administer news feeds')) { $variables['updated'] = l($updated, 'admin/content/aggregator'); } }
And then, aggregator_feed.tpl.php will look like this:
<div class="feed-source"> <?php print $feed_url ?> <?php print $feed_image ?> <div class="feed-description"> <?php print $description ?> </div> <div class="feed-url"> <em><?php print t('URL:') ?></em> <?php print $feed_url ?> </div> <div class="feed-updated"> <?php print t('Updated:') ?></em> <?php print $updated ?> </div>
As you can see, this template can be in almost any language, with the exception that it probably should somehow support t(). However, it doesn't have to, because we have preserved and improved the old _phptemplate_variables() functionality. You can create this function:
phptemplate_preprocess_aggregator_feed(&$variables) { ... }
Or
phptemplate_engine_preprocess_aggregator_feed(&$variables) { ... }
Or
garland_preprocess_aggregator_feed(&$variables) { ... }
Note that the engine gets its very own preprocess function if it needs it. This isn't used by PHPTemplate at all, at this point, but other templating engines may need it to do auto-transformation should they so desire.
}
-- Robin Monks @ www.civicspacelabs.org @ www.gmking.org Fax: (419) 791-8076 "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC
Earl Miles wrote:
In fact, I believe that smarty will be better (assuming someone maintains it and ports it to Drupal 6) due to these changes.
The one place that the alternative engines will have to do real work will be that they should probably ship with their own versions of all the .tpl.php files that Drupal 6 will ship with. I expect this to number between 50 to 100 (depending on how hard we work to convert things over) but as you can see from my previous example, I expect most of the actual .tpl.php files to be fairly simple. It may even be possible to do the bulk of the conversion via regex and then test for anomalies.
The one place that the alternative engines will have to do real work will be that they should probably ship with their own versions of all the .tpl.php files that Drupal 6 will ship with.
I can see one problem with converting every nook and cranny theme_ function into .tpl and that is speed. It is related to the number of files loaded, to make matters worse, I doubt that any of the bytecode caches will help with that for heavy duty sites. That is unfortunate, because it is a rather elegant solution, fitted to how drupal works. Having said that, there are possibilities to improve it, depending what are we ready to trade. Caching - to db or a precompiled file full of theme_ functions are just two of the possibilities, you loose dynamism, but for production sites it is not required in the theme layer. By the way, the changes to the template system are great. HUUGE kudos to Earl and the little helpers for doing them.
Vladimir Zlatanov wrote:
The one place that the alternative engines will have to do real work will be that they should probably ship with their own versions of all the .tpl.php files that Drupal 6 will ship with.
I can see one problem with converting every nook and cranny theme_ function into .tpl and that is speed. It is related to the number of files loaded, to make matters worse, I doubt that any of the bytecode caches will help with that for heavy duty sites. That is unfortunate, because it is a rather elegant solution, fitted to how drupal works. Having said that, there are possibilities to improve it, depending what are we ready to trade. Caching - to db or a precompiled file full of theme_ functions are just two of the possibilities, you loose dynamism, but for production sites it is not required in the theme layer.
I completely agree. The primary thing to look at when converting a theme function to a template is how often this theme function gets used on a page. If it's a lot, then absolutely that function should not be converted. Some obvious candidates to NOT convert are theme_placeholder() and theme_username(). Making these functions into templates don't buy us much anyway. It's definitely a case of 'start with the big ones' and work to the small ones. Big ones are often used only occasionally per page; small ones might be used a lot.
On 04 May 2007, at 20:09, Earl Miles wrote:
I completely agree. The primary thing to look at when converting a theme function to a template is how often this theme function gets used on a page. If it's a lot, then absolutely that function should not be converted. Some obvious candidates to NOT convert are theme_placeholder() and theme_username(). Making these functions into templates don't buy us much anyway.
It's definitely a case of 'start with the big ones' and work to the small ones. Big ones are often used only occasionally per page; small ones might be used a lot.
Yep, we'll only want to convert those theme_ functions that are often themed. Here is a useful bash one-liner that you can run from contributions/ themes: contributions/themes dries$ for FILE in `find . -name *.tpl.php`; do echo $FILE | awk -F/ '{print $NF}'; done | sort | uniq -c | sort -rn | head -n 25 This command will compile a list of the top-25 most popular template files. The first column denotes how many different contributed themes ship or use that template file. 159 page.tpl.php 150 node.tpl.php 119 comment.tpl.php 103 block.tpl.php 81 box.tpl.php 14 search-box.tpl.php 4 node-forum.tpl.php 3 page-admin.tpl.php 3 image_gallery.tpl.php 2 style.tpl.php 2 search_block_form.tpl.php 2 search-theme-form.tpl.php 2 block-sidebar.tpl.php 2 block-custom.tpl.php 1 page_admin.tpl.php 1 page-front.tpl.php 1 node-weblink.tpl.php 1 node-story.tpl.php 1 menu_item.tpl.php 1 maintenance_page.tpl.php 1 main.tpl.php 1 links.tpl.php 1 header.tpl.php 1 comment_wrapper.tpl.php 1 comment_controls.tpl.php ... Unfortunately, this distribution isn't all that interesting ... -- Dries Buytaert :: http://www.buytaert.net/
Op maandag 07 mei 2007, schreef Dries Buytaert:
Unfortunately, this distribution isn't all that interesting ...
A better measure is to grep for ^function (phptemplate|$themename)_([^\s(]*) in /$themename/template.php These resemble the overridden theme functions a lot better. Since creating such a function is a lot less work then buiding the xyz.tpl.php files it is used much more often. By awk and sed skills are a bit too rusty to write a proper bash script that finds $themename. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
participants (6)
-
Bèr Kessels -
Dries Buytaert -
Earl Miles -
Larry Garfield -
Robin Monks -
Vladimir Zlatanov