Though WordPress is increasingly on the verge of becoming a fully-fledged application framework, the humble post editor remains the area of the interface users spend most of their time in.
It’s a part of the backend that’s seen significant improvements over the last number of years – the recent move to version 4.0 of TinyMCE in WordPress 3.9 being a highlight – but there’s still plenty of room for improvement.
One of the most common problems users have with the editor is the need to constantly switch between editing and preview modes to see how content will actually look live.
In this article we’ll tackle that exact issue and break down how to customize the WordPress text editor to look and function like your front-end design.
Why Would I Want to Customize the Editor?
When you’re busy bashing out an initial draft of a post or page, the final look and feel of the text is the last thing on your mind. What matters is getting your thoughts down and – as Steven Pressfield so elegantly put it – covering the canvas.
As you move on to the serious business of editing and revising however, the fact that your content exists in a context becomes ever more important. Typically, this manifests itself as heavy reliance on the built-in Preview button.
Let’s be clear – there’s nothing intrinsically wrong with the Preview button. It’s a fantastic piece of functionality to have at your fingertips.
If you’re simply popping in to update a line or two in an article, it’s a great way to check your changes before hitting Publish. If you need to give an article a thorough proofreading before submitting for review, it’s similarly useful.
Where it’s very far from ideal is in the daily cut and thrust of putting together a main draft. In fact, when you’re working on a longform piece over a potentially slow remote connection it can quickly become a major problem for two significant reasons:
- Context switching: Writing is about getting into a groove. Once you’re in it, you want to stay there. Having to constantly switch between browser windows and different visual contexts is a killer for focus and flow.
- Time: All those roundtrips between the editor and the preview window add up over the course of a working week. Test it yourself. The next time you’re working on a piece, make a note of how often you switch tabs. That’s time that could have been spent polishing the actual content.
By customizing the editing screen to match your front-end display, you remove the need to constantly preview your work. It makes the editor far more of a genuine WYSIWYG tool.
For example, maybe you’re worried a particular paragraph is slightly too long given the generous line-height and font-size your theme employs (as seen here on WPMU DEV). Customize your post editor and the end results are right there on the screen in front of you as you type.
Taking the extra time to customize the backend has a couple of further major advantages also worth pointing out:
- It makes it far easier for non-technical team members to input content in a context that will be instantly familiar to them.
- It makes a great high-end finishing touch to add when you’re preparing a site for an external client who might be coming to WordPress for the first time.
What About Front-End Editors?
Some of you may well be asking at this point: what about front-end content editors? Isn’t this what they’re designed to do? And wasn’t there talk of the Front-end Editor plugin being built into the next release of WordPress as a core feature?
Good questions. Let’s take them one at a time.
The great promise of these editors is that they let non-technical users interact directly with the content of a website to make changes. They can be perfect if you’re just looking to make small changes to existing sections of content and are usually a snap for less experienced admins or site owners to use, assuming they’re set up correctly.
The downside is the restricted range of functionality such solutions typically offer – both in terms of editing itself and lack of access to advanced post features such as meta boxes. They also put a barrier between you and the functionality on offer in the rest of the backend admin.
Then there’s the issue of editorial workflow and control to consider. A front-end editor is great if you want people to just be able to go in there and change things immediately, but that is very much not always the case.
The final sticking point is the issue of complexity. Putting together a solid front-end editor is no trivial undertaking. Many of the best plugins out there are commercial offerings, meaning you’re adding another level of paid dependency to your setup and having to worry about future compatibility with other parts of your theme.
Many of us were hoping some of that complexity would be mitigated by the inclusion of the Front-End Editor plugin in WordPress core.
Sadly, after much initial excitement, those hopes were destined eventually to be dashed.
From late 2013 up until late November 2014, this plugin was under active development as a Feature Plugin meaning it was scheduled for eventual release into core.
The project has unfortunately stalled since then, and been moved on to the Inactive Feature Plugins list. Sadly, it’s safe to say we won’t be seeing its appearance in core anytime soon.
If you are interested in trying out a front-end editor then we’d recommend trialling either the Front-end Editor (free), Visual Composer (paid) or Live Composer (paid), but be aware of the potential complications we’ve mentioned above.
The approach we’re going to take in this article, on the other hand, gives you a simple way of skirting around these snags and getting down to the matter at hand: making your content sing.
Let’s start making it happen.
Setting the Stage
Every site will naturally have different content and potentially wildly different theme implementations. For the purposes of this article, we’re going to strip things down to give you a solid understanding of the basics that you’ll then be free to apply to the particular requirements of your own setup.
We’ll be using a local setup of WordPress and starting with a version of the WordPress Theme Unit Test data to illustrate our points. If you’re starting to look at customizing your own environment, taking this approach offers a couple of obvious benefits:
- By developing locally, you’re free to experiment without risking disruption to your users or co-workers.
- The WordPress Theme Unit Test data gives you a sensibly organized set of core content to test your changes against. It’s the perfect platform to start with when exploring theme changes of any kind, on both the front and back end.
If you’re following along, you can either replicate this approach or simply activate your own theme on a local install with your current site content.
We recommend the former as an initial stage. The content provided by WP Test is an excellent way of checking how complete your current theme’s styling is before you start making major changes to it.
Understanding What’s Going On Under the Hood
Now that we have some sensible sample content to look at, let’s take some time to understand what’s actually going on under the hood in WordPress before we look at customizing the editor itself.
As we mentioned at the top, WordPress ships with the open source TinyMCE editor as standard. This is, so to speak, the bottom of the theming stack.
TinyMCE has its own stylesheet that controls how content is displayed within it. By default, this is blissfully unaware of the outside world. The developers of TinyMCE were sensible enough to make room for additional stylesheets to be loaded into it, however, via a hook called content_css.
For their part, the developers of WordPress were kind enough to wrap this in a native function called
add_editor_style. This has been included in WordPress core since version 3.0.0.
If you consult the online documentation, you’ll see this function is tucked away in wp-includes/theme.php. We’ll be looking at ways of calling this function directly in just a few minutes.
By default, WordPress use this function to check for the presence of a CSS file in your theme’s root directory called editor-style.css that it can use to style the contents of the editor.
So, if you are looking to customize an existing theme, one of the first questions you have to ask yourself is does an editor-style.css file already exist in your theme?
If we take the Twenty Fifteen theme as an example, we can see that it does indeed include such a file. A quick toggle between the preview and admin views of our Markup and Formatting page shows that the core styles are being faithfully replicated between environments.
Let’s take it a step further and doublecheck that the styling we’re seeing in the editor window is definitely being controlled by editor-style.css. A quick trip to the Web Inspector is all we need to confirm that this is the case.
Hopefully the basic scenario is relatively clear at this stage. To recap:
- The WordPress editor is powered by TinyMCE.
- TinyMCE allows its default styling to be overridden.
- WordPress uses a function called
add_editor_styleto specify which CSS file should be used to override default styling.
- By default, WordPress looks for a file called editor-style.css in the root of the active theme.
The next question is how to handle making your own changes.
Making Your Own Changes
As suggested above, the first thing that needs to be cleared up is the question of whether there’s a default editor stylesheet file in place in the root of your theme’s folder.
If there is, we suggest making a copy in the same location and calling it custom-editor-style.css. This gives you a clean place to start experimenting and an easy way to revert to the original setup.
If there is no file in place, create a new file called custom-editor-style.css and place it in the root of your theme folder.
Connecting Your Custom CSS
Our next step is telling WordPress to look for our new file rather than the default. We’ll do this by adding an override in our theme’s functions.php to call
add_editor_style and tell it to use our new stylesheet.
Open up your theme’s functions.php, add the following lines at the end, and save.
Now let’s check that our editor is actually using the new stylesheet. Again, a quick trip into the Inspector is all we need to be sure. As you can see below, we’ve now successfully established a connection with our new file.
Now let’s make a couple of quick changes to the CSS file to make sure they’re being picked up on the backend.
First of all I’m going to make those headers a fetching shade of green by editing custom-editor-style.css.
The headers were changed by adjusting the following CSS: