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.
Latest blog posts
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.
If you haven’t heard, Liquid Web is now the first company offering Managed WooCommerce hosting, which is a huge step forward in the world of WordPress-oriented e-commerce. As a result, I’ve been spending a lot of time over the last few weeks working on WooCommerce extensions that help improve the experience and performance of WooCommerce.
One of the main WooCommerce extensions I’ve been working on is WooCommerce Custom Orders Table, which takes the WooCommerce 3.x CRUD concept to its next logical point: storing order data in a custom, flat table instead of scattered throughout post meta. Mindsize worked with other members of my team at Liquid Web to build the initial version of the plugin, then I came in to fix a few bugs.
Last year, I decided to put some money towards upgrading to a Roland TD1-KV electric drumset, the entry model to their “VDrum” line. I had outgrown my old Simmons SD Xpress II kit (a Black Friday deal from a few years ago) and was excited to get something closer to “real” drums without the volume of an acoustic kit. I was also dealing with a cracked hi-hat on the old, discontinued kit, so I figured it was time.
The drums are fantastic, but after a few sessions, one thing kept bugging me: the hi-hat — a Roland CY-5 cymbal — kept spinning as I played. Nearly half the cymbal is covered in a rubberized pad, which helps mute the sound, provides a better response, and protects the plastic underneath. When I have to adjust the cymbal half-way through a song, that doesn’t make for the best playing experience.
Latest Blog Posts
- Using user-customizations.sh in Laravel Homestead
- Streamlining your test suite with PHPUnit Data Providers
- Quick Tips for New Speakers
Follow me: @stevegrunwell
- Portland, I’ve a blast. San Diego, I’m on my way for #WavePHP18!
- RT @altEPASmrtGrwth: It is rare that a public figure is able to cram so much that is wrong with America into a single sentence. Let's unpac…