Cancel

Jeff Chandler

A Preview of the Custom CSS Editor Added to the Customizer in WordPress 4.7

WordPress 4.7 is a little more than a month away and is going to be packed with new features and improvements. In particular, five feature projects related to the customizer were approved for merge and will be part of the release. One of the feature projects is the custom CSS editor that enables users to make CSS changes to a theme without having to create a child theme.

CSS Editor in The WordPress 4.7 Customizer
CSS Editor in The WordPress 4.7 Customizer

In WordPress 4.7, there’s a new section in the customizer labeled Additional CSS. Clicking the label displays a blank pane with a short description of what users can do. Clicking the help icon displays a short explanation of what CSS is with a link to a help document on the Codex. The Additional CSS pane is more like a text area than an editor.

Unlike Jetpack’s Edit CSS module, the editor in the customizer lacks line numbers, colored text, and other conveniences. However, these are features that are likely to be added in future iterations.

Jetpack's Edit CSS Module
Jetpack’s Edit CSS Module

There are a couple of things to keep in mind before using Additional CSS. First, it does not have revision support enabled. Weston Ruter, WordPress core committer, says revision support is disabled by default and requires a plugin.

Second, changes are theme specific and are not global. Luke Cavanagh has inquired on whether an option will be added in the future to enable global CSS changes which could come in handy for making tweaks for active plugins.

During testing, I didn’t encounter any issues with writing or pasting CSS code into the Additional CSS area. I encourage you to download and install WordPress 4.7 beta 1 and try it out for yourself and let us know your thoughts. If you think you’ve encountered a bug while using WordPress 4.7 beta 1, please report it on the Alpha/Beta section of the support forums.

Category:
Tags: , , ,
49

