Approaches to styling the WordPress backend

Being able to build sites that are intuitive and easy to edit is the primary reason I use WordPress. In this article I spoke about how the Gutenberg block editor has now become the de facto standard for setting up this easy editing. If you aren’t using react (which let’s face it – most of us WordPress devs are not not) then how can you style the WordPress backend so that it’s clear, simple and easy to navigate?

Option 1 do – leave blocks in edit mode

I see a lot of developers just leave the blocks in edit mode. Gutenberg blocks can be shown in either edit or preview mode with a button to toggle between the two. It’s also possible to force it to stay in one mode.

Edit mode shows the fields to fill in, preview mode is meant to show you what the actual thing that will go on the page will look like.

By setting blocks to always be in edit mode, it means that there is no visual preview. In many ways this is like using the classic editor except you have the added bonus of being able to reorder stuff on the page.

It works OK, depending on the site. Once you start getting 5-6+ blocks on the page it can get a bit hard to see where you are and what’s going on. It also depends on how complex the blocks are and how lost you get in a sea of fields (the more fields, the easier it is to get lost!)

Option 2 – Preview images

Each Gutenberg block has an is preview flag. This makes it very easy to show something different in the backend of the site than the front when the block editor is in preview mode. A very common technique I see a lot, is to just put a static image of the block as the preview. This can just be grabbed from the design file or even from a screen shot.

When you have lots of blocks on a page, this helps to differentiate between them. If most blocks are in preview mode and just the one you are editing is in edit mode there is far less confusion. Ultimately, what you are working in is much clearer. It also helps for reordering blocks as you get a nice overview of what the page ‘sort of’ looks like as a whole.

The main draw back of this technique is that the images are static. Any updates you make to the block are not going to be shown in the preview image. Over time (say a couple of years) it’s possible your content looks pretty different to the preview image that you took many moons ago.

I think this a big step up from keeping blocks in edit mode, but we can take it further still

Option 3 – Enqueue your front end CSS into the editor

If you’ve organised your CSS (or SCSS or whatever flavour you are using) into bite sized chunks then this technique is surprisingly easy.

As well as your main style sheet, you also create an admin one. This is essentially just a copy of your main style sheet. You can import all the regular styles and then add some overrides to tidy up some editor specific styles into this admin.css

You then add this line to functions.php to add this css into the editor screen.

function enqueue_admin_styles() 
{
    wp_enqueue_style('admin-styles', get_template_directory_uri() . '/dist/css/admin.min.css', null, 6);
}
add_action('enqueue_block_editor_assets', 'enqueue_admin_styles');

wp_enqueue_style takes in the name, the path, any dependancies (in this case none so null) and then an optional version you can use a cache breaker. My css is in the dist/css folder with the filename admin.min.css

Now you have the styles from the front end in the back end. With just a little tidy up you can space out blocks a bit more, maybe change some button styles and it’s pretty close to looking like the actual site. That admin CSS is only loaded in the backend Gutenberg editor screen.

Now when you make updates in the edit mode of a block those changes are instantly reflected in preview mode! When you go to edit the page is it immediately obvious what every block is and where to click to edit because you are looking at something that is essentially the same as the front end of the site! Nice one.

The only down side to this approach is that the WordPress backend has some quite specific styles for thing like buttons. Overriding these can be a bit fiddly and some extra work that arguably very few people see.

I’d argue that we’re not going for perfection here – we just need clarity. Being able to get a proper *real* overview of the page is incredibly useful. If some button styles are a little out of whack behind the scenes I don’t think it matters. What matters most with WordPress is that it’s intuitive and easy to use and this helps with that massively.

Even if all you do is add a couple of extra lines and bring your front end css into the editor as is, you’ve already massively improved the user experience. Go that extra mile my friend.