How to Avoid Redeclaring Inline Styles for WordPress Customizer

My first publicly released theme, Follet (the one that powers this site right now), features my also first experiments working with the Customizer. This API offers a great way to see modifications to a theme in real time without actually having to apply those changes to the live site, and a large number of articles have been written about its benefits. What I learned while working on Follet was that sometimes is pretty difficult to manage some styling modifications for the customizable areas of the theme, and I particularly had a really nasty time with colours. However, I think I finally could solve that in an acceptably elegant way.

The Problem

You see, when you set a default color value for some areas of your theme, let’s say as a primary, dominant or accent color, you probably declare that default in a CSS file (most likely your style.css file) like this:

Then, when replacing that color through the Customizer, you need to override the former value by having something like this a later point in your CSS definitions:

Traditionally, this is solved printing a chunk of inline styles using the wp_add_inline_style() function, depending on the value of the property we’re modifying.

Got the problem already? When you need to apply that same color to other properties and selectors, let’s say coloured backgrounds, borders and shadows for different sections, divs and anchors, then you may need to add a lot of inline code. You have to write the selectors and part of its contents twice, both in your CSS files and in your PHP functions. As this is extra work that you need to perform manually, the chances of missing something that can lead to bugs increase, and any style addition you want to make in the future would need you to do the same work twice again.

The Solution

I ended up writing all the appearances of the color in a separated CSS file, which is passed as a parameter to a function that reads the contents of the file, stores them in a variable and performs a search-and-replace process that inserts the color that is selected in the Customizer inside said variable. Then, the modified contents are printed as inline styles after the main CSS file has been loaded.

So, this is how the CSS file could look like:

This is the function:

This is how the function is supposed to be used:

And this is how your markup will look like after implementing this method:

So here we have what we needed in the first place, but with one slight (or maybe huge) difference: This way you don’t have to replicate any CSS rules inside PHP files. When you have to perform some modification to your styles, you just need to do it in the CSS file and let the PHP function handle the rest.

I still have some concerns about the current and further application of this method, since right now it requires to load the primary-color.css file through a separated request. One solution to this could be adding the contents of the color file automatically to the main CSS file using a pre-processor like SASS or LESS, keeping the color file separated anyway, just for the reading part of the process, but never loading it directly. Alternatively, you could skip the loading of the primary-color.css file, even when the selected color is different from the default, and just print the inline styles. I also wonder if (and how) this could be applied to some other CSS properties.

This is still an experiment in progress that I’m looking forward to apply in many future projects, so any kind of feedback is welcome.

1 Comment

  1. Can You Make Tutorial To Execute Customizer Dynamic CSS Externally, Instead Of Executing It to wp-head with Inlince CSS ? Please Help

Leave a Reply

Your email address will not be published. Required fields are marked *