Steve Grunwell

Open-source contributor, speaker, and electronics tinkerer

Category: Code

Writing WooCommerce Extensions with Confidence

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.

Continue reading→

An antique hour glass, resting on a rocky beach

Exclude Dependencies from Time Machine Backups

If you’ve used a Mac in the last decade or so, you’ve likely been prompted to configure Time Machine, macOS’ built-in automated backup solution; simply connect your backup disk (or use certain network attached storage devices) and Time Machine will automatically make incremental backups of your machine. In the event that your computer’s lost/stolen, its hard drive is corrupted, or you simply deleted that super important file, Time Machine makes it easy to restore your computer’s previously healthy state.

Where Time Machine is less convenient is in the case of developers: modern development practices often rely on dependency management tools (e.g. Composer, npm, etc.) to pull in third-party dependencies. Instead of including full copies of external libraries, developers can say “my application relies on package N at version X.Y.Z”, and the dependency manager can download the necessary code as a build step. This is great for keeping third-party assets both versioned and out of version control, but for the developer working on multiple projects it poses a bit of a problem: you end up with a ton of project dependencies on your machine!

Continue reading→

Egyptian pyramids

Deeper Testing with PHPUnit Markup Assertions

In a perfect world, every piece of software would have automated tests. As soon as we change a line, we as developers would know what, if anything, broke in our application and where we need to look to fix it. Unfortunately, we don’t live in a perfect world, so we get by doing what we can.

Still, we can look to our image of the perfect world and draw from it, molding and shaping what we do have to closer resemble what we’ve been longing for.

Continue reading→

Still from the 2003 film Lost in Translation, starring Bill Murray and Scarlet Johansson

Finding Missing Laravel Translations

Out of the box, Laravel ships with a simple-but-intuitive localization system: when you call trans('some.key')and Laravel will automatically replace it with the value of “key” within resources/lang/{locale}/some.php. Laravel translations also accept placeholders and can handle pluralization, making it extremely easy to build applications that are localization-ready.

Of course, building an application that’s localization-ready means the Laravel translations need to be filled out to begin with. It’s far too easy to get on a role writing several views, then miss a string or two when creating the localization files. Heck, even the comments in the Translator class within Laravel itself doesn’t seem to think much of it:

If the line doesn’t exist, we will return back the key which was requested as that will be quick to spot in the UI if language keys are wrong or missing from the application’s language files. Otherwise we can return the line.

Unfortunately, I’ve had one too many apps go live (or in front of clients for demos) with a string or two missing a translation. Finally, I decided to do something about it.

Continue reading→

A home sitting on a midwestern, prairie homestead.

Developer-specific Laravel Homestead Configurations

Since joining Liquid Web, I’ve gotten to revisit Laravel, my favorite application framework for PHP. I’m still doing plenty of WordPress work, of course, but when building web applications — especially those with robust APIs — building atop Laravel makes so much more sense than shoehorning it into a WordPress environment.

In their mission to make application development delightful, Taylor Otwell and the other Laravel developers (including my friend Joe Ferguson) maintain Laravel Homestead, a pre-packaged Vagrant box for Laravel development. While the environment can be installed globally, Laravel Homestead can also be installed on a per-project basis, ensuring each application has its own, dedicated virtual machine.

Continue reading→

My Laravel Tests were Failing because of my App URL

In my role as Senior Software Engineer at Liquid Web, I’ve gotten to get back to my roots of not only doing WordPress, which has been great. In particular, I’m getting back into Laravel, getting to build real web applications in an environment that makes testing a breeze (aside: if you haven’t checked out Adam Wathan’s Test Driven Laravel course, I cannot recommend it enough!).

I ran into an interesting problem today, however, when I updated the APP_URL variable in my .env file: running my [previously 100% green] test suite, I was getting random errors and failures within my feature tests that I hadn’t been seeing before. Controller actions weren’t responding properly, model relationships weren’t always behaving, and redirects following actions were hit-or-miss.

Continue reading→

Screenshot from ExploitBox's CVE-2016-10033 video

Keeping WordPress Secure

A few days ago, a YouTube video was passed around a few Slack teams I’m a member of showing a proof of concept of an unauthenticated remote code execution vulnerability in WordPress core (in other words, a way for people to execute arbitrary code on your server, which is obviously bad). The video, posted by Dawid Golunski of Legal Hackers, purported that the vulnerability was exploited against a clean installation of WordPress with no plugins and only the default configuration.

This morning, Dawid’s new site, ExploitBox, posted details about the vulnerability. In short, by spoofing a request’s “Host” header, it’s possible to trick WordPress into sending a password reset email with a return path pointing to a domain you control.

The author goes on to hypothesize that if an attacker were to first overload the target’s inbox with large messages (effectively filling it to the point that it couldn’t hold more messages), this would cause the mail host to “bounce” (reject) the message, returning it to the sender (the attacker). Assuming the returned email contained the body of the original message, the attacker now has the link that will allow them to change the user’s password.

Continue reading→

The Tuletornen residential project in Sundbyberg, Sweden

Schemify: Automatic structured data for WordPress

It’s been several months in the works, but I’m thrilled to announce that my latest WordPress plugin, Schemify, is now available on WordPress.org!

Schemify is designed to automatically generate Schema.org-compliant structured data for WordPress, with full customization capabilities through actions and filters. With Schemify, you can rest assured that Google, Bing, and other search engines see your posts as articles, pages as webpages, and ensure that your authors get the credit they deserve.

Best of all? Schemify is able to inject structured data into your site without you having to change your markup!

Continue reading→

A series of links in several chains

Using symlinks for WordPress MU plugins

If you haven’t run into them before, WordPress Must-Use (MU) plugins can be a great way to say “no, seriously, my WordPress site needs this plugin in order to function”. Other times, MU plugins may be used to activate required functionality that site maintainers don’t want the site editorial team to have to worry about (for example, caching plugins like Batcache).

There are a lot of things that can be done with MU plugins, but there’s one major limitation right out of the gate: WordPress MU plugins cannot run in sub-directories.

Continue reading→

Custom field IDs for Gravity Forms

If you haven’t had the chance to work with it before, Gravity Forms is pretty fantastic. I was first turned onto it a few years ago while I was at Buckeye Interactive, where it was a mainstay across most of our client sites. Besides presenting an easy-to-manage interface for building forms, the plugin also makes good use of the WordPress Plugin API (thus making my life way easier) and has a vibrant ecosystem of official and unofficial add-ons.

One area where Gravity Forms could stand to improve, however, is making it easier to identify fields. Let’s say, for example, we have a form where we’re collecting a name and an email address; outside of assuming that the regular text field is the name and the input[type="email"] is the email address, Gravity Forms doesn’t really have a straight-forward way to identify fields when you’re doing extra work with submissions (like sending them to a newsletter or a CRM system).

In my new role as Director of Technology at Growella, one of the first things I needed to figure out was how we could reliably map Gravity Forms submissions into third-party tools.

Continue reading→

Page 3 of 7

Be excellent to each other.