If you’ve been following along since my WordCamp Atlanta trip this spring you know that I’ve been working on automating my WordPress plugin development and production process. If you missed it you can read about it in theWordPress Workflow and WordPress Development Kit articles. Since I needed to patch some basic CSS rules in my Store Locator Plus themes, these are plugin “sub-themes” that style the store locator interface within a page, I decided now was the time to leverage Sass.
Sass Is In The House
It was one of my first sessions at WordCamp Atlanta and I KNEW it was going to be part of my automation process. Sass is a CSS pre-processor. Store Locator Plus has its own “theme system”, a sort of plugin sub-theme that lives within the WordPress over-arching site theme. The SLP themes allow users to tweak the CSS that renders the search form, map, and results of location searches to create in-page layouts that better fit within their WordPress theme layout.
Until this past release it was a very tedious process to update themes or create a new theme. In the latest release there are some 30-odd SLP theme files. The problem is that when I find an over-arching CSS issue, like the update to Google Maps images that rendered incorrectly on virtually EVERY WordPress Theme in existence, it was a HUGE PAIN. I was literally editing 30 files and hoping my cut-and-paste job went well. Yes, I could have done CSS include statements but that slows things down by making multiple server requests to fetch each included CSS file. Since the store locator is the most-visited page on many retail sites performance cannot be a secondary consideration. Sass deals with that issue for me and brings some other benefits with it.
There are PLENTY of articles that describe how to install Sass, so I am not going to get into those details here. On CentOS it was a simple matter of doing a yum install of ruby and ruby gems and a few other things that are required for Sass to operate. Google can help you here.
My Sass Lives Here…
For my current Sass setup I am letting NetBeans take care of the pre-compiling for me. It has a quick setup that, once you have Sass and related ruby gems installed, will automatically regenerate the production css files for you whenever you edit a mixin, include, or base SCSS file.
I combine this with the fact that the assets directory is ignored by the WP Dev Kit publication and build tasks to create a simple production environment for my CSS files. I store my SCSS files in the ./assets/stylesheets directory for my plugin. I put any includes or mixin files in a ./assets/stylesheets/include subdirectory. I configure NetBeans to process any SCSS changes and write out the production CSS files to the plugin /css directory.
The first thing I did was copy over a few of my .css files to the new stylesheets directory and changed the extension to .scss as I prepared to start building my Sass rules.
I then ripped out the repeated “image fix” rules that existed in EVERY .css file and created a new ./stylesheets/include/_map_fix.scss file. This _map_fix file would now become part of EVERY css file that goes into production by adding the line @include ‘include/_map_fix” at the top of the SLP theme .scss files. Why is this better? In the past, when Google has made changes or WordPress has made changes, I had to edit 30+ files. Now I can edit one file if a map image rule is changing that has to be propagated to all of the css files. However, unlike standard CSS includes Sass will preprocess the includes and create a SINGLE CSS file. That means the production server makes ONE file request instead of two. It is faster.
As I reiterated this process I ended up with a half-dozen CSS rules that appear in MOST of my CSS files. Since all of the rules do not appear in all of my plugin theme files I ended up with a half-dozen separate _this_or_that scss files that could be included in a mix-and-match style to get the right rule set for each theme. I also created a new _slp_defaults include file that does nothing more than include all of those half-dozen rules. Nearly half of the current CSS files use all of rules that were “boiled out of” the CSS files.
Along the way I learned about mixins. At first I was a bit confused as to the difference between include files and mixins. Both are “pulled in” using similar commands in SCSS, @import for the “include files” and @include for the mixins, but what was the difference? While you can likely get away with “faking it” and having mixins act like includes they serve different purposes. I like to think of a mixin as a “short snippet of a CSS rule”.
A common example is a “set the border style mixin”. In the simplest form it can set the border style with a rule for each of the browser variants. This rule is not a complete CSS rule but rather a portion of a CSS rule that may do other styling AND set a border. The mixin includes the -moz and other special rule sets to accomodate each browser. Rather than clutter up a CSS entry with a bunch of border-radius settings, use a mixin and get something like:
That is a very simplistic way of using a mixin. One advantage is that if you decide to change the default border radius settings in all of your CSS files you can edit a single mixin file. However that is not a typical use. Yes, you can create subsets of CSS rules, but it really gets better when you add parameters.
At a higher level a mixin is more than just a “CSS rule snippet”. It becomes more like a custom PHP function. In typical coder fashion, I snarfed this box-shadow mixin somewhere along the way:
Notice how I now call in the include with parameters. This is passed to the mixin and the Sass preprocessor calculates the final rules to put in the CSS file. This makes the mixin very flexible. I can create all sorts of different box shadow rules in my CSS files and have the cross-browser CSS generated for me. No more editing a dozen box shadow entries every time I want to change a shadow offset.
Here is what comes out in the final production CSS when using the above mixin. You can see where the parameters are dropped into the .results_entry CSS rule:
This is only a start of my journey with Sass and I’ve barely scratched the surface. However I can already see the benefits that are going to come from using Sass. In fact I already used it to fix a problem with cascading menus where one of the SLP theme files did not contain a rule set. Rather than copy-paste from another theme file that contained the proper rules I only needed to add @import ‘include/_slp_tagalong_defaults’ and the problem was fixed.
Going forward Sass will not only increase my throughput in CSS development but also improve the quality of the final product that reaches the customer.
My first SLP Theme file, Twenty Fourteen 01, that was built using these new Sass files is only a 136 line CSS file with LOTS of whitespace and comments. When the final processing is finished it has all of the rules necessary to support the current add-on packs and style them nicely for the WordPress Twenty Fourteen theme in all major browsers.