In the previous post, we discussed about how to setup and create your first child theme, how to structure the files, as well as the stylesheet that comes with it. In this post we will setup a working environment for the child theme stylesheet that is automatic, and does not require a lot of maintenance.
As you may have noticed, our current child theme uses the same styling as the parent theme, and in most cases, you would want to apply your own styles according to the design approved or given by the client.
Setting Up Sass
The easiest way to do this is to straight up put your CSS overrides on the
style.css file of the child theme. If you remember, the child theme styles is enqueued after the parent style, and thus will override whatever the parent style is.
The exception for this rule is when the parent has
!importantproperty, or the selector in the parent stylesheet is more specific than in the child stylesheet.
The one obvious drawback of this method is that you are actually using CSS syntax to override the parent stylesheet, and you may end up having a very long CSS rule. To solve this issue, we will set up a Sass folder that will be parsed to a single
style.css file, that will then be enqueued after the child theme.
To better illustrate what we’re trying to achieve, this is what your folder structure will look like:
public_html └ wp-content └ themes └ twentyseventeen └ twentyseventeen-child └ style.css └ functions.php └ css └ main.css (compiled from main.scss) └ sass └ main.scss
In theory, in the folder structure above, you could have your Sass files directly parsed to the child theme’s
style.css file. However in doing this, you may actually face further complications in the future, so I would suggest to actually enqueue the parsed
main.css. We also no longer need to enqueue the child theme’s
style.css to be enqueued, as the
style.css does not contain any stylesheet rules.
As you can see from the snippet above, we no longer enqueue the child theme
style.css, but instead replacing it with
main.css on line #7.
You can also see that I have added a timestamp with the PHP function
time(). This is helpful during development where WordPress, your browser, or any of your plugins decided to cache the CSS, as adding timestamps means that the file would always be regarded as “new”.
The obvious question is, how are we going to parse our Sass file then? Compiling Sass locally is easy, but compiling Sass on the website? And my answer to that is, plugins. There is this one simple and straightforward plugin, the Lenix SCSS Compiler that will help you to compile your Sass file on the server where WordPress is installed.
In the plugin page, you just need to specify the folder where your Sass file is stored, and the destination folder where you want the compiled CSS to be stored. And then each time you made a changes on your Sass file, it will automatically compile it for you.
Although the plugin page did say that it has not been tested with the latest WordPress release, as of 2019, the plugin still works as expected.
Going a Step Further
As you know, in Sass, you can modularise the files and then import them on the main Sass file. I would strongly suggest to do this in your setup so later on it would be much easier to maintain and look for specific rules for a specific page.
In the context of WordPress, it is best to modularise the files based on a combination of type of page, as well as the WordPress template hierarchy – which we will discuss later on.
WordPress also assigns a specific class to the
<body> of each HTML page. For the homepage, this is
.home, for any other page, this is
.page, and for any blog posts this is
.single. You can use this to tailor and modularise the Sass structure.
At the end of the day, you may have a folder structure like the following:
themes └ twentyseventeen └ twentyseventeen-child └ style.css └ functions.php └ css └ main.css (compiled from main.scss) └ sass └ main.scss └ _home.scss └ _page.scss └ _single.scss
With the above structure, we can modify the
_home.scss, for example, to make the homepage heading coloured in red.
And then import it inside the
main.scss, which will then be compiled and turned to
main.css in its respective folder.
Today we have managed to set up a working environment for our styling needs, and I am hoping through this setup – which we will probably tweak as we go along – it would allow us to quickly resolve any issues related to the website styles.