Steve Grunwell

Open-source contributor, speaker, and electronics tinkerer

Category: Code

A home sitting on a midwestern, prairie homestead.

Simplify Project On-boarding with Laravel Homestead

Despite working on Liquid Web’s Managed WordPress and Managed WooCommerce hosting products, a fair amount of the development work I do these days has very little to do with WordPress. In fact, my main project right now is using Laravel, and it’s the sixth Laravel application (depending on how you count projects) I’ve worked on in just under two years at the company.

Laravel’s an incredibly powerful application framework with a thriving ecosystem. Thanks to tools like Composer and Packagist, I have access to thousands of libraries, extensions, and utilities to help me build the best applications possible. Even out of the box, the framework has support for (among many other things) multiple database and caching engines, event-driven architecture, and websockets, giving me a strong foundation for building modern web applications.

Of course, incorporating multiple platforms and tools into a single application can make on-boarding new team members more difficult. How do you make sure they’re running the right versions of PHP, your RDBMS of choice, Redis, and more?

Continue reading→

An exposed lightbulb sitting atop a pile of books

Atomic Deployments from Scratch

Years ago, a mentor of mine introduced me to a Ruby-based server automation tool called Capistrano, and I immediately fell in love. Ready to deploy a new release? Rungit push && cap production deploy, then you’re done. Even better, Capistrano introduced me to what’s colloquially known as “atomic deployments” — checking out a full copy of the codebase and using symlinks to point to the new release for a zero-downtime deployment — which has since been my gold standard for deployment methods.

I continued to use Capistrano for a few years, until I started working on projects (and teams) large enough to justify a proper continuous delivery (CD) tool. Suddenly, building the application locally and pushing up with Capistrano became more complicated; at the same time, services like DeployBot began offering atomic deployments right out of the box, so it was easy to get up and running.

What about services that don’t offer atomic deployments as a default? I recently deployed a Laravel application via Codeship, where atomic deployments to a VPS becomes more complicated; here’s how I approached it:

Continue reading→

An assortment of patch cables connecting various components

Routing phone calls to volunteers with Twilio

In the past week or so, I’ve been working on a Laravel application that enables groups of volunteers to be added to a call tree; a phone number comes in, then gets routed to one of the active volunteers’ phone. A lot of the core functionality is there, but the app isn’t quite ready to release to the general public. There’s something of a time-crunch, however, as the main reason for building the application is to connect people who need rides to their polling places with volunteers in the days leading up to the critical 2018 midterm elections.

Here’s the concept: someone in need of a ride calls a Twilio number, which then rings up to ten (10) volunteers’ phones. Whomever picks up first gets the call, and they can work through arranging transportation.

Building the application has been an awesome introduction to telephony service providers like Twilio, which combine voice and SMS messaging with web applications. Using Twilio’s TwiML (Twilio Markup Language), I can write simple XML documents to describe how to respond to different messages. I have a lot of features planned as far as routing calls more intelligently and letting volunteers mark themselves as unavailable, but I wanted to get the bare-bones TwiML out to the public as far ahead of Election Day as possible.

Continue reading→

A pile of LEGO bricks spread out across a hardwood floor

Understanding the functions.php file in WordPress

If you’re just getting started with WordPress, there’s likely a lot of new terminology being thrown at you. Beyond fundamentals like “themes” and “plugins”, you’re probably seeing “actions”, “filters”, and a ton of code snippets with instructions like “just add this snippet to your functions.php file.”

Let’s take a step back and look at WordPress’ functions.php file; what it is, where it lives, and how it works. Once we understand those points, we’ll learn how to add snippets to our WordPress sites without having them accidentally overwritten.

Continue reading→

A home sitting on a midwestern, prairie homestead.

Using user-customizations.sh in Laravel Homestead

Today, Laravel Homestead maintainer Joe Ferguson tagged version 7.16.0 of the Laravel Homestead library. The announcement tweet includes “Adds support for user-customizations.sh” which, probably doesn’t mean much to anyone who hasn’t followed Pull Request #932 over the last few days. As the person who opened that particular PR, I figured it might be nice to document the motivations.

Continue reading→

A basket full of assorted vegetables

Streamlining your test suite with PHPUnit Data Providers

In every testing talk I’ve attended (or given), there’s one stand-out feature that often has the audience saying “whoa, I had no idea you could do that!” No, it’s sadly not “hey look, you can reliably build quality software with a much lower chance of defects or regressions!”, but rather the inevitable use of PHPUnit’s Data Providers.

With Data Providers, our test suite can become more readable and maintainable while making it trivial to add new testing scenarios. Best of all? PHPUnit ships with Data Providers right out of the box.

Continue reading→

Two small monkeys on a tree branch

Automatically Install PHP’s Runkit7 via Composer

A WordPress plugin I’ve been working on recently needed to be able to accept configuration in a few different ways: users should be able to define a constant in the wp-config.php file or fill out a form within a settings screen. If the constant is defined, the setting screen should be aware of that and hide the setting, since the constant should take precedence.

This is a pretty common pattern in WordPress plugins, but it can get rather tricky to test; by design, once a constant is defined in PHP, you shouldn’t be able to change its value. PHPUnit has ways to work around this by running tests that define constants in separate processes, but this can seriously impact the performance of your test suite. Furthermore, the WordPress core test suite is pretty tightly coupled, so it doesn’t like when tests are run separately.

Continue reading→

A Crash-course in PHP Namespaces for WordPress Developers

Way back in 2009, PHP 5.3 was released to the world and with it brought support for PHP namespaces — a way of easily separating your code from other developers’ code, which has since become the de facto way of encapsulating functionality across the PHP ecosystem.

With namespaces, multiple packages could use the same class and function names without conflict, because each one would operate in their own PHP namespaces. Unfortunately, many PHP developers who focus on WordPress development may be in the dark on this extremely useful language feature.

Continue reading→

The WordPress TinyMCE editor, modified so the block formats read "put whatever you want in here"

Customizing the WordPress TinyMCE Block Formats

This morning, I was scrolling through Twitter as I tried to wake up (as I do most every morning), when I came across a tweet from the wonderful Carrie Dils asking how to customize the WordPress TinyMCE block formats.

“That’s funny,” I thought to myself, “I used to do those customizations on client sites all the time. In fact, some of those customizations are even in my (now-abandoned) WordPress Starter Theme repo on GitHub!

I was able to throw together a quick gist to demonstrate how to pull off a <code> block format, but doing so reminded me how much of a struggle it was to figure that all out to begin with. In the interest of helping everyone else configure TinyMCE, here’s a quick breakdown

Continue reading→

A pile of LEGO bricks, ready to be constructed into something great (and blue).

Two new micro-libraries for WordPress

Last week, I found myself with two consecutive nights where my wife was busy with client work, so I found myself with some time after we put the toddler to bed. I had also had a stressful few weeks at work, where the things I was supposed to be working on kept getting de-prioritized so I could jump in and help other members of my team. Of course, ever-shifting priorities is nothing new for me (considering all but the last year and a half of my career has been in professional services), but it can still get frustrating when you just want to ship something.

A big part of what I do on a day-to-day basis is centered around WordPress. I work on the product team behind Liquid Web’s Managed WordPress and WooCommerce hosting platforms, and even when I’m writing Laravel applications they’re ultimately designed to support WordPress.

The more you work with WordPress, the more you see the same patterns repeating themselves. Registering scripts and styles, nonce verification, and custom meta boxes are things I can do in my sleep. Dig into third-party code and see yet another written using a Singleton pattern. Maybe the plugin author would appreciate if you refactored it to use namespaces, but of course there are no tests.

Sometimes you need a break, to just dig into something small enough that you can knock it out in a night or two but useful enough that you’re not coding for the sake of coding. That’s what I’ve done with two new micro-libraries: WP Cache Remember and One-Time Callbacks.

Continue reading→

Page 2 of 7

Be excellent to each other.