Drupal is very themable. There's so many ways to theme content that it can be very confusing to remember/figure out what's responsible for what. And then if the stock theming capabilities aren't enough, once you've installed Omega (and possibly Delta and Context) and Display Suite, they haystack's size increases exponentially.
I keep finding that things that are supposed to make things simpler or easier, actually don't.
Example.
I don't like the way Drupal core creates the post date and author's username for a blog. I don't want the two things in one sentence. Here's some options:
- Edit the node template for this particular content type.
- Ok, my node template is from Omega, so I'd have to start there. Copy node.tpl.php to my (sub)theme's folder and edit it.
- I can either put the presentation logic here, or
- create a variable in my theme's node preprocess hook (which, also because of Omega, is somewhere non-standard).
- Ok, my node template is from Omega, so I'd have to start there. Copy node.tpl.php to my (sub)theme's folder and edit it.
- Use Display Suite (DS) for whichever view modes this field would display in (so, at least the Default view mode used for node views).
- Create the content in DS
- I can use a code field. Edit code in a textarea? Yuk, no thanks.
- I can use a preprocess field. Ok, better, I can keep all this stuff in my template.php and use a proper editor.
- Create the presentation logic code in a function in theme's template.php file
- Ah, but now all my selectors are upset. My HTML5 Omega theme uses <article> and DS creates <div>s with quite different classes.
- Ok, let's edit or write a new Display Suite layout template because my selectors were fine from a meaningful markup point of view.
- Then select that template, re-do which fields go where ...
- Create the content in DS
| Edit template file? | Edit php code? | Edit database settings through GUI | |
|---|---|---|---|
| What's the problem? | Edited template files need to be maintained against the template they replaced. Otherwise an update to the module that provided the original might affect functioning or formatting. | You need to know what you're doing. A parse error will bring entire site down. (not that you work live, though, of course.) | Difficult to copy your changes from development site to live site. |
| Method 1 | Yes. Maintain as diff from Omega's node.tpl | Optionally | No. |
| Method 2 | Yes. But it's a layout template that belongs to Display Suite. Maintain against DS. | Yes | Yes. Content Type > Display > Display Suite... |
Lessons Learnt
The wealth of modules out there offer ways to do things differently, but they may not be bolt-on extras, they may require whole rewrites of themes, code and of course, database-stored config.
Whereas I thought I was adding a bit of functionality I was changing functionality. Whereas I believed that a tool would enable me to achieve things in a flexible way through the GUI, I have found that it's always going to come back to PHP, and that now there's a whole new learning curve to climb and keep on top of.
I am not being negative about any of these great projects, but am sharing the realisation that if you're going to use these new-shaped building blocks, it's going to take you a while before you beat your high score at development Tetris.
If you're going to use these new-shaped building blocks, it's going to take you a while before you beat your high score at development Tetris.
Add new comment