Upgrading Your WordPress Workflow: Sass, Gulp, Git, and More
Looking for the next step in your WordPress workflow? If you’re still working in a basic workflow (see first section below), here’s an overview of an upgraded workflow so you can more easily create and update websites in WordPress.
The workflow I’ll be covering below is by no means the only other workflow available, but it will allow you to utilize more advanced tools and mitigate some of the issues of the basic workflow. For a more advanced workflow, many developers use Composer to handle dependencies – but that is outside the scope of this article.
…the best audiences for this article are not only developers looking to change their workflows, but also project managers…
The other important item to note is that this article doesn’t dive into setting everything up to run this workflow. Each section will include a link out to another article that explains how to fully complete this step. This article instead is an overview of how all these technologies work together and why each step makes it easier for the developer.
With this in mind, the best audiences for this article are not only developers looking to change their workflows, but also project managers who would like to understand the terms and workflow of their developers.
The Basic WordPress Workflow
When a person starts working with WordPress, this basic workflow is typically what they start with:
Set Up Staging Site -> Install Theme -> Create Child Theme ->
Site Edits & Buildout -> Move Site to Live Server
Want to See the Final Workflow? Skip To the Bottom
It’s the most basic and quickest way to work on a site, but it does come with some drawbacks.
The Positives
First, let’s cover the positives:
- This is a fast way of getting the initial staging site up and start making edits to the theme and layouts.
- If you’re just working with minor modifications of a WordPress theme, this keeps everything simple.
- Small coding edits in the future are quick and easy on the live site.
- Any developer or even quasi-developer understands and can work within this workflow.
Why Change Your Workflow?
There are some significant negatives to this simple workflow:
- SASS is easier and quicker to code as compared to theme edits done with CSS
- There’s no version control – if you need to roll back an edit, you’ll need to re-code.
- The files are not automatically compressed or combined, which would speed up the site.
- You make coding edits on a live site.
- If you do keep a staging site, you don’t have a way to easily move files from staging to live.
Upgrading Your WordPress Workflow
We’ll be covering three different parts of this workflow: SASS, GULP, and GIT (with Bitbucket).
SASS: What it is and Why it’s Awesome
The first step to moving to a more streamlined workflow is to utilize SASS.
SASS allows you to write CSS quicker, easier, and keep it more organized.
You’ve probably heard of SASS before, but I’ll cover the basics here. Just like any other programming language, you have to not only use the language yourself, but also make sure the computer is taught that language. If you used a SASS file on a live site (replacing the CSS), the browser wouldn’t understand it. Instead, we have to output CSS for the browsers.
Write SASS -> Run Compiler -> Creates/updates CSS file (that the browser can read)
This fundamental requirement is why you install SASS and run it on your local computer. In order to do that, you’ll of course need a copy of the website on your local computer.
Learn how to set up a localhost website and get SASS running here >
At first glance, this might seem like too much work to do just to write CSS quicker. For smaller sites that start with a parent theme, you might be right. However, if you’re creating a site from scratch, writing CSS in SASS allows so many shortcuts that it is well worth the extra time to set up the localhost staging site.
If you’ve never seen SASS or would like to see a quick comparison, here’s a Github Gist (a tiny slice of code):
This might not seem like the biggest difference, but when you’re writing hundreds or thousands of lines of code, just the nesting ability of SASS can save a ton of time and future confusion. And SASS can do a lot more than just nesting – it can use variables, math, mixins, and more!
Gulp: Why Use it?
Gulp does a few major things for this workflow. When you save your SASS files, it can automatically change (compile) them into CSS, which is our first main task we need Gulp to do. It can also do a ton of other cool things, including combining all the CSS files and compressing them, combining all your javascript/jquery files and compressing them, and much more.
Gulp is a tool that has been expanded by developers to do 4000+ functions.
That’s because Gulp is a tool for automating and speeding up your workflow. There are over 4,000 ways this tool has been expanded by programmers, so if you’re looking for a way to compress, prettify, minify, bundle, sort, combine, and more, Gulp is a good place to look.
To use Gulp, you install it on your computer, and then include a javascript file under each website’s root folder. Follow the easy steps from Gulp.js (you’ll need to know how to use the terminal) here: Gulp’s Quick Start page.
To see a basic gulpfile.js (the control file for Gulp) file, see How to Set up a Basic Gulpfile.js File >
AFTER Gulp is installed on your computer and the control javascript file (gulpfile.js) in your website’s localhost files is set up, you’re ready to start.
- Open up the terminal,
- Navigate to the root folder of your website
- Type in: gulp.
Unfortunately, that only runs the tasks once, and if you’re editing a lot of files, you’ll want your tasks to run after every save. You can do this with Gulp too – you create a task in your project’s gulp file that runs every time you save: often called gulp watch. This setup is in the bottom of the basic gulpfile.js I linked to above.
So here’s our workflow at this point:
In Terminal, type gulp watch -> Edit SASS or Javascript file -> SAVE ->
Gulp will automatically run all the tasks you gave it (compiling, converting, etc.)
Now we are using SASS, compiling and combining files into a CSS file, and we’re ready for our next step: getting these files somewhere the client can see them.
Utilizing Git in Your WorkFlow
You might be thinking at this point that we have a major problem. We have the WordPress site on our computer and are writing in beautiful SASS that compiles into CSS automatically, but the client can’t see the website. We need to move the entire site from our computer to a hosting server that the client can see.
Before you go doing this manually, there’s a much better way: Git & Bitbucket
A Basic Explanation of: Git
Let’s start with a quick overview of what Git is. Git is a way of versioning your document/code/file. You install it on your computer and then can save your document or code at any time. Instead of saving the file as the same file, each time you “commit” the file, Git creates a new version of the file. Git is so effective because it doesn’t just save the entire file with a new time-stamped name, it actually only saves the edited parts of the file. So instead of having 10 files each 500KB big, you would have the first file of 500 KB, and each additional commit (or save) would be much smaller: maybe only 1KB or less. This feature makes Git economically intelligent in regards to file sizes.
Git is economically intelligent in regards to file sizes.
You can use Git on your computer by itself. You can use it on design files, documents, anything that you might want version control on.
A Basic Explanation of: Bitbucket
But we want to go one extra step: we want to have all the files that have changed uploaded to a staging site where the client can see them. “Commit” saves the file on our Git, while “Push” can move the file from our computer to a designated location online. To create a designated location that can handle what we’re doing, I’d recommend BitBucket.
BitBucket, unlike Github, can keep code private. If you upload your code into Github, everyone can see it. Github is used for showing the world open source projects and getting volunteers to collaborate on the coding with you. Bitbucket keeps your code private for only the people on the project.
To tell Git where to “Push” the files, set up a project (repository) on Bitbucket and then copy the URL they provide. We’d add that URL into the Git file inside our project, and voilà – we now can “commit” our files on our computer (save them in our computer’s Git), and “push” them to a certain protected place online.
But we’re not quite done. We need to take the files we’re saving on Bitbucket and “pull” them into an online staging site. Right now, the files are just sitting there. You can view the code, but it’s not running the site on Bitbucket. In other words, Bitbucket is just a repository for our files – it doesn’t run the code.
The final step would be setting up a staging site on your preferred server. Set up the database there as well. You’ll need to install WordPress and Git within the files with the URL Bitbucket provided, and then, by logging into the server’s Terminal (using SSH), “pull” the files from Bitbucket into our staging server.
Here’s our Git workflow:
Localhost website edits -> COMMIT (save) using Git -> PUSH the files into Bitbucket ->
Log into our hosting server using SSH -> PULL the files from bitbucket into our staging server.
The Summary of This Workflow
If this seems like a long process, don’t worry. The first time, you’ll be installing Gulp, SASS, and Git, but after you have these set up on your computer, the entire setup process moves quite fast; as does the saving, committing, pushing, and pulling. While I’m sure people have build single commands that will do this setup all at once, even keeping a default localhost website that you can copy speeds up the process quite a bit.
For the entire WordPress Workflow, here’s the steps:
- Create a WordPress site on your Localhost
- Make sure SASS and GULP are installed on your computer
- Create gulpfile.js within the root of your WordPress localhost install (same level as wp-config.php)
- Create the site; edit as needed
- When ready (at any time), COMMIT your edits (saves to your computer’s Git)
- Set up a Repository on BitBucket
- PUSH the changes to that Bitbucket Repository (Use the URL they provide)
- Create a staging site on your hosting (so the client can see)
- Log into your staging site on your hosting and install GIT (You’ll need SSH access to do this)
- PULL the changes from the Bitbucket URL
I would say the hardest thing about this workflow is that you’ll need to learn the entire thing at once. If you’ve never used SASS, GULP, or GIT, this can seem insurmountable. But it’s well worth the effort and isn’t quite as hard as it seems.
Have you recently switched to this workflow? Are you an expert with some helpful tips? Leave a comment below!
