Latest blog posts
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.
AIf 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
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.
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.
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.
I’m not a professional speaker by any stretch of the imagination, but I do tend to make it to a non-negligible number of conferences each year, where I get up on stage for 45 minutes to an hour at a time and try to help people.
Lately, I’ve been trying to pay more attention to newer conference speakers, and trying to offer what little advice I feel qualified enough to give. This post aims to sum up some of the more common points.
Last week, my wife, daughter, in-laws, and I took a week long vacation to the west coast of Michigan. Bookended by two weekends in Grand Rapids (the second of which was centered around WordCamp Grand Rapids), we rented a cottage in Spring Lake, just outside Grand Haven, MI.
The trip started off well enough (I should mention that my in-laws and I get along well, and my father-in-law joined me a couple of years ago on my walk across Columbus), but things got rough once we arrived at the cottage. No, it wasn’t family drama, nor was the toddler to blame (though her “terrible twos” aren’t helping) — the coffee pot in the cottage was on its last leg.
The first morning, the coffee was…okay. I had brought some beans from Upper Cup Coffee (one of my hometown favorites), but the coffee pot had obviously not been well-maintained. The coffee maker itself took about 30min to brew a 12 cup pot (which is way too damn long!), and when we tried to make a second pot the coffee maker decided it’d had enough: the heating element stopped working, and no heat means no hot coffee (and a severe lack of cognitive function on my part).
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.
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.
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
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.