The Days of Creating Child Themes for Simple CSS Changes May Soon Be Over

The general advice given to users who want to make simple edits to a theme without losing them is to create a child theme. This involves creating a directory, CSS file, a functions.php file, and uploading them to the webserver via WordPress or FTP.

Users must also make sure the child theme references the parent theme correctly in order to establish the proper inheritance. This can be a complicated process for a lot of people but thanks to a new feature proposal for WordPress 4.7, the days of going through this process may soon be over.

The Benefits of Adding a CSS Editor to the Customizer

The proposal suggests adding a CSS editor to the customizer which offers a number of benefits. Users can live preview changes before they’re applied and see how they’ll appear on mobile devices. Instead of editing files directly, changes are stored in a Custom Post Type for each theme and override theme styles.

Related projects such as customize changesets (#30937) and revisions for customizer settings (#31089) will allow for future enhancements. Adding the editor will also lay the groundwork for possibly removing the Theme file editor from core at some point in the future.

Here’s an example of what the CSS editor looks like in action. Note the line numbers that can help with troubleshooting purposes.

custom-css-proposal-demo-1.gifThe editor also displays error messages for common syntax errors. For example, a missing bracket. Adding the editor is only the beginning with revisions, syntax highlighting, and in-preview selector helpers, planned for future iterations.

Special Meeting Planned to Discuss Storage Issues

In today’s WordPress developer chat, attendees discussed the pros and cons of the editor and whether or not it’s ready to be merged into WordPress 4.7. A point of contention preventing a final decision is how data is stored.

Members of the Core and Customizer Component teams will discuss this particular issue in detail in a special meeting before making a final decision to merge it.

Testing and Feedback Needed

To test this feature, you’ll need to apply the patch via Trac or the Pull Request from GitHub as it won’t land in WordPress Trunk unless the proposal is approved. The team encourages you to add custom CSS in the customizer using a variety of themes and to share your experience and feedback in the comments.

A Use Perfectly Suited for the Customizer

While I have yet to test this feature myself, it seems like the perfect use case for the customizer. While some developers have expressed concerns with the proposed implementation, others are excited to see it land in core.

Removing the need to create a child theme for small or simple changes is a huge win for users. It’s also a major win for those who provide support. Instead of giving a customer complicated directions, it can be as simple as telling them to open the customizer, click on additional CSS, paste the snippet of code, and click the save button.

46 Comments


    1. What’s proposed would allow users to not need to use most of the CSS Editor plugins out there and would provide a standard way of applying minor style changes.

      Report


    2. The author of that plugin is leading development of the feature for core, actually.

      Report


    3. Having just worked on a site that had 5 Custom CSS plugins installed… 3 of which were actively in use… centralizing this all into a single core feature makes a lot of sense to me.

      For those wondering, 5: 1 built into the theme, 1 from VIsual Composer extension, 1 from JetPack (module enabled), 2 other stand alone custom CSS plugins installed by who knows.

      Personally, I could care less about the customizer front end previewing aspect. I get some people do, but I think the win is from separating CSS editing from PHP editing (the later I’d just as happily see permanently removed) and of building this in as a core feature to get away from the fractured custom CSS experience I mentioned above.

      I think it of a bit like the custom menus getting built in after a bunch of conflicting custom menu plugins became popular.

      Report


    4. I used that plugin previously, but noticed that it was adding significant load time to my sites, so removed it. That doesn’t mean several seconds, but enough to say “Do I really need this?”

      I really liked the plugin, but felt it better to implement using files and child themes.

      Report


  1. So, when the theme is being switched, all goes to hell? Perfect idea.
    And people keep wondering about where the “us vs. them” comes from. Guess who’s gonna have the “fun” in explaining it all to the users? Definitely not the Core developers ^_^

    cu, w0lf.

    Report


    1. The problem you just described can be easily solved by simply connecting the CSS changes with the current theme. When it’s changed, the CSS changes would disappear.

      Report


      1. The theme switch resetting all settings made with the customizer I quit fumbling around with the customizer. Explaining THAT to the average end user turned out to be a total support nightmare.

        So when its switched, this actually means your CSS changes won’t resurface if you switch back. Sounds like fun. … not.

        Aside of that, I agree with Steven – there is already a nice plugin (or two ..) for this :)

        cu, w0lf.

        Report


      2. But why would you want your CSS changes to work between themes? You’d have the same issue when using child themes – you lose your CSS changes when switching to another theme.

        Report


      3. @matthew, because you want the banner shortcode you use for your “call to action” to be styled with a yellow background instead of white. Many HTML entities are not added by the themes.

        Not sure that it is different in practice from what happens with child themes though.

        Report


      4. Why? because people customize lots of little things that transcend theme changes, like shortcode call to action buttons, etc…

        BTW, the proposal ties the CSS to a theme, so each theme gets it’s own post object to hold it’s CSS data, but that makes it recoverable/copyable between themes.

        Report


      1. Thanks. That looks quite promising. Always wondered why they never went with that right from the start.

        Yes, I do see the logic in the current behaviour from a programmer’s perspective, but from the UI / UX perspective it always seemed utter crap ..

        An afterthought: Or maybe it really WAS how I always feared all of this came to life: Just some Frontend Developer geeks fiddling and chopping away, not thinking about the rest .. o.O

        cu, w0lf.

        Report


  2. This sounds like plugin territory to me.

    I foresee this being just another thing I need to deactivate in core :/

    Report


    1. Perhaps, but I believe it will be beneficial for a large subset of users and it’s only the first stage of what could become a great alternative to the Theme file editor which many believe is plugin territory.

      Report


      1. IMHO, adding the theme file editor was a horrendous decision. This CSS feature would definitely be less bad, since it is not an obvious point for targeting for hacking.

        Report


      2. I think a large subset of users should be using a plugin. If you’re “advanced enough” to write custom CSS, you’re most likely “advanced enough” to know that you need a plugin. Adding features like this one is just bloating the core.

        Report


  3. Child Themes is much more than only one extra style.css and one extra functions.php. I use them to make and fix css changes and some php functions (i don’t like to use plugins for some reasons) that, like fwolf said, when update the main theme, those changues don’t get lost in the way.

    The Custom CSS on the customizer is a great idea, don’t get me wrong. But for lot of users and WP devs, child themes is mandatory on some cases.

    Report


    1. You’re right, if you need to alter templates and other php files using PHP, this editor won’t help you. But if you want to make a few changes like hiding post meta or adjusting the margin of an item in a theme, then this is perfect.

      Report


      1. ….and then what happens if later they need to do more? It just makes things messy when the user has to then switch to a child theme, or a plugin.

        Report


      2. Messy maybe, but not hard. This suggestion is just for simple CSS changes to a theme. Anything more: just make a child theme. Most front-end developers can bang out a WP child theme in our sleep.

        Report


      3. @Jeff I hope you are not seriously hiding post meta by adding display: none; to your CSS?

        Making changes like that is the whole point of the existence of child themes: adjusting functionality of the parent theme.

        And whilst the child theme is there, you might as well use it to adjust the styling, so no need to add this to the Customizer or do it with Jetpack or another plugin.

        Report


      4. As I’m a bit of a ‘newbie’, what is wrong with adding display: none; to your CSS?

        Report


  4. Although I applaud for “trying” to create user friendly functions and features for the end-user, do we seriously need to keep cramming in more into the customizer? I swear they are trying to move the whole admin into the customizer. I’m already getting theme customers confused on the customizer as more and more elements are stuffed in which gets mixed in with my own theme settings.

    I still say that the customizer should have been only for theme settings and options; leave out the admin stuff.

    When it comes to customizing a theme, I let my users know of three options:

    1. Simple Custom CSS for just CSS changes
    2. If they use Jetpack, then they can use its own Custom CSS feature
    3. Child theme

    Based on the demo of the custom css in the post above, working with CSS, especially if you have to use media queries to override, is a very very tight space to work in.

    Report


  5. I think a raw dev mode is valid in a controlled env. Rollback/Undo is imperative. With these types of layers, you have to consider the Users time more than anything. Lastly, teaching CSS is a non-option.

    Report


  6. Just not seeing the need here. Is joe public clamoring for a css editor be added to the core? Devs and DIYs aren’t.

    Report


    1. If it’s added to core, it’ll make life a lot easier for theme authors who have to deal with providing css tweaks in support tickets. It’ll also make it easier for users.

      The Simple Custom CSS plugin is active on over 300,000 sites. Other custom css plugins are used on a large number of sites.

      Report


      1. There are around 75 million WordPress sites out there. Adding “custom css” to the core because of 0.4% websites doesn’t sound appealing to me. People who need only small custom CSS tweaks can install a plugin, advanced users use child themes. Why bloat the core ?

        Report


      2. 50% of the sites you mention are hosted on WordPress.com, which has a paid option for custom css.

        JetPack, which is active on over 1 million sites, has a custom css option.

        A lot of themes also contain an option for adding custom css. These range from the “mega” themes on Themeforest to more simple themes like those by ArrayThemes.

        The reason for ‘bloating’ core is to make things easier for users; core committers and the lead developer for this release have outlined why they want it added on trac, Slack, and this blog post.

        Report


      3. The fact that Jetpack has 1m installs doesn’t mean that 1m people installed Jetpack due to custom CSS. Same goes for W.com – 50% of the sites, doesn’t mean that they all are paying for Custom CSS.

        And yes – themes provide custom CSS options ( I do too ), and plugins do that as well. Which is why I don’t think that this is a direction the core should be moving. WordPress is a flexible, extendable platform. The purpose of a plugin is to add functionality that some users might require. That sounds like a perfect fit for Custom CSS.

        Using analytics like “1m people want X and Y” to add features to Core can quickly go down a rabbit hole. Have a look at popular plugins – tons of things to add to core – Google Analytics, Regenerate Thumbnails, etc.

        When you’re saying “easier for users” you mean “easier for advanced users”. For people who don’t know what CSS is – this is just another item in the menu they don’t understand.

        Report


      4. When you’re saying “easier for users” you mean “easier for advanced users”.

        I mean the exact opposite. This will make it easier for novice users who might be provided with a css snippet to tweak something, like hiding part of the entry meta. It’ll makes it easier for volunteers in the WP.org forums to help users with css tweaks too.

        An advanced user who wants to add more css can use a child theme if they want to.

        The reason for mentioning WP.com, JetPack, and themes with a custom css option, is because you appear to suggest that there’s only a demand from 0.4% of all WordPress sites. That isn’t accurate. It’s difficult to gauge how many sites would use a feature like this.

        One of original purposes of the customizer was to allow users to preview real-time changes to the appearance of their site. Adding the ability to do that for css tweaks seems like it could potentially help a lot of people.

        Report


      5. you appear to suggest that there’s only a demand from 0.4% of all WordPress sites. That isn’t accurate. It’s difficult to gauge how many sites would use a feature like this.

        It’s certainly nowhere close to the majority.

        From the Philosophy page:

        Design for the Majority

        Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.

        Report


  7. Great work. Should make things a lot easier for end-users. Very excited for this first step and can’t wait to see what the future holds.

    Report


  8. I never understood why people who have more than minimal CSS skills use a text box in a themes settings to add CSS. You lose having a local copy but more importantly you use the convenience of editing in your IDE or even in a simple text editor with some formatting. CSS text boxes are for people who have problem connecting with ftp and usually those people barely know CSS so sure, some basic users with a basic site might benefit from it but in no way should a discussion of this becoming a standard make headlines.

    Report


  9. When I work with the CSS editor in WordPress.com I end up copying and pasting the code back and forth. This because the browser search function doesn’t work for me in the field A.F.A.I.K. (It did with an earlier version I.I.R.C.)

    Also having such a small field to scroll is really a pain. It is slower than a dedicated program or text processing program.

    It is nice to be able to just add CSS changes, when on wordpress.com because it adds quite a lot of functionality en customizing to the appearance of a website.

    The put it in Jetpack as plugin option sounds like it could be the better road. This because I do believe core should remain as lean as possible (and this arguably is not user functionality but developer functionality). This is all stuf that will have to be maintained and updated, possibly by a volunteer crew. Which knowing open source will not get any/ little development if not enough people are interested. This could lead to product quality degradation, which could lead to less user, inciting a road to the bottom.

    The argument that makes it easier for a user with no experience? I’d rather see a service that people can hire for an affordable price to do small changes. This would also put food on the table of developers. Explaining something like this can take quite a bit of time, and most often the questions I have seen in the forums, the people knew how to make the changes. Some webhosts have easy file manager access, so that’s copy and paste, with search functionality.

    Report


  10. I see people citing “bloat” as a reason to exclude a CSS editor from the customizer. But what’s the actual impact of including it in core?

    My gut reaction is that a simple CSS editor makes WordPress even more useful out of the box, and the performance impact would be negligible.

    Report


  11. I’ve used the “Custom CSS” option in Jetpack, as well as two standalone CSS plugins: Simple Custom CSS and SiteOrigin CSS. The SiteOrigin plugin is, by far, the best.

    But in most cases, I back up my CSS manually to a text file that I save offline. That makes sense no matter what online CSS option you use,. It negates any issues you’ll have if you switch themes. If the CSS changes don’t port over to the new theme, then just copy in the ones you want from your saved file.

    To the first-time WordPress user, this addition to the Customizer will make a lot of sense. CSS edits belong in the same place you’re customizing other parts of your theme – and that’s where I’d look for them if I weren’t familiar with the WP dashboard. And they should have live previews.

    Meanwhile, you can back up all your Customizer settings via a great free plugin made by the friendly folks at Beaver Builder. It’s called “Customizer Import / Export” and it adds a backup option to the Customizer itself. It’s easy for both experienced and novice users to understand and implement.

    Report


  12. That’s not a good idea. These fields are badly stored into db, and you can easily lose them during website migrations. I thinks child should be used as first, and for so stupid-css changes you can use a plugin.

    Report


  13. Putting the feature into the Customizer makes sense, but I’m fairly sure that most of those who would use that feature were not creating child themes. People who create child themes don’t use the Customizer by choice, but I’d never bother with a child theme for a few minor CSS changes. That’s what Simple Custom CSS or the Custom CSS module in Jetpack are for.

    I don’t have user data (and would like to see some, because I always want to see real user data), but I’d bet that the people most likely to take advantage of CSS in the Customizer were far more likely to be using Jetpack’s Custom CSS module, or some kind of plugin to let them adjust CSS without code, than to create a child theme, even a very simple one.

    All of which is to say, the feature idea is interesting, but I don’t think the headline reflects reality.

    Report


  14. Is anyone going to mention that the Customizer frequently doesn’t display correctly? Now we have good options – plugins or child themes. We’ll lose those in favor of a solution that will confuse people and not work as well.

    I use the plugins on most sites and have bits of CSS that are not theme-specific. Other tweaks will be theme related. I can comment those out when I want to change themes but am not ready to lose those theme-specific changes just yet.

    I understand WP.com wants to compete with Squarespace and the like . . . but so much more important work could be happening for small business website builders.

    Report


  15. From https://wordpress.org/about/philosophy/:

    Many end users of WordPress are non-technically minded.

    The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

    Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste.

    It might only be a “rule of thumb”, but I don’t see how a CSS Editor is something that a majority of people would care to use. Where’s the evidence to support this?

    Report


  16. It’s definitively not something most user will want. Yes, they want to style buttons, headings and other parts of their sites, but they really don’t want to use CSS-code to do it. If they’re advanced enough to install a plugin, they should (like the ones mentioned or even Child Theme Configurator
    It would be enough and much better to have the possibility to add a class to an element and maybe have a customizer control to define color, background-color and the like for the class.

    Report


  17. If this does become a standard then at least the biggest issue with it should be resolved. Revisions :)

    Report

Comments are closed.