4 minute read
With every WordPress we do, there are a number of standard tasks that have to be repeated. To improve our efficiency, we have set up a standard sample WordPress build that we can use as a starting platform for every new WordPress project. This has several benefits for us: it is more cost effective, and we can pass these savings onto our clients; it will bring consistency to every build we do; we don’t have to refer back to any notes or remind ourselves how to do something; and it helps us to complete a project more quickly.
As we work in a collaborative industry, we are sharing the details of our sample WordPress build.
Source control
All of our work is source controlled, and we wanted to use phpdotenv (influenced by Laravel) to store all configuration details in one file, that is stored on local and external builds. By only storing this information on a server itself, and not in source control, we are helping to keep confidential information secure.
For our source control we use Git across all projects that enables us to track changes and manage team collaborations of projects more efficiently. We work towards a setup to manage development, staging and live variations in the construction of a website. This can start with a development version that has all the code in an expanded, readable format that our team can work with and understand more easily.
When preparing for going live this code is processed through our automated setup to compress and streamline pages, images and other supporting code. This provides for optimum performance and taking away code redundancy once pushed to the live server.
ENV
Defining the environment of the build (local, dev or live) produces the relevant debugging tools available to us. This will help us to solve problems faster.
We have pre-installed all plugins we typically use (such as for contact forms) and have configured them so they are ready to go. If we end up not using some of these plugins, we will simply remove them. Within ENV, we have also built in code for Google Analytics to generate itself when specified.
The configuration is set up so we can specify whether SSL is used, and if the answer is yes, the website automatically converts to HTTPS when refreshing permalinks (all the relevant code is inserted into the .htaccess file). As we know there is a growing need for an SSL and all our websites now use SSL so this helps streamline the process.
Sage
Sage is a starter theme for WordPress, which we use and adapt rather than using one the vast number of heavy and bloated ones with features that our clients may not need and may pose extra performance and security vulnerabilities. We like to build themes from scratch as much as possible so using Sage allows us to save time in the basic plumbing of a WordPress installation before moving onto the design and build of a website and its content architecture.
Within Sage we have already set up sample code for AJAX and post requests, for when we need to write some bespoke code to handle data. We also have a number of security improvements and clean-up scripts added in to keep the themes nice and tidy.
ACF
We use Advanced Custom Fields to make our WordPress interfaces even easier to use. Originally WordPress didn’t include a simple way to manage additional content fields on pages and posts, but thanks to the ACF plugin, and later the pro version, this is now more effortless. Virtually all our WordPress sites use ACF to offer our clients fully editable content on their website. Typically custom fields include anything from additional text content areas for pages to specific settings for different colour settings and layouts.
Most of our WordPress builds have global fields available, so we have that on default with sample fields available, should they be required.
This is a working build and is likely to evolve with every project we do. If you have any suggestions or questions about this, get in touch and we would be happy to talk it through with you.
