WordPress development can be simple if you want it to be. You can follow the codex to the letter and put your styles inside
styles.css and your PHP inside
functions.php. But is that necessarily the best way of doing things?
There answer is… ‘probably not’. Well, actually, it’s ‘not at all’.
You see doing things that way might seem logical during your first foray into web development, but as you learn more and begin to take on bigger challenges you soon realise that it will cause you a lot of trouble down the line. You’ll notice this especially when your projects start to include more custom PHP, instead of just the usual
get_footer();, and the infamous WordPress Loop.
I discovered this myself a year or so ago, realising that for every project I was building, I was coding stuff over and over that would be better off as part of a boilerplate that I could initialise for every project. After spending some time collecting everything together, I’m pleased to introduce WP Boilerplate.
I use this for every WordPress project now and I’m improving it every day with new features. Bare in mind you will need NPM and Composer installed in order to use it.
Currently it features the following:
- Simple but sensible folder structure for assets and PHP.
- Integrated dependency management using NPM.
- Plugin management using Composer.
- Jeet, an advanced grid system.
- Asset management using Gulp, including autoprefixer for your CSS (meaning you’ll never have to write another vendor prefix ever again!).
Take a look around and see what you think. It might seem overwhelming or confusing at first if you are new to using NPM/Composer, and other tools liek them, but it’ll be well worth it in the end.
Want to give the boilerplate a go? Follow these steps to set it up:
- Download a zip of the latest stable release.
- Unpack the zip into the root of your
- Change the details in
package.jsonto those of the new theme you want to build.
sudo npm installin the theme root. This will install the dependencies for the project.
composer installto install the plugins listed in
composer.json. The ones I have included by default are useful during development when you are messing around with image sizing, or seeding the database with some dummy data. I also include Advanced Custom Fields by default because it’s the best thing to happen to WordPress since, well, I can’t think of any bread related puns right now but you get the idea.
You may be used to putting all of your PHP inside functions.php. However, this will get annoying when you have loads of functions that you’ve written just shoved in there. It doesn’t make for an organised setup. That’s why I like to organise my functions into smaller ‘partials’ that I then include inside
functions.php, like so. You may have noticed the ‘ACF’ code in there too; that’s because I like to include Advanced Custom Fields inside my theme for production to hide the ‘Custom Fields’ menu from content managers. You can learn more about that here.
The boilerplate has a pre-setup assets structure that focuses on keeping everything logically grouped. Sass goes inside
assets/js, and images inside
assets/img. Gulp is then used to compile all of the Scss and JS, and optimise the images. It then spits it all out inside the
public directory. This means you don’t need to version control all your compiled assets, which keeps you git repository cleaner and easier to manage.
There are some handy gulp tasks set up for you including the following:
- Default task: Watches your project for changes, automatically compiles your assets, and live reloads your tab using LiveReload.
- Deploy task: Runs all of the asset compilation tasks, and also minifies everything and removes any debugging code.
Checkout the gulpfile to learn more.
When you want to deploy your theme simply run gulp deploy to create all of your minified assets and then upload the theme via FTP or
git pull it to your server using SSH.
These simple changes make it much easier to manage your WordPress projects, and you’ll quickly begin to wonder how you did without them. Your standards will rise and you’ll end up writing more efficient, maintainable code. I’m currently working on a more object orientated system for managing post-types and meta fields too; feel free to fork this project and contribute!