Make WordPress Core

Tagged: themes Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 5:36 pm on October 11, 2016 Permalink |
    Tags: , , , , themes   

    Feature Proposal: Better theme customizations via custom CSS with live previews 

    When people ask “why WordPress?”, some of the most common answers center around flexibility for users of all kinds, whether they’re building their sites primarily through code or UI. Let’s take the story of a user who does a little of both – we’ll call her Becky.

    Becky is a pretty savvy user. She knows that you’re supposed to make child themes instead of hacking on a theme directly, because updates can wipe out your changes. She found that out the hard way when she first started using WordPress – she hardly knew what CSS or PHP were, but she knew there was a theme editor in the admin and that she could make tweaks to colors or remove the author byline pretty easily without having to figure out this FTP stuff. Later on, most colors could be changed with the customizer so having a child theme just to remove an author byline seemed like overkill, but it was certainly better than having it reappear every time her site updated, especially with auto updates turned on.

    After a couple years with the same theme on her personal site, Becky felt it was time to change things up. She was pleasantly surprised to find some new features that made getting a theme set up a lot easier, especially when live previewing them. Still, though, that pesky author byline remained, and since her last child theme copied a template to get rid of the byline, she would have to set up a whole new one to do it again. Then Becky found an “Edit CSS” option and realized she could hide things using CSS without having to go through the entire child theme process. Now, it turns out that those CSS tweaks didn’t come with live previewing, and that functionality was provided by a certain plugin, but Becky got what she needed to get done a lot faster than she would have otherwise, and ended up with the site she wanted.

    This isn’t one specific story, but it is a combination of user stories many have heard, witnessed, or even personally experienced. You could replace Becky with @helen and it would be 100% accurate. The theme editor is a dangerous but useful entry point to more deeply customizing your site – rather than outright removing it and cutting off that introduction not just to WordPress code but to the concept of web development at large, why not provide a far safer and more user-friendly alternative? This post will explain why custom CSS with live previewing is valuable for WordPress and propose an implementation for inclusion in 4.7.

    Proposed solution: Custom CSS with live preview

    When bridging the gap between advanced user and beginning developer, desired changes are typically visual tweaks, such as changing a font size or hiding something, that are theme-specific. These sorts of changes should not require that users take risks editing live files that might white screen their sites or jump immediately into developer-facing tasks such as using FTP. Therefore, the scope of this feature has been defined as a custom CSS editor that leverages the customizer for a user-friendly live preview experience. This live preview allows for users to try various tweaks to a theme before saving and setting their changes live.

    There are hundreds of thousands (if not millions) of users making use of custom CSS plugins or other themes/plugins that have custom CSS capabilities, and the frequent suggestion of CSS fixes in support forums justify a core need for this functionality. When plugins and themes interact in unexpected ways, CSS snippets are often an efficient solution to fixing the particular problem on particular sites.

    The CSS editor takes inspiration from the many plugins offering similar solutions, but with an updated approach that offers instant live previewing in the customizer. The proposal for 4.7 looks like this:


    Notably, previewing CSS in the customizer allows the site to be navigated and previewed on different sized devices by leveraging existing core features, allowing users to visualize the impact of their changes across their site. Error messages are shown for common syntax mistakes to help users ensure that their CSS is formatted properly before saving.

    In future releases, the interface can be iterated on to further improve usability. The long-term design vision provides functionality such as revisions, syntax highlighting, and in-preview selector helpers, and can be implemented iteratively over time (click through for the full version):


    CSS would be stored in a custom post type (without admin UI), with a post stored for each theme. The editor would be used to supplement and override theme styles rather than editing them directly, as users have long been advised that directly editing files may lead to lost changes during updates. Instead, custom CSS safely stays available through updating and switching themes, starting fresh for each new theme. Projects such as customize changesets (#30937) and revisions for customizer settings (#31089) would bring future enhancements to this feature and further leverage the opportunities that come with storing the data in post objects.

    This is proposed as core functionality rather than remaining as plugin territory because it is designed as the first step toward a next generation of the existing theme editor in core, with a more refined feature set and safer, more user-oriented focus. The theme editor is not proposed to be removed at this time, though with the introduction of this feature it likely makes sense to introduce more friction before accessing the editor (#31779).


    To improve the user experience further, it is critical that a link to documentation and resources for learning CSS be included with useful help text. This could initially be the “CSS” codex page but would ideally live on a user or developer handbook of some sort eventually (perhaps the theme developer handbook?). This help text must be much more succinct than the help tab on the existing theme editor, conveying what CSS is, where to learn about specific rules, and explaining that it’s specific to each theme in only a few lines.

    Help is needed to create a resource for using custom CSS in WordPress, and locate it on WordPress.org. There are some related resources on make/training and WordPress.com has a good introductory page that they may be willing to contribute. Translated versions will eventually be needed as well. If anyone is interested in improving this aspect of the feature, which will presumably live on WordPress.org, please comment on this post.

    Security, Capabilities, and Multisite

    While the proposal includes basic validation, it is not possible to fully sanitize CSS. For this reason, a new meta capability will be introduced for managing css, unfiltered_css. By default, this is mapped to the unfiltered_html capability.

    Site administrators on multisite networks do not have the unfiltered_html capability by default. A plugin that remaps unfiltered_css to a different capability can be created to provide this access on multisite, where custom CSS is especially useful given the need to restrict the number of themes and child themes in the network. This is an area of potential evolution over time.

    Related Customize API Improvements

    There are a couple of customizer API improvements introduced as part of the implementation of custom CSS in the customizer. A new “Code Editor” customizer control (WP_Customize_Code_Editor_Control) is used for the CSS editor and can also be utilized in plugins and elsewhere in the future. It currently handles line numbers and basic code styling, and will eventually add enhancements such as syntax highlighting.

    Additionally, the WP_Customize_Section class has a new “description_hidden” parameter, which locates the section description in the section header behind the help icon toggle (“?”), functioning in the same manner as the customizer panel descriptions.


    @johnregan3 is leading development of this project, based on initial work by myself (@celloexpressions). @folletto is leading design efforts, with a focus on the long-term growth of the feature for maximum usability.

    The implementation takes inspiration from many of the numerous plugins and services that implement custom CSS, specifically including:

    • Simple Custom CSS (@johnregan3)
    • Modular Custom CSS (@celloexpressions)
    • WordPress.com Custom CSS in the design upgrade (Automattic)
    • Jetpack (Automattic)

    Testing, Feedback, and Next Steps

    Your help is needed in giving feedback on this proposal and testing the feature! To test, please apply the patch either via Trac or the PR (helpful reminder: grunt patch handles both) and try some custom CSS in the customizer using various themes.

    Pending approval of this proposal, the next steps will be to finalize and commit the patch on #35395. Code review is ongoing in the GitHub PR linked on the ticket. Feedback on the feature in general and the specific implementation is encouraged via the comments on this post, with any more technical implementation discussion happening on the Trac ticket or GitHub PR.

    • FolioVision 5:46 pm on October 11, 2016 Permalink | Log in to Reply

      I appreciate all the thought you’ve put into this Nick. A simpler way to customise a child theme is a bold and welcome proposal.

      Still I’d rather see a tool for CSS customisation (a browser extension or an app) than add all this code to core WordPress. This much javascript and CSS in a single webpage is a house of cards and equally fragile.

      A simple way to save in custom CSS after using an external tool would be useful.

      PS. It pains me every day to see complex caching solutions and top heavy security plugins. Core issues (caching and security) would be a better place to start with heavy duty new features than adding more fragility and complexity to a an already fragile and complex system.

      • Helen Hou-Sandi 7:07 pm on October 11, 2016 Permalink | Log in to Reply

        Volunteer effort is not symmetrical – people work on things they have expertise in and passion for. “X is suffering because you are working on Y” is a fallacy.

      • Nick Halsey 11:30 pm on October 11, 2016 Permalink | Log in to Reply

        This feature doesn’t introduce a significant amount of code and in fact, most of the core code is PHP, not JS or CSS. Because it uses the customizer API, which is a framework for live-previewing changes to sites, the implementation of the particular feature is not complex. The proposed solution will work well in a workflow where you write CSS elsewhere and paste it in as well.

    • Jon Brown 6:33 pm on October 11, 2016 Permalink | Log in to Reply

      The general outline of this proposal sounds good to me and I’d certainly love to see all the custom css plugins die a fiery death. The primary reason for that though is that I’ve seen them all hurt performance with slow queries on each page load. My mantra has long been that CSS doesn’t belong in the database.

      I suspect storing the data in a CPT (instead of _options) is going to be more performant, but I’m still very considered about it based on past experience. Wouldn’t be possible to store it as a static file while still having a similar UI to this proposal for editing that file’s content?

      Either way, is there a way it could be tied into the enqueuing system so it could be easily manipulated by themes and picked up by plugins that concatenate enqueued stylesheets?

    • Luke Cavanagh 8:11 pm on October 11, 2016 Permalink | Log in to Reply

      Not sure what the performance will be like for rendering out CSS from postmeta.

      • Nick Halsey 11:27 pm on October 11, 2016 Permalink | Log in to Reply

        Noting that it’ll use post objects directly, not postmeta. This is how Jetpack and WordPress.com do it, so I don’t believe there aren’t major performance issues with that, although I can’t speak to specifics there.

    • Tom J Nowell 9:39 pm on October 11, 2016 Permalink | Log in to Reply

      I’d just like to note that loading this post on a mobile is painful, I’m sure we can cut down a fullscreen 6MB GIF to perhaps a 640×480 view of a reduced size screen a quarter of the length, especially given that when roaming that GIF could cost a lot of money to load. I know my former carrier charges £6 per MB in the US and Canada, that’s £36 or $43 USD

    • vherring 10:09 pm on October 11, 2016 Permalink | Log in to Reply

      The feed back here is from developers the real benefactors of this kind of change is not developers, it in some ways threatens developers because if we get sophisticated in this feature a significant proportion peoples frustration with themes would go away. Like others I do feel storing in a database is too heavy for the feature at present and maintaining a method similar to existing mechanisms provides the flexibility in using the feature in the short term. Perhaps migrating to a different permanent storage method in the future as we become familiar with it and it is functionality is extended.

    • simonrcodrington 10:54 pm on October 11, 2016 Permalink | Log in to Reply

      Pretty excited by this. I think it’s a great idea to offer a more core centric solution to styles and the customizer is the perfect place for it. Having the ability to control styling in an easy to preview way will really help some of our more tech savvy users without giving me the stress of having to let them loose editing the child them.

      In addition to helping site admins, I can see this being really useful as it gives me the ability to quickly preview style charges without affecting live sites.

    • Ahmad Awais 12:17 am on October 12, 2016 Permalink | Log in to Reply

      Good one, Nick! +1 for Aditional CSS. I am just not so sure about the versioning part of it. While it is going to be an incredibly important part of this addition, at the same time it might confuse a beginner. What are your thoughts about that?

      • Nick Halsey 2:24 am on October 12, 2016 Permalink | Log in to Reply

        Versioning/revisions isn’t part of the initial proposal for 4.7. We’ll explore all of the considerations there in a future release, and your input/any ideas you have for improving the usability would be appreciated there.

    • Ipstenu (Mika Epstein) 1:18 am on October 12, 2016 Permalink | Log in to Reply

      CSS would be stored in a custom post type (without admin UI), with a post stored for each theme.

      One small thought… Sometimes users make changes that are not theme-specific. Like your example, Betty/Helen wanting to hide the author byline via CSS, if she changed from TwentyFifteen to the Magical Jumbotron theme, she should be able to grab the CSS from before. Otherwise she has to go back to her old theme and copy pasta.

      Right now, JetPack lets you restore by clicking from your older, saved revisions so stealing that would help 🙂

      • Nick Halsey 2:22 am on October 12, 2016 Permalink | Log in to Reply

        I explored this with the Modular Custom CSS plugin, which stores CSS intended for themes and plugins separately. In practice, I found that the vast majority of tweaks were specific to a particular theme since so much of the way the markup is structured depends on the theme. For the byline example, it would work on other themes using similar markup, but it’s hard to say how consistent themes would be there.

        That being said, there is definitely room for core to improve the cross-theme experience here over time.

        • Ipstenu (Mika Epstein) 5:31 pm on October 13, 2016 Permalink | Log in to Reply

          Yes but… consider that I may change my theme and keep my plugins. This may be intended to be theme specific, but (part of) the reason Jetpack CSS is so popular is that it’s outside my theme, so I can keep plugin css tweaks between themes 🙂

          • Knut Sparhell 1:33 am on October 14, 2016 Permalink | Log in to Reply

            Does Jetpack really keep custom CSS between themes? It says in a notice at the top of the editor that the CSS will be reset when changing theme.

            • Ipstenu (Mika Epstein) 11:54 pm on October 14, 2016 Permalink

              It does and it doesn’t. What it does is lets me click on the link to see the older versions, with the name of the theme. So I can go back and grab the old one. I’m not saying KEEP them as the active CSS, I’m saying make it easy for me to go back, get my old css, and restore it 🙂

              IIRC it’s via post revisions, but I could be wrong (and I’m currently not using it because I needed SVG stuff they don’t support).

    • David C 1:34 am on October 12, 2016 Permalink | Log in to Reply

      Fantastic idea and proof of concept, Nick! We get customers all the time asking how to “tweak” certain css elements without having to build a child theme. This feature would certainly fill that gap. BTW, nice animated gifs. What software did you use to create them?

    • James Collins 2:20 am on October 12, 2016 Permalink | Log in to Reply

      This is a great idea.

      We always need to write custom css rules when creating WordPress sites for clients. We’ve used our own Custom CSS plugin for many years, which helps us avoid the need to create a child theme just to override some CSS.

      We also have clients who want to tweak CSS rules themselves, so they appreciate being able to do so via the WordPress admin.

      Having this operate via the customizer with live preview would be a real time saver!

      In our custom CSS plugin, we save the CSS rules to the database, and also out to a .css file in wp-content/uploads/ , and reference that inside . So when the website is viewed, the .css file is loaded via a CSS link rather than being embedded directly in each and every page.

      I would have thought serving the static .css file from the uploads directory would be more performant than embedding the CSS in each and every page?

      We also use CodeMirror for the actual textarea/editor interface, which works well.

    • Kishores 5:14 am on October 12, 2016 Permalink | Log in to Reply

      +1 for Aditional CSS.

    • Hapiuc Robert 6:34 am on October 12, 2016 Permalink | Log in to Reply

      Really great idea, for small use of the feature storing the data in a CPT doesn’t sound so bad, but we all know how users act and things can escalade quickly.

      How the CSS will be embedded on the page?

    • Primoz Cigler 6:36 am on October 12, 2016 Permalink | Log in to Reply

      Excellent proposal Nick, I can see lots of positive feedback here and I can only add to it.

      One question: will there be another blogpost here in Make Core going more in details about implementation? With the introduction of Additional CSS in 4.7 we will be deprecating our custom CSS field from customizer and we want do to do in a safely manner by automatically migrating the existing custom CSS for our users.

      > How the CSS will be embedded on the page?


      • Nick Halsey 2:04 pm on October 12, 2016 Permalink | Log in to Reply

        That’s a good point, hopefully @johnregan3 can put together some boilerplate functionality for importing existing CSS data into the new core post type, and we can write a dev note for that during beta.

    • Hugo Ashmore 8:57 am on October 12, 2016 Permalink | Log in to Reply

      While I appreciate the sentiments here in the proposal I also have great worries when WP attempts to pursue the user focussed simplicity path as we are in danger of going too far and of encouraging bad code and broken sites and where those users tweaking wouldn’t especially realise something was amiss.

      CSS is not – as often it feels like it’s suggested – a simple language, yes it’s a simple declarative syntax but in reality a powerful tool for preparing the presentation of rendered code to devices, not simply a tool to make a link ‘green’, the cascade, the inheritance are hard aspects to grasp and the flow of rulesets important. CSS was never intended, really, to be worked as many separate disparate episodes provided by themes, child themes, plugins, core etc.. In many cases this results in sites that are problematic to say the least in maintaining with clashes in code that are largely unresolvable.

      I understand the issue though and that we are talking from the perspective of non coder/developers but from a developers perspective we have to understand that many – if from a Standards focussed background – would have a deep concern with the level of participation a client might have in that core site code, personally if a client came to me and expressed the desire for a major site build but also that they would tweak and play with the code as they saw fit I would decline the work as impossible or hard to maintain any sort of standard. implementing a proposal like this may worry developers and further isolate them from the WP sphere at worst (yes the functionality doesn’t have to exist ).

      The process for adding this custom CSS needs thought, embedding as often seen by plugins using wp_head is not a great idea filling the head element of a document isn’t good practise, never been so , embedded code isn’t cached as a linked file is, the page is weighed down, altogether not a good experience especially when perhaps many plugins drop their styles in. So preferably a method that somehow allows the writing of a file to be enqueued would be better although possibly with issues implementing.

      Regardless I do appreciate the intent in this proposal and the nature of WP is to be user focussed and friendly, with ease of use but we just need to think carefully how we implement improvements such as this.

      • Joy 2:59 pm on October 12, 2016 Permalink | Log in to Reply

        I agree that if you don’t really know CSS, you shouldn’t be using a feature like this. I think it could make it more difficult for support people to diagnose problems or clone a design.

        I already proposed the idea of treating the new CPT like an attachment, in that it would hold the file information of where the CSS is stored, and it would be embedded using a link tag, which means anything other than CSS in the file would be ignored.

        The problem I see with the way the interface is proposed is that the live preview should only come after the CSS is entered. Before that, there needs to be a way to toggle to see the source of the page so the proper selectors can be found. Basically, you need to have the browser’s Developer Tools there so you can see the existing selectors and the cascade and the autocomplete, etc.

      • FolioVision 4:13 pm on October 20, 2016 Permalink | Log in to Reply

        Thank you for articulating our shared concerns so well Hugo. A hidden custom CSS feature is a troubleshooting nightmare conceived to destroy developers lives. End users in the end won’t like it either when neither they nor their developer can make their site run right again without starting from scratch.

        The situation isn’t quite as bad as I’ve described above for very well organised developers (I imagine you fall into this class too Hugo). We’ll just add yet another nuisancy check to our checklists of what to do before we start work on a site.

        For our internal clients, we’ll be disabling the Customizer completely I believe as our clients don’t want a tool which could break their sites available to any site admin. It’s funny that developers all have to spend as much time fighting WordPress core these days as working with it.

        What we really need is rock solid caching in core and a built-in security solution and not more toys to break and slow websites. A CSS tweaker or theme builder should be standalone software or a web-based server. I don’t understand why we aren’t all working on such a tool together with Nick. Building a theme building into the core of your CMS is a very, very bad idea for performance, security and maintenance reasons.

        Complexity killed the cat.

    • laur3ntv 12:19 pm on October 12, 2016 Permalink | Log in to Reply

      What I generally do is that I try all the CSS changes in the Chrome Inspector and they apply them in a custom CSS plugin or file. It’s not user friendly and I have to go back and forth between the two.
      So I really love this feature proposal and give a huge upvote 🙂
      Thank you Nick!

    • Timothy Jacobs 7:08 pm on October 12, 2016 Permalink | Log in to Reply

      This is great! Fantastic work. Excited to see where this goes over the next few releases.

    • Weston Ruter 8:58 pm on October 12, 2016 Permalink | Log in to Reply

      Since the only feature provided in the WP_Customize_Code_Editor_Control is line numbers, I think we should skip including this in favor of just using a regular textarea control. In the future when we actually have a code editing control powered by a library like CodeMirror, then the textarea control can be replaced.

    • Daniel Bachhuber 9:01 pm on October 12, 2016 Permalink | Log in to Reply

      Echoing my comments made in Slack, I’m -1 on this proposal for a couple of reasons:

      1. A lot of my (and others) post_type != 'revision' code is going to potentially break. There’s historical precedent that revisions are the only “hidden” post type.
      2. I’m not sold on adding more IDE features to WordPress (that we’ll eventually need to replicate in the REST API)

      I’m opinionated towards having WordPress make decisions as to which elements of the page are configurable and how they can be configured (e.g. header color or background image), over recreating an IDE within the WordPress admin.

      • Aaron Jorbin 2:48 am on October 13, 2016 Permalink | Log in to Reply

        Assuming revisions are the only post type with no UI is far from a best practice. `nav_menu_item` for instance is another non-public nonstandard UI post type already in core.

    • idealien 11:25 pm on October 12, 2016 Permalink | Log in to Reply

      Question: Would this respect the DISALLOW_FILE_EDIT config variable?

    • Aaron Jorbin 2:50 am on October 13, 2016 Permalink | Log in to Reply

      After playing with this, I wonder if it would make sense to add an “Import from Theme” selector of some sort. That might give you a leg up when you switch themes. Was this tested at all?

    • davetgreen 7:17 am on October 13, 2016 Permalink | Log in to Reply

      I’d like to see a couple of filters introduced so that developers can:

      • Hide the CSS editor completely.
      • Prevent the use of `!important` by removing all instances on save etc.
      • Pass in an array of banned properties.
      • Insert a custom notice/advisory directly above the editor.
    • justnorris 9:01 am on October 13, 2016 Permalink | Log in to Reply

      Why not keep this as a plugin ? Why add more bloat to the core? I don’t see the argument for killing CSS Plugins just because they’re popular.

      All plugins solve some problem that the core has. There are 300’000 people using bbPress, I don’t see WordPress becoming a forum software in it’s core any time soon.

      Regenerate thumbnails has 1m+ installs, maybe merge that into core too – people obviously need it and it helps people after they switch themes or thumbnail sizes.

      The list goes on – “Disable Comments”, “Google Analytics”, “Loco Translate”, etc.

      Plugins extend the core. That’s what they’re made for, that’s why WordPress is awesome – everyone can customize the software to their own liking.

      Features that aren’t useful to most users should not be added to the core.

      This is going to clutter the interface, it’s going to add bloat to the core. If it ain’t broke, don’t fix it

      I get it. Custom CSS is rad, I make themes too, I get people asking for CSS modifications too. That’s why you have plugins like Custom CSS. There is just no need for this to become core.

    • treykane 4:06 pm on October 13, 2016 Permalink | Log in to Reply

      I’m a few days late to this debate, but I see a fundamental problem here…

      I have conflicted feelings on this feature as I know I’ve had many clients in the past that wanted this ability, and plenty of good plugins have provided exactly already. But, it seems WordPress is starting to diverge down two different paths, which is a much deeper problem than this proposal.

      1.) WordPress has been going for some time in the direction of becoming a CMS that supports data in a REST API. I think this is great, it puts WordPress in a position to become the backend for web applications of all kinds. Its user friendly, gives content editors a familiar place to go and work on their content, while still providing the developer with the flexibility to do whatever they need to on the front end.

      2.) WordPress keeps adding features like this one, that allow the user to customize the front end, and empowers the user to do whatever they want to do on the site. While this isn’t bad and is in-fact GREAT for a consumer centric product, its in contention with my first point.

      TL;DR –
      It feels like WordPress is trying to be two different products at once and at some point this is going to become a serious problem, on one end or the other. It feels like this proposal just continues to push the potential for identity crisis another step further.

    • Ximbalo 4:52 pm on October 14, 2016 Permalink | Log in to Reply

      This is a welcome topic that I have often wondered “How long before WP adds this feature?”
      I can see quite clearly how this would be a valuable and helpful feature for “simple customization” requirements.

      As long as it does not imply a gradual “phasing out” of the continued ability for more advanced and experienced developers to still create child-themes as needed.

      In my projects at least 50% of all child-theme edits are specific to and focused on the PHP of the parent theme and not just the CSS.

      Here is my input on the topic:

      1. Must Remain: PHP File Overrides:
      As a professional developer, I almost always cannot properly complete a project, nor apply ideal code-and-content top-down flow optimizations, without resorting to PHP template overrides. Suffice it to say, rarely does any given theme’s built-in page header or body structure suffice for my client customization requirements. The built-in CSS editor feature sounds great… as long as it does not lead to my eventually not being able to create child-theme PHP page template & include file overrides.

      2. Unwanted: Long Streams of Embedded Inline CSS
      To me, one of the *very worst* and sloppy coding bad habits of WP Theme developers in recent years, is that of “dumping” custom CSS directly into the code-flow as inline CSS — rather than at least allowing for the custom CSS to be compartmentalized into a single “custom.css.php” file.

      I have seen some themes that include a checkbox for this option – and I always admire that. If it does not exist, I will add my own PHP to remove the hundreds or thousands of lines of inline CSS that get dumped into my would-be “clean and optimized code”.

      Thus, when this new feature is added to WordPress, it would be good to include an option for all custom CSS to be written into a PHP generated include file. (Understood and acknowledged is the idea that this option is not compatible with DISALLOW_FILE_EDIT or Security Plugins that turn off back-end file edits.)

      3. SUMMARY: As a professional developer…
      A) I would use and benefit from this feature in cases of small, simple edits to a relatively simple site.
      B) I would use this feature to make clearly accessible certain “global styles” that I actually WANTED my client to be able to edit on their own ( i.e. global use of font styles, colors, & such )
      C) But only if an option was available to encapsulate the cusotm CSS into a single file (avoid dumping reams of inline CSS)
      D) I would NOT use this feature when hundreds of lines of advanced custom CSS are required
      E) This feature should really not be confused with no longer actually needing child themes due to the requirement of being able to override PHP template files.

      Thank You,


    • Philip Ingram 3:39 pm on October 20, 2016 Permalink | Log in to Reply

      As mentioned here -> https://core.trac.wordpress.org/ticket/35395#comment:71, I still feel like this type of tool is more “developer-centric” as 99% of my clients would never use this nor would I expect them to however I do see value in power users using something like this to tweak and fix very minor css.

      Ultimately, yes I do want this…but in core? Not so sure about that. I want to be able to turn this off and leave no dependency on loading the actual css from the db on the front end. The db stored css should only be used for revisions and live editing in the customizer and I feel the front end should still reference actual files that can be post-processed, cached and even off-hosted such as a CDN.

      If we can figure out a way of writing logical files that WP automatically loads based on file naming structure, similar to how themes do this now with the php file naming conventions, we would be golden and no one can complain about bloat, extra db cost etc. But again, do we need IDE features like this built into the core or should we amend the core only to allow for bettering our IDE plugins we use for development?

      Maybe we should consider requiring a constant in wp-config to enable IDE development features of wordpress, like this, like the current theme/plugin editors?

    • Sebastian Pisula 7:45 am on October 21, 2016 Permalink | Log in to Reply

      Why CPT? Why not theme_mods?

  • Nick Halsey 7:00 pm on October 3, 2016 Permalink |
    Tags: , , , , , themes   

    Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer 

    This is the feature merge proposal for the new themes experience in the customizer introduced with #37661. Here’s an overview of the current proposed UI:

    Customizer themes design and user flow mockup

    Customizer themes design and user flow mockup by @folletto.

    A theme is the most fundamental aspect of customizing a site. This project seeks to unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly in the customizer.

    Walkthrough of the latest patch on #37661.

    Walkthrough of the latest patch on #37661.

    Background & History

    The customizer originated as a tool for previewing and customizing themes and as such, was closely integrated into the theme browsing experience in wp-admin when it was introduced in WordPress 3.4. The theme browser and installer were rewritten in WordPress 3.8 and 3.9, respectively, offering a fast JavaScript-based way to explore, install, and switch themes.

    Eventually, as the customizer’s role grew to that of a framework for live-previewing any change to a site, it became apparent that it would benefit from a more direct way to switch themes, without entering the wp-admin context. The Customizer Theme Switcher plugin was created, and after some refinement, merged into WordPress 4.2. However, while it initially included external links to install themes in the admin, these were eventually removed due to the jarring experience of unexpectedly leaving the customizer.

    Currently, there is no indication that additional themes can be installed when viewing available themes in the customizer. For new users, it may take quite a bit of time to discover the ability to install themes, via wp-admin, or they may give up on WordPress before making this discovery. This is a usability dead-end where a user’s flow is disrupted in the process of discovering, installing, previewing, and activating themes, both on initial site setup and when considering a redesign.

    When the theme switcher plugin was developed, the team made preliminary plans for a theme installation interface as a second phase of the project. Specifically, it would leave the “preview” context of the customizer but retain the same identity in the user experience. @folletto helped develop this initial concept in early 2015.

    Technical Constraints & Requirements

    There have been several technical limitations preventing theme installation in the customizer from being addressed previously. Most notably, such an interface requires “shiny” ajax-based theme installation, updates, and deletion, so that the user flow can persistently stay in the customizer themes interface rather than jumping to separate “installing” views. This is now possible with phase 2 of “Shiny Updates” in WordPress 4.6. Additionally, expansions of the customizer JavaScript and JS-templated controls APIs to better support dynamically-registered controls were needed to support theme installation within the customizer framework, and these were fully fleshed out for the customizer menus interface introduced in WordPress 4.3. With these technical constraints eliminated, theme installation in the customizer is now possible without additional significant improvements to the underlying themes or customizer APIs.

    The customizer must currently be completely reloaded from PHP to preview a different theme. To perform a theme switch without a reload, theme-defined settings, sections, and controls would need to be updated dynamically with JavaScript. While the customizer internals have been working toward making this possible for some time, significant work remains to make inline theme switches possible. Therefore, changes to this part of the theme-switching workflow are out of scope for the current project, which focuses on the user-facing flow.

    The biggest usability block that this limitation causes is that unsaved changes are lost when the theme is switched. Unsaved changes are currently handled by prompting users with an are-you-sure notice in the browser before making the switch. Unfortunately, limitations in JavaScript require the loading indicator to be hidden after the user decides to stay on the page or to continue to the new theme, causing confusion. In the new interface, this is further mitigated by displaying a warning that there are unsaved changes, with an inline button to save and publish them, at the top of the interface. With customize changesets (transactions) (#)30937, a “save draft” option could also become possible in the future, allowing changes to be saved (potentially automatically) without being published between theme previews.

    Previewing Themes

    One of the biggest challenges with theme installation in wp-admin, and opportunities in the customizer, is previewing themes. Currently, a customizer-like frame displays a preview hosted on WordPress.org, with limited content. Rather than opening this potentially-disorienting similar but different interface, the proposed flow de-emphasizes the distinction between installed and available themes. The primary action for available themes is now “Install & Preview”, which installs the theme and live previews it in one step.

    Users can now see any theme on their site with their content and play with its options in the customizer in one click. If they decide it’s the wrong theme for their site, the themes panel can be quickly reopened and another theme selected and previewed with no harm done. A secondary action allows themes to be installed without instantly previewing, so that the installed themes tab can become a personal theme library of sorts, where users can save themes that they might want to try on their site. Installed themes being a filter along with the available theme headings unifies the previously-disorienting separation of themes and add-new themes on separate screens, with confusingly-separate search and header (add new/upload theme) functionality.

    Proposed Themes Interface

    Due to the tight integration with the existing system, with the existing theme control and section as well as internal elements in the customizer manager and theme details template requiring moderate modifications, this project was implemented as a patch and cannot be reasonably converted into a plugin and back. The patch has been available on trac for six+ weeks, with iterations continuing to improve and polish the new experience.

    The technical implementation continues adapting the concepts present in the backbone.js-based themes experience in wp-admin to leverage the customizer API. With the themes experience natively built on the customizer framework, it should be much easier for developers to improve and maintain the core experience in the future as well as extending the core experience in a structured way.

    A few highlights of the proposed details:

    • Installed themes are no longer loaded every time the customizer is opened, resulting in potentially significant performance improvements by only calling wp_prepare_themes_for_js() when needed. This also allows themes in the customizer to be fully disabled with remove_panel( 'themes' ).
    • The themes experience is unchanged on the top level of the customizer, but selecting the change theme button now opens a panel that fills the entire screen, as the preview is not relevant when considering a theme change.
    • The UI diverges somewhat from what is found in the theme installer in wp-admin (which will remain), particularly around the filters.
    • The theme details view is unified between installed and available themes; clicking on a screenshot opens the details view to match the admin UI.
    • Primary buttons are used where clicking them takes you away from the current page (ie, for previews); secondary buttons are used elsewhere.
    • The loading strategy attempts to balance performance with wait time by loading theme data from Ajax in large batches (100 themes) and following up by rendering screenshots as they become visible (as the existing interface does).

    Usability Testing

    Four usability tests have been conducted so far. The full test screencasts are available on Make/Design, alongside key takeaways. These tests expose a lot of largely-known issues with themes and the customizer in general, but did not reveal any significant issues with the proposed new theme browser. Because the tests were conducted in-person with a limited set of volunteers, additional testing with a broader user base would be ideal.

    There has been design feedback since the user testing was conducted, resulting in some significant changes. @karmatosed has volunteered to coordinate additional testing in the next week to verify that the changes haven’t introduced usability regressions, and to test with a broader audience. Check out the call for user testing on make/design to help out here.

    A visual record on a phone of the revised design has been posted on make/flow.


    Because the new interface is built entirely on the customizer API, third-party plugins should now be able to integrate much more easily. This means that other theme marketplaces (including commercial themes) could realistically be browsed (and maybe even installed) from within WordPress, while leveraging the core UI exactly.

    The presentational flexibility is available via the customizer API (with custom theme sections for other theme sources, and theme controls for individual themes), but there are likely some gaps in the ability to do this seamlessly in the internals. If anyone is interested in building this sort of functionality, please evaluate whether any additional hooks are needed so that they can launch alongside the new feature.

    Review and Approval

    In addition to a general core approval of this proposal, the following sign-offs are required before the feature could be approved for merge, based on the applicable elements of this list:

    • Flow (and mobile) review (see also an initial post)
    • Docs review
    • Security audit
    • Polyglots/i18n review
    • Design/UX review – tentative approval has been provided from @karmatosed and @folletto (with additional input from others in last week’s design meeting) with an expectation that minor adjustments will continue to be required. General design feedback is still welcome, but major changes are unlikely to be feasible at this point.
    • Accessibility review – @afercia completed an initial review, with the issues fixed in a subsequent patch. A comprehensive final review would be a good idea as well, since there have been significant design changes.
    • Code review – to be handled by @westonruter once the patch is otherwise deemed “ready” based on review from other teams.

    To test, update to latest trunk and apply the latest patch on #37661. On your test site, open the customizer and “change” the theme. Try out the various filters, browse themes, and install and preview them. Also test the inline update and deletion functionality.

    To meet the feature merge deadline for 4.7 (10/19), reviews from various teams and any corresponding iterations need to be completed by October 12th, leaving a week for final code review and commit. General feedback and specific reviews and action items should be provided as comments on this post.

  • David A. Kennedy 3:38 pm on December 1, 2015 Permalink
    Tags: themes   

    Menu ids in wp_page_menu() 

    In changeset 34330, we added a menu_id argument to wp_page_menu(), allowing theme authors to use a unique id with the containing menu div.

    It also means that, by default, the fallback menus have the same attributes as wp_nav_menu(). So wp_page_menu() and wp_nav_menu() now have the same menu_id. We made this change to help accommodate accessibility and certain ARIA attributes that require an id to be associated with a control. Before this change, theme authors lacked an easy way to add an id to that container.

    This shouldn’t cause most themes to break, except in a few edge cases. If you rely on the absence of that id in your theme for wp_page_menu() or do any kind of detection around wp_page_menu() vs. wp_nav_menu(), read on. I’ll go over a few recommended ways you can avoid your theme breaking with the release of WordPress 4.4.

    If you need to add class names or id names to the HTML output of either function, you can use a filter for that. Like this, using Twenty Fourteen as an example:

    function twentyfourteen_page_menu_args( $args ) {
        $args['menu_id'] = 'page-menu';
        return $args;
    add_filter( 'wp_page_menu_args', 'twentyfourteen_page_menu_args' );

    If you need to do something similar with wp_nav_menu(), you can either change the id with an argument in the template tag itself, or use a filer, similar to the page menu. Again, using Twenty Fourteen as an example:

    function twentyfourteen_nav_menu_args( $args ) {
        $args['menu_id'] = 'nav-menu';
        return $args;
    add_filter( 'wp_nav_menu_args', 'twentyfourteen_nav_menu_args' );

    Note that wp_nav_menu() adds the id to the ul element and wp_page_menu() adds it to the container element around the ul. So your CSS may need adjusting depending on what you have in place. You may need to make it less specific in some cases.

  • John Blackbourn 3:15 pm on October 7, 2015 Permalink
    Tags: , , themes   

    single-{post_type}-{post_name}.php: New theme template in WordPress 4.4 

    A new theme template has been added to the theme hierarchy as of r34800: single-{post_type}-{post_name}.php.  This template follows the rules of is_single() and is used for a single post or custom post type. It’s most useful for targeting a specific post in a custom post type, and brings consistency to the templates available for pages and taxonomies. It comes in the hierarchy before single.php and single-{post_type}.php.

    Don’t forget, too, that in WordPress 4.3 singular.php was introduced and the hierarchy of attachment templates was fixed.

    • petermolnar 3:22 pm on October 7, 2015 Permalink | Log in to Reply

      wp-config should have an option that sets the max allowed depth for template searches. As in:
      1 -> single depth, eg. single.php, {taxonomy}.php
      2 -> 2 level depth, eg. single-{post_type}.php
      3 -> unlimited depth, eg. single-{post_type}-{post_name}.php

      I wouldn’t be surprised it’d result in a measurable speed gain.

      • John Blackbourn 3:36 pm on October 7, 2015 Permalink | Log in to Reply

        That would save a maximum of about five file_exists() calls, depending on whether you’re using a child theme or not. I doubt it would have any measurable impact at all. file_exists() checks are very fast when absolute file paths are used.

        Additionally, it would introduce inconsistency to the template hierarchy, and consistency is a huge benefit of the theming system in WordPress.

    • kjbenk 4:07 pm on October 7, 2015 Permalink | Log in to Reply

      This is really cool and I can see an immediate use case for this.

    • Ravinder Kumar 5:05 pm on October 7, 2015 Permalink | Log in to Reply

      Nice addition to WordPress.

    • Dinesh Kesarwani 5:28 am on October 8, 2015 Permalink | Log in to Reply

      Yes! nice addition. I also suggested similar template before some time ago. But, it was rejected.

    • BenRacicot 12:10 am on October 10, 2015 Permalink | Log in to Reply

      Golf clap

    • elzix 2:26 pm on November 5, 2015 Permalink | Log in to Reply

      I read in the Theme Developer Handbook and assumed single-{post_type}-{post_name}.php was in WordPress 4.3. Is there a way to add the function to my theme or must I convert my posts to pages and use ‘categories for pages’ plugin?

  • Dominik Schilling (ocean90) 5:41 pm on July 30, 2015 Permalink
    Tags: , , themes   

    Legacy Theme Preview Removed in 4.3 

    This release we removed the old code for the Legacy Theme Preview, which hasn’t been maintained since the introduction of the customizer in WordPress 3.5. Recently, we noticed that the theme preview no longer works when using a static front page. We kept the old theme preview for no-JS and some browsers that were less capable. But since browsers are doing a better job today we don’t need to continue fixing/shipping this legacy code. It’s removed in [33492].

  • Aaron Jorbin 7:34 pm on July 6, 2015 Permalink
    Tags: , , , themes   

    Singular.php: New Theme Template in WordPress 4.3 

    A new theme template has been added to the theme hierarchy as of r32846: singular.php.  This template follows the rules of is_singular and is used for a single post, irregardless of post type.  It comes in the hierarchy after single.php, page.php, and the variations of each. Themes that used the same code for both of those files (or included one in the other) can now simplify down to the one template.

  • Derek Herman 8:00 pm on March 11, 2015 Permalink
    Tags: , , themes,   

    HTML5 Widgets in WordPress 4.2 

    Note: HTML5 widgets theme support in 4.2 has been reverted pending a decision about the correct container to use

    With the upcoming WordPress 4.2 release, widgets have been added to the growing list of HTML5 supported markup. Once you’ve added HTML5 support for widgets, WordPress will use the <aside> element, instead of the generic list markup.

    To declare that your theme supports HTML5 widgets, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

    add_theme_support( 'html5', array( 'widgets' ) );

    For forward compatibility reasons, the second argument cannot be omitted when registering support. Otherwise, a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking it visually.

    If there are any questions about the current implementation, feel free to leave a comment below.

  • Nick Halsey 11:00 pm on February 11, 2015 Permalink
    Tags: , , , , , , themes   

    Customizer Theme Switcher Feature Plugin Merge Proposal 

    Ticket: #31303

    Customizer Theme Switcher brings theme-browsing and theme-switching functionality into the Customizer. By integrating themes directly into the Customizer, live-previewing workflows are greatly simplified, and the relationship between themes and theme/site options is clarified for the user.

    This plugin represents a significant step in moving all “Appearance” functionality into the Customizer, following Widgets. The future roadmap includes Menus, Theme-Install, and iterations on widgets that would allow the Customizer to entirely replace those admin screens for most users. Because the Customizer Theme Switcher plugin does not address theme-install, the admin page (themes.php) is fully intended to remain in use for now. We are proposing to redirect the front-end “Themes” link (in the admin bar) to the Customizer, as was done for widgets in 4.1.

    Technical Overview

    Customizer Theme Switcher is primarily about adding new UI for existing functionality using existing APIs, rather than introducing new functionality. The plugin operates entirely off of the WordPress 4.1 Customizer API, leveraging the new JavaScript API in particular. Themes is a custom section (that acts kind of like a panel). Each theme is a custom Customizer control.

    The code is heavily Backbone.js-inspired, leveraging JS-heavy portions of the Customizer API to do things like underscore JS templates for rendering theme data. Most of the code is directly adapted from the Backbone-driven themes.php system (and the theme data is retrieved with existing functions), but things like the search/filter are written from the ground up to leverage the Customizer API (in that case, conditionally activating/deactivating controls).

    In keeping with the goal to avoid back-end functionality changes, theme-switches are accomplished simply by leveraging the existing ability to pass a theme as a URL query arg when loading the Customizer; ie, the Customizer is simply reloaded to preview a different theme. Loading overlays are leveraged to make this process seem more instant. Unrelated 4.2 core work around Customizer Transactions could potentially improve how this works.

    Core Changes & Merge Implementation Details

    As outlined in the plugin’s readme there are several proposed technical and user-oriented changes that are best done as core patches (mostly in the merge patch):


    • Remove #customize-info for theme previews.
    • Change front-end admin bar Themes link to point to themes in the Customizer (deep-linked).
    • When a new theme is activated, go to the home page (front end), not the themes admin.
    • If user doesn’t confirm that they want to leave unsaved changes, remove the customize-loading body class (requires core patch).


    • Move custom section and control to class-wp-customize-control|section.php in wp-includes.
    • Merge all CSS into customize-controls.css, scope to .wp-customizer.
    • Move .themes-panel-back to the Customizer header, adjust JS accordingly.
    • Merge JS into customizer-controls.js, after the respective object types.
    • Merge customize_themes_template() into wp-admin/includes/theme.php, at the very end. Make sure that this file is included at the appropriate time as needed when adding the Customizer controls.
    • Merge remaining PHP (all in Customize Register callback) into register_controls() in class-wp-customize-manager.php.

    User Testing

    @designsimply has run four usertesting.com tests (see links in #core-customize), and we haven’t really seen any ongoing issues with the actual theme switcher. It has been difficult to get users to follow our instructions, but when they have used the themes-in-Customizer UI, the interactions have been fairly seamless and as-intended. Further testing could be beneficial after merge, but we think that in-person testing and feedback is generally going to be more effective for this particular plugin.

    Outstanding Issues

    The exact handling of the themes header display still needs some work – the backwards-sliding works well but the arrows to indicate it don’t. @folletto opened a ticket on core trac to work through some alternative options. Most of the accessibility issues have been fixed as well (@afercia please let me know if I’ve missed any), with the exception of the Themes section header, which will happen along with the UI changes there for everyone.

    Future Plans

    A future phase of this project will explore integrating theme-install in the Customizer and minimizing the distinction between installed and available themes. Due to the larger UI and UX changes proposed with that effort, we’ve decided to hold off on theme-install for now so that the basic theme-switching functionality could be built on a reasonable timeline for 4.2. This is similar to the manner in which the “THX” feature plugin team re-did themes in 3.8 and theme-install in 3.9.

    • bellfalasch 9:31 am on February 12, 2015 Permalink | Log in to Reply

      Looks good =) I personally would love something like a top positioned overlay with short text “You are previewing Theme X – [activate theme] – [cancel]”. Or wouldn’t that make sense in the customizer?

    • Andrea Fercia 1:52 pm on February 12, 2015 Permalink | Log in to Reply

      Thanks very much Nick and great job 🙂 will review all your feedback on the accessibility issues list and will let you know.

    • codeinwp 9:10 pm on February 12, 2015 Permalink | Log in to Reply

      Looks really cool!

  • Nick Halsey 12:46 am on February 3, 2015 Permalink
    Tags: , , themes   

    Customizer Theme Switcher Update – 2/2 

    We’ve made lots of progress in the past week and will be holding another meeting tomorrow, Tuesday February 3 2015 16:00 UTC, in #core-customize Slack. The accessibility team did an extensive review and we’ve addressed nearly all of the issues that can be fixed in the plugin (big props to @afercia especially for reviewing and patching some of the issues). I made several core tickets (some with patches, some good-first-bugs) for some of the other issues that came up during the review.

    @designsimply and @vizkr have been working on formal and informal user tests as well. It’s been a little tricky to try to nudge users in the direction of the Theme Switcher in the Customizer without explicitly asking them to change the theme, but they haven’t had any negative feedback or expressed that having themes in the Customizer felt at all out of place. We’ve made a couple of minor adjustments both to the plugin (improving the filter to search for tags without hyphens) and the prompts, and additional tests are in-progress. We’d like to encourage anyone that can to do informal in-person testing, asking for feedback on the workflows and/or comparing the themes admin screen to themes in the Customizer.

    Our biggest remaining decision is whether to change the title of the “themes” section in the Customizer. Currently, it’s “Theme: Current Theme”. Open to suggestions here; we’ll tweak it for screen readers regardless if it works for everyone else as-is, but I’m not convinced that it’s the most discoverable option currently.

    Here’s an agenda for the meeting:

    • Usertesting.com testing update – @designsimply
    • Theme section heading title discussion
    • Informal testing/feedback updates – anyone
    • Accessibility updates: ready for (or do we need) another round of testing for the plugin? – @afercia
    • Outstanding issues – anyone
    • Final proposal and core patch/merge plan and timing – @MarkJaquith, me, @DrewAPicture
  • Nick Halsey 8:11 am on January 26, 2015 Permalink
    Tags: , , themes,   

    Customizer Theme Switcher Update 

    The Customizer Theme Switcher feature-plugin brings theme switching into the Customizer. This project aims to clarify the relationship between themes and theme options by introducing a themes “panel” (it’s actually a custom section since it contains controls, not a multi-level hierarchy of sections and controls) to the Customizer. The themes panel slides in from the left instead of the right, implying a hierarchy of:

    1. Themes – change the entire layout of the site
    2. Theme/site options – tweak various options (default view)
    3. Panels – edit larger groups of site appearance options, such as Widgets and Menus

    Essentially, the phase of the project proposed for WordPress 4.2 (and that exists in the plugin currently) brings the “THX38” theme browsing experience into the Customizer. Installed themes are browse-able directly in the Customizer controls panel, and have a details modal like the admin page. Functionally, theme-switching is accomplished by reloading the Customizer to live-preview a different theme. @westonruter is working on several related improvements that could further streamlining the experience from a technical perspective, but this feature plugin is focusing on the switching UI, with other improvements considered “nice to have”. @folletto and I have also started planning a second phase of the project for a future release that would also address installing new themes, and simplifying the distinction between installed and available themes. @designsimply is currently in the process of user-testing the plugin.

    Get Involved

    We’ll hold a meeting in #core-customize Slack to discuss the progress of the plugin this Tuesday, January 27, 2015 16:00 UTC, and continue at that time weekly as needed at that time. Development is happening directly in the WordPress.org plugins repo – I’ll give commit access to anyone interested in contributing code. Outstanding issues are noted below, but the plugin is generally ready for review of code, inline-docs, design, and accessibility (with each of those being theoretically good-to-go in the plugin). Note that the plugin can’t really work on mobile because the Customizer doesn’t really work on mobile, see #28784 (great 4.2 candidate if it gets a patch).

    Known issues (see also a list of core merge notes in the plugin’s readme):

    • Weston Ruter 9:53 pm on January 29, 2015 Permalink | Log in to Reply

      PostMessage setting transport may not be working immediately after switching themes, cause unknown

      I can’t reproduce this. See Slack conversation.

    • Rian Rietveld 7:40 am on January 31, 2015 Permalink | Log in to Reply

    • Devin Price 12:04 am on February 5, 2015 Permalink | Log in to Reply

      Hi Nick. Great work on this. A couple thoughts:

      I might recommend is that the theme panel stays open (retains focus) after switching. If someone is testing the look of a few different themes, it might be annoying to have to open that panel again each time and lose context.

      I’m not sure if the theme switcher should have such a high priority (in terms of order). I feel like switching themes has a lot of ramifications, and perhaps shouldn’t be the first option. I’d probably hook it in below the “widgets” (just a personal feeling though).

      Also, looks like the open/close arrows for the panel are pointing the wrong way.

      Maybe you’re already working through some of those. Just wanted to add my 2 cents.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar