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.
If you’re one of the thousands of developers attending CodeMash this week in Sandusky, OH, be sure to find our Director of Technology, Steve Grunwell (that’s me!), and say hello!
Friday morning, I’ll be giving a talk entitled Building for the PHP Command Line Interface at 9:45am in the Guava/Tamirand room(s). I’ve given this talk a few times before, most recently for Nomad PHP’s EU Chapter in December.
If you’d like to keep up-to-date with Engineering @ Growella, please be sure to follow our new engineering-focused Twitter account: @GrowellaEng!
We’ll be using the new Twitter handle to share posts from Engineering @ Growella, answer questions, collaborate on open-source software, and share great resources we’ve found as we build Growella.
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.
wp_enqueue_style(), respectively) is missing an explicit version number and, when such an asset is found, a version number is created dynamically.
Over Thanksgiving weekend (thus way before this blog got started), I wrote about assigning custom field IDs to Gravity Forms fields, which is crucial in reliably connecting Gravity Forms to third-party tools like CRM or lead generation services.
Welcome to the Engineering @ Growella blog!
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.