Compiling and testing the changes

Over the last few pages, we've covered a number of key tasks that would be perfect for compiling WordPress themes.

In an ideal world, we would automate as much as possible, or at least tasks where it would make sense—to remove tasks that give little value when done manually, for example. The key, though, is to give plenty of thought as to which order these tasks should be carried out; getting the order right can be the difference between receiving a valid style sheet file ready for use, and getting…well, what can only be classed as rubbish! Yes, that might seem a little extreme, but if the task order isn't right, then you can get compiled files that break your theme.

Leaving this aside, let's take a look at compiling our code—for the purposes of this exercise, we will use a copy of the pre-edited files that are available in the code download that accompanies this book.

Note

Before continuing, you may like to save copies of the source files you've created in the src folder that sits at the root of our project area, for safe keeping.

To get a feel for what we will be discussing, this is a screenshot excerpt of the Twenty Sixteen theme in action:

Let's make a start:

We'll start by downloading and extracting a copy of the src folder that is under T68 - converting a WordPress theme in the code download; save this to the root of our project area. Make sure there are no other files present in this folder first!
Next, make sure that the gulpfile.js and package.json files that we downloaded earlier are still present—we will need both during compilation.
Go ahead and fire up a Node.js command prompt session, then change the working folder to the root of our project area.
At the prompt, enter gulp then press Enter; Gulp will run through each task and spit out a compiled theme file in the dest folder at the root of our project area.
Copy this to the root of the Twenty Sixteen folder, which can be found at C:\wamp\www\wordpress\wp-content\themes\twentysixteen—if you use Linux or OSX, then please alter the path accordingly.

We now have a fully compiled style sheet! There are some points of note though—for example, the order of tasks that we covered earlier in this section doesn't match the order shown in the gulpfile.js file. Let's cover these points now:

The type of tasks you include can be split into two groups—those that I would describe as core, such as minifying files or providing source maps; these can be done for any sites. The second ones are custom tasks—these will be specific for each site, and might include requests to compile variables or nested code. It's up to you to plan how these are created, so that you can reuse them for future projects.

There is no right or wrong answer as to what should be included in a Gulp task file; the tasks you want to include, and the order they are called, will ultimately be determined by your own requirements. In our example, we used this order, from top to bottom:

Name of task	Purpose
`styles`	This compiled the raw code—merging the rules into one file, running PreCSS through the code, and updating vendor prefixes where needed.
`pxrem`	With the base code in place, we can now run through it and add pixel fallback for rem units, where appropriate.
`lint`	In this task, we're checking the compiled code for consistency.
`rename`	We then rename our base compiled file to have a `.min.css` extension; this is in preparation for minifying our code.
`sourcemap`	At this stage, we want to produce a source map, so this task kicks in to create a suitable map file for us.
`minifyCSS`	The final task is to minify the CSS style sheet file—it already has the right extension in place.

We've done the hard work—it's time to see the fruits of our labor in action. The style sheet is now in the theme folder within our WordPress installation—all that remains is to test it! We could get into using automated testing facilities such as Quixote (available from http://www.quixote-css.com/), but this would fall outside of the scope of this book. Instead, we can simply launch our local WordPress installation and check to see what it looks like—this is a useful way to gauge if there is anything amiss with our theme.

For our demo, we used the Twenty Sixteen theme. Out of the box, this is a very bare theme. Although this may not seem much, we've done most of the hard work needed to implement a PostCSS workflow when working with WordPress. A key measure of success is that the base theme should be identical to the original version that came with WordPress. If this is the case, it then means we can now concentrate on manipulating our style sheet over a period of time to further develop the styles within this (or any other) theme.

Previous Chapter

Making changes to our code

Next Chapter

Summary

Table of Contents for Mastering PostCSS for Web Design

Compiling and testing the changes

Note

Table of Contents for
Mastering PostCSS for Web Design