I’m very excited to announce our next open source project; Suzie. If you haven’t been following our progress over the last few months we’ve been giving back to the community with Herbert — a WordPress plugin framework, and Peggy — a free DevOps platform.
So what is a starter kit? In the early days of Big Bite, it was just a repository encompassing our file structure and blank theme — the main value was the functions.php
file, which became larger and larger each project.
As we grew, so did our projects. I’m ashamed to say, but we fell into the trap of bloated repositories mostly consisting of media files. It was time to change, but big changes can cause problems, so we split the problem up into smaller chunks. What were the most common issues? What solutions did we implement often?
On the simple level it was managing database details across environments. It became common for other PHP projects to use .env
files to manage environment variables. Looking into how Laravel handled it, I was going to require a package (vlucas/phpdotenv), which meant it made sense to tackle using Composer as well. After building out my own version I stumbled across Bedrock, which is a well maintained project. Although it satisfied both environment variables and Composer, it didn’t solve some of our bigger problems of media management.
Deciding to move media files to a single location, allowing all environments to access and update them was a sensible route, especially as the amount of assets per project started to increase. To give you an idea of the problem, a recent project had 6,500 media files — that’s a lot for a repo to handle. At this scale, using WP Migrate DB Pro to sync assets is out of the question as it can take a long time to process. With hosting costs falling, the idea of hosting across multiple servers is becoming more common, so moving assets to a single location solved another one our issues. Originally we tried the Amazon S3 & Cloudfront Plugin, but it wasn’t long before we had a client that were unable to host assets externally, which meant we needed use SFTP. Over two days I wrote a small library called Sync (now part of Suzie), to use either S3 or SFTP for uploads. Having this option built-in makes the process the same for every project.
As developers we have 101 things to remember before a site goes into production and, unfortunately, there are often those one or two little things that end up happening on launch day. A good example of that is third-party email provider integration. Getting client account information for API services such as Mailgun or Mandrill is not something that should be left until the last minute. To prevent letting it creep up on us, we added it into our starter kit, so that the developers remember to enable it, and to request the client information during the project setup phase
Every client comes with their own set of requirements, whether it is nightly database backups, or highly secure nightly password resets. These kind of tasks need to happen at set times, and that means CRON jobs. Remembering which CRONs are set up can become messy to manage, so we built a Scheduler — based on Laravel’s — right into the starter kit to make this simple. The idea behind this is that you can set up one CRON job, and schedule as many tasks as you require.
And that brings us to the final piece of the puzzle. Even with S3 and CDNs, coupled with the best written front-end, WordPress can still benefit from a helping hand. Varnish Cache offers serious improvements in load times and amount of traffic the server can handle. It’s something you configure on the server, but Suzie has the option to enable clearing of the cache if a post is added, updated or deleted.
As we continue to offer more of what makes Big Bite tick we’d love to hear if you have any feedback, or any way we could improve — we’re never done learning. Anyway, it’s time to meet Suzie.