When it comes to WordPress theme development, one or the areas that developers often find themselves wrestling with is just how verbose they should make their code.
For example, we’re often taught and strive from principles such as DRY and KISS, but it’s hard to maintain both of these when building WordPress themes from the ground up.
For example (and as according to the Codex):
At the very minimum, a WordPress Theme consists of two files:
– style.css
– index.php
And for anyone who has done extensive work in WordPress development knows this to be true; however, if you’re getting into theme development – that is, specifically for bloggers, or digital publishers – then you know there’s a wide variety of templates that are also supposed by the WordPress Template Hierarchy.
To name a few:
- style.css
- rtl.css
- editor-style.css
- archives.php
- author.php
- category.php
- comments.php
- date.php
- index.php
- single.php
- tag.php
- …and so many more
But here’s the deal: it’s nearly impossible to embrace DRY while simultaneously trying to implement each of these templates.
Instead, we’re left with having to repeat a variety of code all the while doing so when much of the code could be produced though template parts and conditional logic.
Though I’m sure we all fall somewhere in between on this issue, he’s where I’ve landed with respect to the various themes that I’ve developed over the last couples of years.
WordPress Theme Development: The Blogger
First and foremost, when it comes to building WordPress themes, you need to think about the various people in your audience. The fancy term for this is the market segment, but the truth is that users can usually be divided into at least one of three groups:
- Bloggers
- Designers
- Developers
Naturally, there is some overlap between the designers and the developers.
Anyway, this is where the choice on how to structure your theme comes into play.
If you end up building a theme primarily for designers and/or developers, then you can most likely get away with building a theme that uses a variety of conditional statements in `index.php` with a few partials (thanks to `get_template_part`) to make the entire blog function.
No problem, right?
But let’s be honest: The majority of the audience for themes are going to be people who want to blog in some form or fashion. This comes in terms of sharing long form articles, tumblelogging (or, in WordPress-world, heavy use of post formats), sharing photos, videos, and so on.
In short, it’s people who want to share content.
To that end, how the theme is built doesn’t matter as much to them as long as the theme looks good (which, I know, is subjective), helps them achieve the things they want to get done, and it looks good to search engines (let’s face it – everyone wants their site to look good to search engines), then you’re good to go.
Let’s Not Kid Ourselves
People love to tinker – if they find another font they like, they want to use it. If they find another color they want to use for part of their site, they will.
And the blessing and curse of open source is that they – like us – have the ability the modify the core code of their product to fit to their liking.
But just as we – as developers – know that we should never touch the core code, we’ve done a poor job evangelizing this to our customers in the theme marketplace about our own work.
Remember: view the theme as the core product and child themes as those customizations.
Sure, some people offer up a `custom.css` (and I’ve been guilty of this at some point), but as soon as a new upgrade appears for the theme, those changes will likely be overwritten or simply made irrelevant if the elements that they alter are to be changed.
Think of the Children!
So here’s a dilemma that I’ve been faced with while building Mayer: I want to make sure that I have as strong as a theme as possible.
First, I’m targeting the theme to the following audience:
For the established, frequent, long-form bloggers, and for those who aspire to be.
Easy enough, right?
Sure, I could go on about typography, readability, and all of that stuff, but what’s the point if those things are not only subject to change, but are going to be visible in the demo?
Secondly, I’ve gone against the grain of trying to keep it DRY and have implemented a number of different templates. These include (but are not limited to):
- 404
- attachment
- author
- category
- comments
- content
- date
- header
- index
- page
- search
- searchform
- sidebar
- single
- tag
- …and more
And the reason is because I know that inevitably someone is going to want to modify the theme to fit their liking. And that’s fine, but I want to make sure that I’m setting themselves up for success.
The way to do this is to think of the children – specifically, the child themes.
If the templates are defined in the base theme – rather than, say, a bunch of developer-ish conditionals – users are going to have an easier time basing their templates off of something that already exists.
On top of that, even though the code is a bit repetitive, it helps to know exactly where I need to edit should (read: whenever I notice) a bug arise.
But that’s the content for another post.
Keep It DRY, Except Not This Time
So if I had to sum this up in some concise way, I’d say that I – like many developers – want to keep my code as DRY as possible, but there’s a tradeoff that comes with doing so in the context of WordPress theme development.
And I don’t think that staying DRY is the best way to go about it if you’re going to be marketing a product to a wide audience.
I’ll likely talk about this more in the future as it relates to other personas, but that’s my general stance on it, for now.
Great post Tom! I have been thinking through this as well. It has been such a struggle with me internally because I can’t stand duplicating code, but it does complicate things and adds a layer of needed PHP knowledge from a user who wants to make modifications. I wonder it makes sense to use something like mustache templates for development that compile the WordPress Template Hierarchy files.
DRY is something we need to strive for at an application layer, but when it comes to template sand child theming, I think it saves a lot of time, pain, and headache for both users and support / developers as they help their customers extend themes.
Dunno – this may be over-engineering the problem – we have the template hierarchy for a reason :).
dealing with custom css is one bugging me in the past. when user in multisite enviroment, editing the style.css or prepaid custom.css is not an options. the solution would be adding a custom css via setting api/theme options. that why even user upgrade the theme, the custom css saved will still exist.
ps
really like to see a theme using only index.php for all template hieranchy :)
that would be neat.
Are you saying you’d really like to see a theme using only `index.php` or those are the types of themes you like to see?
Curious :).
I’ve stopped recommending child themes to people who want to edit css. Now I recommend the Jetpack plugin. It has lots of goodies – including a css editor. That’s all most people need for basic edits – and the changes get carried on for as long as the plugin is enabled.
I think this works fine as long as they understand the revision system and what the limitations are – truth is, I’ve used it on a few sites myself; however, as soon as templates need changing, then come the child themes.
I don’t think this is a valid reason. Just for CSS changes, you are asking people to use JetPack . Seriously ? Being a professional theme developer at WordPress.org, I personally recommend child themes as they are the best options. Child themes give more flexibility of changes specially when user wants to change something more in future, other than just CSS. Jetpack has limited capabilities when it comes to CSS or theme customizations.
It’s pretty easy to do if you use Sass and store all customizations in variables and generate new CSS files on the fly.
This is true – and I’ve seen it done both very well and very poorly.
In the worst cases (in fact, in a site I was auditing this week), a plugin that was doing this was the worst performing plugin installed on the system.
On the other hand, if they’re properly storing variables and compiling it on the server-server, then it really shouldn’t be that impactful.
Even still, I get a “weird” feeling when I think about editing theme styles in theme options pages (not that that’s what you’re saying), but it’d needed to be done elegantly enough such that it’s under, say, the “Appearance” menu, but also that users get it’s likely not portable between themes (hence this could be a plugin, but I’ve already talked for too long :)).
I’m just being contrary to piss you off, Tom.
Just kidding. I think there’s a bright future for Sass in WordPress now that it has been adopted in Core.
HA!
Agreed, though I’m personally stuck between Sass and LESS at the moment. One project is using another, using the other.
This is a whole other discussion for another post, though – one where you can go and try to piss me off there, ;).
Well, obviously, I won the Sass vs. LESS battle so there’s really nothing to discuss.
LOL. You’re such a troll.
All I meant was that I’m using them in projects on WordPress. Not in core.
But I would if I wanted just to irk you.
Hi Tom,
Like Jason, I too hate to have to repeat code. And while breaking down the theme files into multiple templates is the only (perhaps?) way to go right now, it does induce complexity for the “tinkerers”. Having said that, how good or bad would it be to introduce a simple templating system in WP? Like Laravel – Blade?
Also, regarding custom CSS, why can’t it be stored in DB and restored after each update?
I don’t think storing the CSS in the DB would be a good idea. That wouldn’t allow you to cache your pages very well as you would need to make a database call each time the page is loaded.
That’s not entirely true. One could set it up to cache the CSS from the database for a long time, making it trivial whether it’s stored in the database or in a file on the server. Personally, I would opt for a custom CSS file saved in the uploads folder.
You understood me wrong. We would be calling on the database only on when –
(1) User sets custom CSS – INSERT, and write to custom.css file;
(2) user edits the CSS – UPDATE DB, write to custom.css file;
(3) User updates the theme – Update the theme as usual, recreate custom.css file from DB
Any downsides to this approach? (Considering CSS or design changes are not something that is done on a daily basis)
Surely it’s horses for courses? You use the template files that are necessary to achieve your theme goal and nothing else.
A theme for a restaurant, say, is a pretty simple concept. Perhaps a few static pages and a custom post type and template for menus/menu items. Maybe, just maybe, the owner wants to have a blog in the form of a news section but even that doesn’t complicate the templates required.
I’ve always liked the idea of using as few templates as possible as long as it suits the intent of the theme. I think the tendency to throw the whole kitchen sink into every theme is a hangover from the early days of blogging when a) blogging was all WP was used for, and b) blogs were set up by the bloggers themselves and needed to be super flexible. Nowadays a large percentage of WP installs are used for non-blogging applications and users aren’t required to do their own setup/maintenance because a mature and professional developer industry exists.
Good post, Tom.
Greate article. Keep writing such kind of information on your site.
Im really impressed by your blog.
Hey there, You’ve done a great job. I will certaimly digg it and individually recommend to my friends.
I’m sure they’ll be benefited from this website.
my page :: campagne marketing sms
Nice article!
Thanks for sharing..