Rethinking WordPress Admin

Updated on December 29, 2015, Posted January 3, 2013

After having tackled customizing wp-admin with happytables, I’ve once again had the opportunity to go through the motions with an exciting project in a new vertical. The good news is that it’s completely doable:

Custom admin work in progress

The bad; it’s time consuming, hacky and leaves a bad taste in your mouth (similar to doing responsive web design in a rush). Both projects have had me wondering what opportunities exist and what sort of barriers of entry could be lowered with regards to how wp-admin is managed.

14,000 Lines

The first challenge and pain point you’ll encounter when trying to change the way wp-admin looks is the amount of CSS you run into. The core wp-admin styling adds up to at least 13,306 lines (14,000 with the random bits that get loaded in too). Considering the language doesn’t require any structure, that’s a LOT of code. What makes it worse, is that an editor viewport will only display the CSS properties for a fraction of elements at any given time (mine shows 50 lines, or 0.4%). This makes it quite hard to get a feeling for the general inheritance and specificity that governs the overall style (especially at 14,000 lines).

Plain CSS is so forgiving and detached that it becomes exponentially harder to manage with size. Now imagine trying to customize wp-admin away from the “one size fits all” approach, to something that actually speaks to the requirements in front of you. It’s mind-numbing. You can stop wp-admin.css from being loaded and throw in your own custom style, but are then in a very bad spot when an update comes around. So you’re left doing a lot of !important, border:none and display:none on an additional CSS layer. Like said, functional, but hacky.

Static CSS

The amount of lines aside, could the admin area ever become responsive? I do believe so, but not with the current CSS. Whilst I’m not advocating a mobile first approach or complete reorganization, some form of drastic measure will be necessary to make it all work. The reasons for this go beyond size, let’s backtrack a little to understand.

Admin in WordPress 1.5 used to be styled through over 500 lines. The overall DOM structure was also far simpler. In short, the CSS was fine as it was then:

WordPress Admin 1.5 – 3D view of DOM structure

Through the versions, the DOM grew and styling was added where necessary. The WordPress UI changed a few times too, getting us here:

WordPress Admin 3.5 – 3D view of DOM structure

Today, a number of elements will have issues such as containing relative positioning (example: top:-3px) or absolute values (example: font-size:14px).  This sort of immobile scaffolding means that in order to go responsive, you’d need to create an equal amount of responsive declarations simply to counter the existing code. That’s hard to justify.

Way Forward for the WordPress Admin

It’s painful to imagine that we would have to wait another 5+ years before the benefits of  CSS preprocessors would make their way into standard CSS. In that time, WordPress will certainly grow further, have new features added and become even more complex. New CSS would just be tacked on to the old, band-aids (top:-3px) would be applied to make things fit and the CSS files would burst the 20,000 line marker. It’s always been easier to gain weight then to build muscle. Trying to lose said weight later on is even worse. We have an opportunity for an easy win here.

In short, a preprocessor needs to replace the current CSS structure. Assuming we use the designer-friendly LESS, there is zero impact in migrating from .css to .less files tomorrow. The files simply need to be renamed (as preprocessors support standard CSS just fine) and best practices need to be established for compiling and minification (compilers exist for OSX, Windows, Linux, etc.). From there, work can be broken down into the following initial passes:

  • Variables & Mixins (1-2 days)
  • Nesting (5-10 days depending on accuracy)
  • File Segregation (1-2 days)

I wish I could have provided smaller and more tangible suggestions (fitting the trac mindset), but the problems are larger than that. The challenge here is also less likely to be one of technology, but rather of culture. The large majority of front-end developers, agencies, startups have all made the switch for reasons relating to productivity, workflow, clarity and so forth. We should too.

Recommended Reading