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.
But when you’re responsible for introducing changes into someone’s existing theme, it allows you to treat the base theme as a black box and extend it with more than just custom styles – it includes templates, additional JavaScript – and so on.
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.
I use the following criteria. If only css changes need to be made, then custom css is the way to go. If anything else needs to be changed especially in the way of custom functions – or adding widget areas etc.. Then child themes are the way to go. I think that child themeing just for css only changes will start to go away in favor of custom css either through jetpack or other plugins.
The filter through which you make your decisions is spot on. Really dig that, Grant.
I am not developer and of course I always use CSS Editor.
Have you ever had problems when upgrading the theme and losing the customizations or having to tweak the customizations for the new version of the theme?
If its only a few lines of CSS I provide my users with a Custom CSS & JS panel within the admin options, however if its anymore than 10-20 lines I direct them to my Child Theme Generator all done within the admin makes it as simple as ever. I also provide them with extensive documentation on child themes and advanced functions, etc…
I agree that parent themes should be treated as a “black box”, not using a child theme you’re just asking for issues down the road like parent theme updates or feature additions.
This seems like a fair balance, though you’re a braver than I am :).
As far as I’m concerned, I just don’t let customizations happen outside of a child theme. I’ve been burned too many times to let it keep happening, but if you’ve got the ability to support it and it’s working, then go for it :).
As a theme provider, this is a tricky issue that we run into fairly often. The solution ultimately depends entirely on the user. Asking someone who is new to WP to download, modify, install and activate a child theme for a few lines of CSS just isn’t realistic. The process involved with child themes isn’t something the average person can or should be dealing with, as it’s not intuitive in the least bit and takes away from their time publishing content.
As an alternative, we do provide a custom CSS box in the customizer for users who are adding a few lines of CSS. We are very clear in the documentation and in our interactions with users that this custom CSS box is specifically for small changes, and anything more than a few lines should be done with a child theme. This is a pretty good balance, and we haven’t seen anyone abuse the custom CSS box.
We always recommend child theming as a precursor to any advice we give regarding CSS or theme changes, but ultimately leave it up to the user to decide what is best for them. These folks are choosing WordPress (and our themes) because of their ease of use and I think it’s important that we respect that in how we help them and the tools we suggest.
Glad to have you chime in, Mike.
When I was doing themes-as-products (rather than themes-as-a-service), it eventually got to a point where we said child-themes or nothing. We’d provide a child-theme kit in order to help them get started because too many users were making it hard on the rest of them.
I fully agree with this so long as the main qualifier is takes away from their time publishing content. After all, for many, that’s their goal, right?
But when people want to convert the theme into this vastly different looking thing, it makes me wonder why they purchased it in the first place.
I’ve noticed and I dig it.
+1
As a developer, if I’m only making CSS changes, I typically use the Simple Custom CSS plugin because I don’t want to install all of JetPack just for a module or two (https://wordpress.org/plugins/simple-custom-css/). It’s quicker and easier than installing a child theme. However, if I’m modifying actual theme functionality and not just CSS, I use a child theme. I try to stay away from ever using the built in editor to modify the original theme files because those modifications will be lost if the theme is upgraded.
This seems like a good process to follow. The biggest concern I have with using a custom CSS file is that customizations can break when the theme updates.
It’s true that the same can happen with child themes, but many times people will include a
custom.cssfile in their theme and then it’s overwritten or deleted when a theme is upgraded. That won’t happen with a child theme (or a plugin that does it correctly, as you mention).I was referring to the Simple Custom CSS plugin (https://wordpress.org/plugins/simple-custom-css/) not a
custom.cssfile. That way people can add small CSS tweaks via the WordPress dashboard without modifying the theme itself and without having to install all of JetPack.Ah, gotcha!
Custom and theme (parent or child) CSS aren’t really alternatives to each other for the average user.
The purpose of custom is to allow non-destructive, easily-reversed tweaks to be made to a style the user is mostly happy with. If they’re not happy with that, get a new theme, or at least have the current theme extended into a child by a developer and then continue to use custom.css to tweak it.
Unless a developer is looking for easy money fixing the mistakes of regular users it’s almost professionally negligent to leave the theme editing capabilities enabled.
I think custom.css is fine if used minimally. Hell, as a developer I sometimes use such features to quickly add a rule that is a little tricky to persist in developer tools. I’ve also seen the opposite situation where custom style panels have hundreds of lines of rules that should be in a child style sheet.
You’re right; however, if an average user goes to Google for how to make changes, they’re likely going to stumble across both of these as solutions.
Agree. This is a constant that should be set in
wp-config.phpby release, though I actually don’t know how this impacts Jetpack’s editor.I’ll typically make the decision at the outset of whether the theme is going to need to be customized heavily or not and who is going to be managing it. It’s far easier to make a child theme from the outset than having to go back and do it if I need to add or edit files besides Css , or there are going to be inheritance issues. If I know a client wants to make simple style changes Ned that’s it, then the vast editor in et pack is perfect, and not too bad of an editor, considering.
Agreed.
Personally, I’m more of a fan of child themes but I think that’s given the nature of what I do for a living and because I’ve dealt with the challenges of
custom.cssI tend to want to avoid it.Yeah – I think they’ve done a good job with it and if the user knows what they are doing, then go for it.
It’s the theme upgrades that can always get you, though.
It’s nice to have a way to do minor tweaks to a theme — as the OP suggested, making the blockquote bolder. And in a case like that, maybe setting up (and later removing) a child theme seems a little over-complicated. Especially if you’re testing multiple themes to see which best suits your existing content (an exercise I’m engaged with right now).
When a theme has a built-in custom CSS component, that makes it easy. But when it doesn’t then having a custom CSS plugin to do it helps — until you swap themes again. Then the results get a little unpredictable — the blockquote change you made in Theme A could be a disaster in Theme B. And we’re all going to change themes eventually.
In that case, it would be helpful if a theme had an identifier. If “My Best Theme” had in the tag the class , your style rules could be along the lines of
.my-best-theme blockquote { font-weight: bold }
.my-second-best-theme blockquote { font-size: 2em }
Technically, this is something that I think all themes should be doing with the body_class hook, but given the nature of theming, it really depends on how experienced the author is.
Sorry, should have coded my comment differently.
In that case, it would be helpful if a theme had an identifier. If “My Best Theme” had in the <body> tag the class <body class=”my-best-theme”>, your style rules could be along the lines of
Not sure if WordPress ate your code after “..could be along the lines of” so I’m just leaving this here as a heads up.
The whole nature of CSS – the cascade – is outdated.
Cascades were created to make CSS more efficient.
But saving a few bits of CSS makes no difference these days.
Sites should be able to have custom styles per post.
Cascading styles should be the exception not the norm.
As a developer, I would always create a child theme (even in situations where you don’t need it immediately) because menus / widgets tend to “break” when you reach the point where you do need a child theme.
As for the custom CSS issue raised here, if you don’t use a child theme you can’t easily version control things – guess that how important version control is depends on whether you’re working in a team or on your own and your workflow. Personally, even working on my own I version control everything.
Plugins / theme options that allow for custom code to be added, tend, in my experience to lead to issues down the line. For users who know enough to make changes, but not enough to do things “properly” (subjective, I appreciate) the answer here is training.
This is the direction in which I lean.
Yep. There are plenty of things I have that I throw into version control even if it’ll never see the light of day if, for no other reason, to keep a history of what I’ve done as well as having the ability to rollback to something if I’ve borked it (or a dependency has borked it).
Same is true in my experience, as well.