One of the things that I think many, many young (that is: inexperienced) theme developers do is ship a
custom.css file in WordPress. Years ago, I made the mistake so I’m just as guilty as the next person.
Unfortunately, this is something that’s still happening today – we need to stop including custom CSS in WordPress and use the native facilities to take advantage of the same functionality we’re trying to achieve with this particular file.
Here’s the thing: Normally I wouldn’t bother talking about something like this because the Codex does such a good job of outlining the proper way to introduce customizations into themes, but I recently received a comment (that I’ll paraphrase) in which I was told that:
In the real world not everyone uses child themes.
Odds are, many of us have heard the old cliché that:
The difference between theory and practice is that in theory there is no difference.
And when you’re talking about something like a complex algorithm for traversing, say, the shortest path across a graph over a large network, or when we’re talking about something like properly handling memory in embedded systems, talking about theory and the real world makes sense.
That is, all of those cases are important and are worthy of optimization, but we’re talking about a single CSS file.
We’re not talking about a complex system.
And it concerns me that those who are contributing to the WordPress economy through products aren’t taking the built-in features of the application seriously. It’s seen as some bit of impracticality that they don’t want to pursue.
But this introduces it’s own set of challenges that negatively affect theme development from both a developer and a customer standpoint.
The Problems With Custom CSS in WordPress
Anyone who has dealt with a custom stylesheet in a WordPress theme before either as a developer or as a customer knows the frustration that it causes.
First, upgrades can break the changes. If, for example, the developers ship an empty
custom.css file and don’t change the name of the theme’s directory to include, say, the most recent version number (think
mayer-1-1-0), then it will overwrite the existing theme files including the
custom.css file that was part of the original theme.
Next, let’s say that the developers include a routine to check for the existence of a
custom.css file and only write it out if the file doesn’t exist. Again, sounds good in theory, but what if the markup has changed in any of the template files.
Will the changes in
custom.css still work? It’s hard to tell until you install the new theme and then load every single template that exists on the site. If something is borked, does the custom have the ability to change the styles on their own or are they going to need to contact support?
This raises the question as to if customizations should even be a major support issue. I think it warrants its own discussion, for sure, but this isn’t the post for that.
Anyway, let’s say that the developers do ship a version of the theme that includes a different directory names (again, think
mayer-1-1-0), then the
custom.css file is completely ignored when the theme update is activated because it’s essentially a different theme.
Thus, the problem still persists.
Now, to give a quick run down, I know that some of the points I’ve mentioned above aren’t handled well by child themes, either.
- Creating a new directory for an updated theme version still requires that that the child theme properly reference the new theme.
- If the markup changes in the new theme, then the customized child theme still needs to be updated in order to handle the newly changed markup.
This, of course, hits on the importance of user-friendly changelogs which, again, is the topic for another post.
Even still, despite these two points, we need to stop including custom CSS in WordPress and start pushing more towards the child theme implementation of customizations not only because it ultimately does ease the pain of upgrades, but it helps to further treat the theme more as a black box than something that can be hacked to pieces to fit the customer’s needs.
Wait, What? a Black Box in Open Source?
A Word About Our Freedoms
First, don’t get me wrong, I understand that one of the biggest benefits of of open source is the ability to learn from other people’s code. The WordPress Bill of Rights even grants (which is based on the GPL):
The freedom to study how the program works, and change it to make it do what you wish.
However, that doesn’t necessarily mean that the version of the code that we distribute has to include all of the raw development files.
- Include all of the files separately, enqueue the files one-by-one negatively impacting the load time of the theme at the expense of keeping all of the code easily readable,
- Or minify, compress, and/or combine all of the files in order to help decrease the size of the theme, increase the load time and performance of the theme, but make it more difficult for others to study.
There is a third option, though: Leave the code completely open source on one of the popular repository sites from which others may learn, but distribute only the version of the code that’s smallest in file size, highest in performance.
Meanwhile, Back at the Main Point
Okay, so I still haven’t answered the whole idea of a “black box in open source” thing. The short of it is this:
I believe that the majority of people who are buying WordPress themes are those who want to have a great experience in setting up their site or their blog, and have access to high-quality support.
I don’t believe that they want to be able to access to code, read it, change it, and so on. Sure, that’s a luxury that comes with open source software, but it’s not the primary motivation for someone purchasing a theme.
They’re looking for a product to help them solve a problem or to help them with their online brand, for lack of a better term.
And yes, customization is something that’s possible with WordPress, and yes, despite how I might sound in this article, I’m all for people making adjustments to products that they purchase. It’s built into the foundation on which the products are built, so why would I be against it?
Simply put, I’m against hacking the core theme in order to make the changes because more often than not, something is going to change or break and then they’ll have to ask for support and now they’re asking for support on a product that was not shipped to them.
All About Maximum Customization
This isn’t some theoretical idea as to how themes work, either. I’m speaking from experience.
We’ve already covered most of the challenges that come when a user updates their theme, and this is no different of a situation.
After all of that’s said, child themes certainly can help to mitigate the problems that come with this, and though they aren’t without a few of their own challenges, they help keep the changes abstracted away from the core product which can make it much easier to port the changes to an update, to track changes via support, and to continue introducing your own changes.
Ultimately, I’m completely for giving users the ability to introduce customizations into their theme, but I want them to have as pleasant as experience doing it as they can have with using the theme itself.
This means that customizations to templates, styles, and so on need to be kept out of the core theme. Leverage features that are already offered by WordPress, make sure that themes are child-theme compatible, perhaps often with some instructions – or education – on how users can get started with creating child-themes, and make the changes there.
Though WordPress itself is open source, it’s never a good idea to try to touch core files in order to achieve our customizations. We do so via plugins. The same goes for themes: Don’t make the changes by touching core files, do so via child themes.
It’s easier, it’s safer, it’s something that is done in the real world, and it’s something that can help foster the development of even greater core products.