WordPress, which Barques uses to create and manage all of its clients’ websites, is a great content management system (CMS) and there are some key reasons why 23% of the web is powered by it. I put this down to the low entry point for starting WordPress development, as well as the system’s power and flexibility when it is used correctly. Even some very large sites – notably BBC America, TechCrunch and BestBuy – that you might not expect, are powered by WordPress.
The low entry point often means that people will take shortcuts in their development and rely on bloated plugins to do simple tasks. Using lots of plugins on one site will create security risks, increase code bloat (badly written code that is longer than it needs to be), and decrease portability and the ability to version control your applications.
Creating many sites in WordPress and learning from the frustrations of working with other people’s code (mainly plugins) has helped me to develop a streamlined workflow that works for me, although it is constantly evolving and improving.
Vagrant is an excellent upgrade when coming from MAMP (Macintosh, Apache, MySQL, and PHP), my old development environment. It allows the user to create an exact replica of its live server, which allows me to edit files on a copy of the live server without constantly having to upload new files. I can also use Git and Compass without having to install them on the production server.
All Modular Everything
WordPress itself is a procedural application. I like to do modularise everything I add, as much as I can. An example of this is custom post types.
I previously used a plugin called Custom Post Type UI (CPT UI) but a recent update brought bugs and a lot of problems on some of my sites. Another problem I had with this plugin is that it stores custom post types in the database. This means they cannot be version controlled, as well as adding extra MySQL queries – never a good state of affairs.
Now I have created a BasePostType class, which contains the default set of options I would normally use. Now, when I want to create a post type I can just create a new class extending this one. For example, I could create class PortfolioPostType, which extends BasePostType, and now I have a new post type with little overhead and no database queries.
Recently I have moved to modularising by CSS (Cascading Style Sheet) too, with help from Compass.
With Compass, I like to make a CSS file for each different section or template of a website. For example, I will have a header css file, one for the footer, one for archive pages, etc. Now I just need to include these files in my main style sheet and Compass will compile all these files into a single style sheet. When I’m ready to move to production, I can simple minify this style sheet and everything is set to go.
This workflow makes it a lot simpler to find style definitions when additions or edits are required, and makes cascading the style sheets a lot easier in my mind – no more !important definitions. By making the site layout as mobile as possible from the start, it drastically reduces the size of the development style sheets, which are now a third or half the size they were before I adopted this workflow. They are much easier to maintain and quicker on the download, too.
I am just getting into git flow but I find that it helps me to focus on a single task at a time, rather than editing a bit of index.php, then a bit of the stylesheets, then a bit of single.php, etc. I create a feature branch for either a template or a site feature and don’t close the branch until it is done.