49 responses to “A Preview of the Custom CSS Editor Added to the Customizer in WordPress 4.7”

  1. And _I_ thought that idiocity was “off the desk”. Ah well .. and then everyone in the Core team is wondering where this “us vs. them” divider stems from ^_^

    *smh*

    cu, w0lf.

    • +1, a feature no one asked for which teaches users to do the wrong things, and as a bonus hurts the performance.

      but if it is in jetpack it is probably a good idea, thinking for yourself is optional.

  2. I think this CSS editor is a great feature. As most of WordPress theme developers have to make one for their themes. But with this option available in WordPress by default, make the lives of theme authors easier.

  3. We need all the things to be in a very small area with annoying structure and duplicate functionality and annoyance. Maybe WP should “steal” something from Wix(squarespace etc) :).

  4. Custom CSS is clearly plugin territory, IMHO. I’m frankly against this merge. There are already a few plugins that add custom CSS without the need of a child theme. And even some that do it with a live preview, like SiteOrigin’s. If a user has enough skill for editing CSS, what stops her/him of installing a plugin? I don’t get it.

  5. The Simple CSS plugin already does this but does it much better. Style changes remain in effect even if you change themes. What I like best about Simple CSS is that you can modify the CSS for single posts or pages. Say you publish a page that doesn’t need a title because you’re using an image as the title. All you have to do is go down to the Simple CSS box and display: none the post title. It will hide the post title only on that page.

    Simple CSS is the very first plugin I install on any WordPress site I create. It will continue to be, even after a CSS editor is added into core.

    • The option in core is not global and custom css will be lost if a user does changes themes.

    • The Simple Custom CSS plugin is one that I always add to my theme tutorials as a suggested option…and will continue to do so. I also plan on the recommendation that my users bypass the customizer’s CSS.

    • I agree Rick. I use WP Clips which offers database-independent CSS, JS and PHP customizing for both themes and plugins. Really simple and safe against theme switching. Not sure what added benefit this new CSS customiser really offers?

  6. Can there be an option to disable this? The plugins in the repo already support styling everything about the website including plugins. This features needs more time. Maybe make it a plugin like other core features have become.

    • There might be, you can disable the customizer from being viewable but the code will still be in core and the hidden custom post type for the custom css will still exist.

  7. Yay for core Custom CSS. That doesn’t transfer between themes. That doesn’t do the job (it would seem) as well as a plugin (like Simple CSS, as Rick mentions).

    Great work!

  8. As a theme seller I’m happy to see this for two reasons.

    1. I’ll get less support requests about how they can add custom CSS because some users will find the core feature on their own.

    2. It’s easier for me and the customer when I can point them to a core feature rather than suggest involving a third-party.

    It’s not like users can’t still opt for a plugin if they need something more sophisticated. I was always happy with the plugin approach. This is just one less step for most users and that’s a good thing.

  9. This is not a that bad of an idea but not a very good one either. I think that maybe they should have thought it out a little more.

    Personally, I think it’s plugin territory.

    Maybe they should give theme devs the option to include it in a theme they are building. Something like:

    add_theme_support( 'custom-css' );

    Just an idea.

  10. This doesn’t seem like a great idea. I feel like this kind of defeats the purpose of the customizer since it’s supposed to allow users to make edits without using code. I’m sure this will cause headaches on client sites.

    • Actually, I agree. A friend of mine pointed this out:

      WordPress zipped download 8.4 MB (uncompressed about 21 MB)

      Joomla zipped Download 11.6 MB (uncompressed about 30 MB)

      For anyone who is not familiar with Joomla! It’s a full on CMS that can do a ton more than WP, and when you look at the size of WP, it’s closing in but does only a fraction of what Joomla does/has.

      • I don’t have much experience with Joomla! But I think Joomla! for now is not better than WordPress.

        WordPress is coming to a platform, where you can build an app, use WP as backend system. Joomla! More like a CMS.

        I prefer old-school method of custom CSS; WordPress is famous for many reasons; plugins repo is one of that. So lets plugins repo do its job.

        • It was kind of a tough call whether or not to add the comparison of file size between WP and Joomla, because these are two completely different CMS solutions, and for the most part, for different uses. But it was more for the fact that Joomla is a big CMS (I’ve got 8 yrs with it) and WP (I’ve got 5 yrs with it) is stll (IMO) a blogging platform (which it excels in)…and yes, I know that it’s being pushed to be more than a blogging platform :)

          Joomla packs a lot more features and capability, but the file size between the two are narrowing, is really the focus of why I mentioned what I said just earlier.

          However, as I originally pointed out in the comment, that it’s growing in size in the core.

  12. Why in core?! If you need it, please install a plugin. Next step is including a contact form, a cache feature, a SEO feature, etc. Why? Because many users want this.. When to stop?

  13. Seriously….this just boggles my mind and wondering where are the priorities and rational thinking with the WP core devs. Let’s start by saying this:

    – Sure it might be fine for “small” CSS changes, but what if you need more; you then have to add a plugin or use a child theme.
    – Speaking of small, that is a very small space to work in if you have a lot of CSS to do.
    – Let’s just keep adding more and more and more and more to the customizer that should have been used strictly for theme options only!

    There are so many other issues that are more important…like:

    – Put some effort into a proper CMS editor that does NOT touch my own code I add to the HTML view. Stop stripping out my stuff.
    – How about adding core ability to disable widget titles on a per widget basis?
    – How about adding core ability to disable page titles from the editor
    – How about adding RGBA capability to the customizer core
    – How about letting us create our own “Post Formats”
    – How about creating creating a way to assign templates to categories
    – How about core adding capability to assign widgets to select pages without plugins

    There’s a lot more things that can be added to the list, but I’m sure others can do that.

    The core is getting absolutely ridiculous with the customizer. I keep saying that it should have been used only for theme options and settings. Wasn’t it supposed to be that to begin with so that themes did not code in their own theme option pages? Now we continue to see more core stuff and plugins being added to the customizer. How soon before we get the whole admin added to the customizer!

    • Now we continue to see more core stuff and plugins being added to the customizer. How soon before we get the whole admin added to the customizer!

      Unfortunately, I think that’s their plan. In every release, I see an increasing amount of tickets being opened in the Trac related to the customizer.

  16. I’ve been using WordPress since 1.2 and teaching it since 2005. Trying to explain somethings to beginning users is getting incredibly complex. The customizer is almost a full day alone- as is the concept of “Child themes”- at some point, WP has to realize it’s greatest strength is that it was easy to use- and that’s why it spread.
    The forcing of JetPack and the connection to WordPress.com is horrible- and big brotherish.
    The beauty of SquareSpace and WIX is that they have stripped away the complexities of “Front End” editing- which is something WP needs far more than the customizer solution.

    • So you basically say that hunting around settings in 10 screens (with no preview of changes) is a better UX for the novice than the customizer? And if you have been that long around you must remember that around 2.0 – 2.2 there was a preview iframe as part of the edit screen, so even the concept is not very new to wordpress.

      There are many faults with it, but nothing will be better without it.

    • Front-end live editing should be the end goal. Also the Medium Editor is a full-screen takeover, with a clean UI.

      • Yep, I’m all for live editing in the customizer and seeing the changes immediately. Those that complain about the containment should also realize there is a plugin (or its easy to write one yourself), that allows for click + drag resizing, full screen editing and even hiding it from view entirely if you like.

        I’m also all for the idea of a live css editor. I’ve written a nice plugin myself that I’ve updated and used over the years but I don’t leave it around for my clients.

        It’s a development tool and therefore…

        I’m definitely NOT in favor of a custom css editor in the core. I believe this is plugin territory.

        In fact, it kind of undermines all of the work I’ve put into my own plugin but then again, this core version is nothing close to usable (for me) in the fact that it stores and loads the css from the database with inline style tags and doesn’t support per post/page css. In my opinion, the css stored in the db should only be used for revisions and during live editing/preview. The front end should load css from the file system or better yet, compressed and cached. It should also be disposable in that you can disable and even uninstall the plugin while leaving the work you completed left behind.

        What I would have preferred to see added to the cuztomizer is a new customizer control type for posts so we can stop using hacks. This would give theme/plugin authors superior firepower and freedom to use the customizer for live front end editing within the customizer in a way that everyone can finally adopt and start using it.

        There are some really great themes that let you control everything in the customizer, post/page content is missing the boat big time.

        I’m also all for the idea of all admin options being accessible in the customizer. It’s clearly more efficient to see results immediately and with the preview capability, it just might save your @$$ some day.

  17. It would be a cool feature as an option for developers, but adding it by default is not the best idea. Most of the beginner users will do rather harm than good.

  18. I am not enamoured of the customizer. And I can’t think of anything I’d rather NOT do than do CSS in a little window jammed on the side. It’s like the FB message window in a way. I’d stick with modifying the CSS in the child theme’s style.css in Coda or Sublime, thanks.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: