Why did creating themes get so scary?

Jen Lampton

13

May 15, 2011 - 3:45am

There are a lot of great things about being a Drupal Trainer. My favorite is getting to see -- first hand -- how the code we write affects the community.

I noticed that with the release of Drupal 7 - the demand for training on theme development increased dramatically. It took me a while to figure out why - exactly - but after a night of heated Debate in IRC with chx, mikey_p, HedgeMage, heyrocker, and yoroy (among others) we may have arrived at a conclusion.

Chx pointed out that the best Drupal themes are made by developers - people who know Drupal really well, and understand all the code. Even though he is probably right (and most of the themers we have at Chapter Three really are developers, too) I have always seen the theme as the entry point for people who are new to Drupal. I assumed this was because the template files (the ones ending in tpl.php) were written in HTML - and this is a language most people in web are already familiar with. It's the piece of the system that, until recently, seemed the most approachable. So what changed?

People who aren't entirely comfortable with PHP seem to have no problem reading logic in template files, things like

<?php
if ($sticky) { print ' sticky'; }
?>
seem to just make sense. But things like
<?php
hide
($page['thing1']); print render($page['thing2']);
?>
make people pause.

Words like 'if' and 'print' are pretty easy to figure out, even if you don't know any PHP - they're just English, and thus self explanatory. Based on the amount of explanation I usually need to provide in my theme classes on arrays vs objects, I think it's the presence of these data structures in template files that scares people off. When what they saw in there was

<?php
print $header;
?>
they were fine, they just worked around it and let it be. But when that became
<?php
print render($page['header'];
?>
they could all of a sudden see that there was something else there that they didn't understand, and they start to think "Maybe it's better just to leave it alone."

The last thing our community needs right now is a decrease in the number of new people who are jumping into code and giving it a shot. Those people with the ambition and do-it-yourself attitude are going to be our next jr devs, and maybe even our next experts! We need them in our community to support the huge growth in Drupal adoption.

In a lot of ways I think the Drupal 7 theme system is vastly superior to Drupal 6, but was the decision to use data structures in templates a mistake?

Work has begun on removing these data structures from the top most levels (http://drupal.org/node/1158090) Join the discussion and let us know what you think!

Comments

I agree. Template files (especially page and node tpl) should be completely understandable by someone at the designer level and not require drupal specific knowledge. print $header is easy to understand. But as soon as you put render(), now you have to search through documentation to see exactly what that means, etc.

Good call...

maybe the increase in requests for theme training is related to the fact that themeing changed a lot in 7, rather than there being some kind on intellectual deficit regarding data structures that themers just can't overcome.

is there any data that suggests people in general (as opposed to the 6 people listed above) have a specific problem with data structures, and that the proposed fix in [#1158090] will improve things?

i think it would make more sense to test this theory (in a usability testing kind of way) before spending time developing and advocating for adding new features (and hence complexity) to the theme layer in the name of simplicity.

for example, you could provide someone without previous exposure to drupal and present them with one of three page templates - a drupal-6 style page template, a drupal 7-style template, and a new version with the proposed write() function, and see how well each group performs trying to make basic manipulations to the template.

Thanks for this article and having this discussion. I think there has been fantastic theme changes, but other changes have made it really hard for beginner themers. I remember for example I was against moving out of the page.tpl.php, this is also a point that makes a beginner themer go wtf. I think the patch proposed by chx is great, and its the way to go! Thanks to everyone involved in this for your hard work.

The division between 'themers' and 'developers' in the Drupal community has always confused me a little. As a web developer who works on relatively small projects I interact with lots of different parts of the Drupal API during a project, the theme layer included. I try my best to keep any business logic out of my template files and when I create new functionality with a custom module I also try to keep it modular and within the spirit of Drupal's extensible nature.

As a web programmer though I want full control over what my framework (Drupal) outputs to the browser. I think the changes to the API in Drupal 7 make that easier. I'm trying not to pick sides here but I'm not sure the 'themer/developer' binary is helping us out.

FYI, the commit logs hold the answer to your question. In particular, interested parties should read and understand http://drupal.org/node/455844.

I'll also point out that themers who don't like render() and arrays in their templates are welcome to use preprocess to render and just print strings in the template. That D6 technique is still available and perfectly valid.

Moshe, what would we miss if we used the D6 approach (rendering in preprocess functions)? If we wouldn't miss anything, why have we changed the templates?

If it's rendered in preprocess, that alone makes an assumption for all themes because preprocess runs stacked from module preprocess all the way into any theme or sub-theme.

seems like a lot of Drupal Trainer and Developer don't know how to programming. they was crammed full of drupal stuff only.

Every framework have their own style, you have to learn something new if you want to use it.

No needs to do usability test, it don't always tell you the right answer. If you are really want to get more people to understand it, just copy Wordpress stuff into Drupal, that's all.

The question and maybe the solution is to use preprocess in core.
People that create themes for drupal should ideally be designers because we don't need more cleverly programmed themes, we need more and foremost more beautiful themes.

So maybe providing default preprocess that can be overridden in template.php inside your theme would be the way to go? People that need the flexibility could use it, the others never get to see it and just print variables.

Maybe my lack of technical knowledge is tricking me and this is not possible at all :P

Indeed! This is just what they are up to with the patch in http://drupal.org/node/1158090 . It looks likely that something just as such will likely be commited to 7.1!! I must say we are in the same boat with training themers. It's a big scary transition for some away from wordpress theming.

As a designer it was frustrating the lengths I was going to to simply removed extraneous html.

This new system in Drupal7 is huge relief because I actually have control on the theme layer of what gets printed on the page.

It looks longer on the templates but the advantage is that you don't need some of the workarounds that were needed in Drupal6.

I think that this actually makes it easier for new people overall.

Seems like there should just be a base theme for new designers instead of changing core.

+1

In Drupal 7 there *is* a base theme as part of core. It's called "Stark" and contains almost no style aside from a simple example of layout, and far less HTML than traditional Drupal themes - for those of you HTML Purists who want to do it your own way :)

Post a comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
Let us know you're human by typing in this code. The code is case sensitive.
Image CAPTCHA
Enter the characters shown in the image.
To prevent automated spam submissions leave this field empty.