At times, it’s helpful to be able to create a secure, private family blog for sharing updates with close friends and family without posting to more public social media channels.
There are any number of reasons you might do this: sharing updates about a new child, a new city, or — in our family’s case — a new adventure.
If you’ve spent much time on GitHub, you’ve probably come across repositories with green badges that look like this:
A lot of repositories will have these badges/shields, as they indicate that the last run of the Continuous Integration (CI) pipeline for this repository “passed” (e.g. everything is working as expected).
Now, Continuous Integration can mean a lot of things: maybe the project has a wealth of well-written tests that are all passing, or the simply that coding standards are all up-to-par. No matter the coverage level, this green badge indicates to potential users of your code that it satisfies the quality checks you’ve put in place.
Better yet, once we have a Continuous Integration pipeline in place, we can make it a prerequisite for pull requests to be merged. If you’re tired of PRs that don’t respect your project’s coding standards, ignore PHP compatibility rules, or otherwise produce lots of overhead, automating the high-level testing can save you lots of time.
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.
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.
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.
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!
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.
Be excellent to each other.
