Posts

Happy to announce that this afternoon we rolled out the “prime” release of Growella.com!

While we’re proud of what we’ve built so far, we’re well aware that we have a long way to go, both from a content and engineering perspective. We’re already looking at ways to speed up site performance, create more interactive content, and design the best user experience we can.

WordPress has had the concept of page templates for a long time, but it was only in the last major release (4.7) that this feature was extended to support all post types. The timing couldn’t have been better, as Growella makes use of custom, named page templates for different types of content (regular articles, “Your Job is Whaat?!?” episodes, and more).

Being able to change the page template being used is great, but often a specialized template requires some specialized post meta to go with it. How can we show or hide different custom meta boxes based on the current template? I’m glad you asked!

When I first decided to join Growella as the Director of Technology, one of the most appealing parts was the utter lack of technical debt; after all, if you haven’t built anything yet, you probably don’t have a whole lot of technical debt to worry about!

I decided that we would set out from the start to do things “right” (with “right” being a relative term, based on my past experiences and personal opinions on software development), and one of the first things I wanted to introduce was a Continuous Integration (CI) and Continuous Delivery (CD) workflow.

Growella uses DeployBot to handle deployments, but we're also using Gulp to run webpack, Sass, and other compilation tasks, then building a dist/ directory that acts as the root of our deployment. This ensures we're only deploying the files we need on production, while leaving out development assets.

We're also building Growella as a twelve-factor application, so we're using Composer and WPackagist to pull in our dependencies, which is super easy to do with DeployBot. We're even able to cache the composer install, ensuring it's only run when something has changed in composer.json (for instance, installing/upgrading a plugin).

On paper, this looks great: we're only running Composer when we need to, and we're able to prepare a nice, packaged version of the site for delivery to the target server, which is taking advantage of DeployBot's atomic deployment pattern.

Here's the rub: it was slow. Unacceptably slow, taking 10-15min to deploy a WordPress site.

We're proud to announce that we've published our first plugin to the WordPress.org repository: Dynamic Asset Versioning.

Dynamic Asset Versioning was designed with one goal: prevent stale CSS and JavaScript from being served in a heavily-cached production environment. It accomplishes this by detecting when a script or style (registered and enqueued using wp_enqueue_script() or wp_enqueue_style(), respectively) is missing an explicit version number and, when such an asset is found, a version number is created dynamically.

This blog is designed to be a place to get technical about all of the things that we're building at Growella. The content primarily comes from Growella's engineering team, but there may be the occasional post from other members as well.