From a developer’s standpoint, I have mixed feelings about having a built-in editor for editing custom CSS in WordPress. On one hand…
- It’s a really easy way to make quick changes to the theme you have installed so you get the changes you want.
- Then again, it also completely bypasses and defeats the entire child theme process.
As I’ve tried to think this through, I realize each serves a different purpose I’ll try to explain in a moment, but sometimes I can’t help but wonder if it makes things for difficult for users or more difficult for other developers than necessary.
Sounds weird, I know. But hear me out.
Custom CSS in WordPress
At this point, I think you’d be hard-pressed to find someone who’s very comfortable with WordPress who isn’t familiar with the built-in editor.
This does not mean they are comfortable editing any of the files that are able to be read in said editor, but they know the menu items exists and that it can be used to alter files that make up the theme.
However, one of the files I know people are more comfortable editing is the CSS that comes with the theme. Any time spent going through public support forums will show as much.
On top of that, the Jetpack plugin also offers the ability to enter in your own custom CSS. According to the module included with the plugin:
The Custom CSS editor gives you the ability to add to or replace your theme’s CSS, all while supplying syntax coloring, auto-indentation, and immediate feedback on the validity of the CSS you’re writing.
So if a user is an administrator of a site and has Jetpack installed, then they have two ways to go about customizing the site aside from the notion of child theming.
Does this empower the user? Does it harm a potential developer? Is this a false dilemma?
For The User
If you’re an accomplished WordPress user and have knowledge of front-end development – even if it’s limited to CSS (where the word “limited” isn’t meant to be a bad thing) – then having the ability to change the front-end of your site can be empowering.
For example, maybe the
blockquote style needs to have it’s
font-weight style changed, or maybe you want to add some padding around one of the content elements.
Easy enough, right?
But do you do this by editing the theme’s core CSS file or do you do this by editing the custom CSS file provided via Jetpack?
Personally, I’m a fan of the latter as I like to treat themes as a black box. I know, I know – open source and all – but I don’t think that argument should be used as a blanket for why everyone should be able to do anything with the software we want.
That’s probably a post in and o fitself, but not today.
If you’re someone who’s savvy enough to know what CSS is, but isn’t someone who’s savvy enough to know the full scope of the ramifications of the changes, then it could negatively impact the presentation of your blog and you’re left having to ask for help.
And that’s a shame because it could’ve been avoided had, say, the option not been presented. Is that swinging too far in the other direction?
For The Developer
Generally speaking, I think child themes are more developer-oriented because they are based on the concept of inheritance which is something that’s core to object-oriented programming.
No, not everyone who works with WordPress knows object-oriented programming (or is a fan of it, even if they are), but the concept still remains. Furthermore, child themes can be used as a way to make CSS changes without actually touching the base theme.
That’s one of the, if not the, primary difference in child themes and simply editing an available CSS file.
A False Dilemma
Maybe I’m looking at it the wrong way. Maybe having two ways to modify the styles of a theme is something completely fine and I don’t understand how the majority of people use self-hosted copies of WordPress.
I do know from experience there are people who will send emails requesting help for changes they’ve made through these interfaces in the dashboard that ended up borking their installation.
I don’t blame anyone in particular, either. There’s a lot of information out there and Google returns just about anything you can imagine when it comes to changing the styles of a WordPress theme.
But here’s where it gets really touchy for me. From the Codex:
A child theme is a theme that inherits the functionality and styling of another theme, called the parent theme. Child themes are the recommended way of modifying an existing theme.
So if this is the case and if this statement is not out of date, would it be wrong to ask if:
- The ‘Editor’ option under the ‘Appearance’ menu wasn’t available? Or maybe only limited to certain files?
- Custom CSS files were only part of the Jetpack plugin or even a standalone plugin and it inherently creates the custom CSS file in a child-theme’s directory on the server?
I know there’s a lot more to think about than “just doing it” – features are hard and thinking of all use cases is tough – but I remember getting into WordPress almost 10 years ago and
custom.css was all the rage.
Then child themes became the way in which many, many people were urging the direction of development to go. And now it looks like we’ve swung back in the other direction. We’ve just provided a different interface for it.
It’s All Food For Thought
Ultimately, all of the above is food for thought. I don’t have a specific answer nor do I know exactly what goes on in the decisions behind the features.
Maybe we should just work on introducing a large warning giving users a heads up making changes to core files – from within WordPress, nonetheless – is a dangerous thing to do and may result in irreparable fixes without an experienced developer.
And sure, these discussions are usually available on Trac, patches are welcome, and all of that that’s great – seriously! – but what I mean is I give the benefit of the doubt to those features as to why they are the way they are and provided as such.
As someone who has had to work with others who have ended up borking their theme or their installation by editing core files, I can’t help but wonder if we’re making things easier or harder.