Tag: WordPress

Moving on from always moving on

Five years ago, I was unemployed and bored, and somehow happened upon the idea of a WordCamp. As luck would have it, there were plans underway for one in Boston, and help was needed. With an abundance is free time, I gladly volunteered–a decision that led to a job and my current career.

The last five years have been a wild and often-surreal experience of travel, growth, and so much WordPress. Boston has been my base through this time, and New England where I’ve always called home, but soon that changes.

For more than two years now, I’ve been a nomad in a long-distance relationship, but I’ll soon drop both descriptors. Chris and I are moving to Los Angeles this summer.

I love traveling and the nomadic lifestyle, but I’m ready to settle down with my boyfriend and move on with our life together.

Redis Object Cache for WordPress, the Accidental Effect of PHP 5.5

Last week, I went a little upgrade-crazy with the VPS that hosts this site. With SPDY 3.1 support in nginx 1.5, I upgraded. I also bumped PHP from 5.4 to 5.5.

The latter change is significant because PHP 5.5 drops support for APC, and I was using APC for both opcode caching at the PHP level and object caching at the WordPress level (thanks to Jaquith’s plugin). Since I’d lost my object cache, I’d also lost my page cache because I was using Batcache. Nice job, Erick.

Almost a year ago, I contributed two small changes to Eric Mann’s WordPress Redis Backend plugin. With Redis already running on my VPS for reasons unrelated to WordPress, it seemed an obvious choice over competing persistent caching options.

I spent some time updating Eric’s plugin (see https://github.com/ethitter/wordpress-redis-backend/commits/master for the fun I’ve had) and sent a massive pull request back with my changes. I’ve been using the plugin for a few days now without incident, though I wouldn’t rush to switch over just yet unless you’re adventurous. I’d watch Eric’s repo if you’re interested in what comes of my efforts.

WP_Rewrite Isn’t As Scary As You Think–WordCamp Vancouver 2013

I just finished my presentation at WordCamp Vancouver 2013 entitled “WP_Rewrite Isn’t As Scary As You Think.” My intent was to reduce the fear surrounding WP_Rewrite in the hope that more developers will be able to leverage the API in their code. I described my talk thusly:

Everyone wants pretty URLs on their sites, and WordPress provides a powerful system to support this. Behind the magic of the Permalinks settings page is WP_Rewrite, an API terrifying to many developers.

Like most of WordPress, the Rewrites system isn’t limited just to internal use, and understanding how the API works lets developers build powerful tools atop the platform. We’ll start by discussing what happens when you set a permalink structure through the dashboard and how WordPress uses that to query for content. We’ll then explore how you can add custom rewrite rules, both with and without an understanding of regular expressions. By the end of this session, you’ll know what actions and filters are available to tweak rewrite rules, how endpoints enhance your code, and how you can leverage this powerful API to deliver a better user experience.

Proposed as a 45-minute presentation, I was offered a shorter slot instead. As such, the talk isn’t as in-depth as I described it, but it still provides a good primer for those unfamiliar with WP_Rewrite.

Slides from the talk are available at http://slides.ethitter.com/wp-rewrite-isnt-scary/. I’ll embed the video as soon as it’s available.

Year in Review

I experienced two notable milestones last week. It’s been a year since I joined Automattic, and I’ve been without a permanent home for the same duration. During this year, I’ve visited a new country, met innumerable incredible people from both Automattic and the WordPress community, attended fourteen (14!) WordCamps and spoken at seven (7!), and taken over as lead of Team Custom. I’ve flown in excess of 100,000 miles and spent at least seven months away from my Boston-area home base.

What a great experience I’ve had and a wild year it’s been! I have no desire or intent to settle down any time soon, and going forward, will be posting more about my nomadic experience  at Get Transient along with Siobhan McKeown,  Hanni Ross, and guests.

Disable Jetpack’s Photon module in specific situations

I receive a lot of interesting questions about the Photon module in Jetpack. Occasionally, users would like to disable Photon for certain requests, such as when a plugin or theme calls one of WordPress’s image functions (wp_get_attachment_image(), wp_get_attachment_image_src(), or anything else that ultimately calls image_downsize()).

While the Photon module does include filters to disable it for each individual image requested (see here and here), there are situations where one may wish to disable Photon regardless of the image being requested, such as when a certain widget retrieves an image from WordPress’s media library.

Doing so is relatively simple, but a bit obfuscated because the Photon module is written as a PHP class. The snippet below demonstrates how to do so, and is made possible because the Photon module is implemented as a singleton.

$photon_removed = remove_filter( 'image_downsize', array( Jetpack_Photon::instance(), 'filter_image_downsize' ) );
// Call wp_get_attachment_image(), wp_get_attachment_image_src(), or anything else that ultimately calls image_downsize()
if ( $photon_removed ) {
	add_filter( 'image_downsize', array( Jetpack_Photon::instance(), 'filter_image_downsize' ), 10, 3 );
}

The code on line 1 should appear immediately before the function call that shouldn’t have Photon applied, and lines 5 and 6 should appear immediately afterwards to ensure that Photon is available for any subsequent calls to image functions.

Grab the snippet from https://git.ethitter.com/snippets/1.

Aside – if you’re curious about using singletons in WordPress, check out Eric Mann’s post on the subject: The Case for Singletons in WordPress.

Authy for WordPress? Jetpack Photon for NextGEN Gallery?

I’ve been busy this week writing some new plugins.

First, I released Jetpack Photon for NextGEN Gallery, which extends the WordPress.com CDN capabilities in Jetpack to galleries built with the NextGEN Gallery plugin. I built this one after building Jetpack’s Photon module and noticing that NextGEN Gallery images weren’t benefitting from the Photon CDN.

Then, I enabled two-factor authentication on my CloudFlare account. CloudFlare uses a hosted service, Authy, rather than a local codebase, to handle the verification process using an installed app and a hosted API. Surprisingly, there wasn’t a WordPress plugin that integrated the service, but there is now: Authy for WordPress. It’s in use on this site, in fact.

Both plugins are available in the WordPress.org plugin repository. Development can be found at http://github.com/ethitter/Authy-for-WP and http://github.com/ethitter/jetpack-photon-for-nextgen, respectively.

All You Ever Wanted to Know About Automattic

Hurricane Sandy disrupted life along much of the east coast, but couldn’t stop the Boston WordPress meetup. We couldn’t meet in person, so we used a Google Hangout instead. I spoke for around 90 minutes about all things Automattic.

Here’s the video:

https://www.youtube.com/watch?v=xdiUuGlAE08

And the slides:

The case for another action in WordPress

In my experience, WordPress’ power lies in its actions and filters, of which there are many. Still, there are situations where an action or filter would be useful, but doesn’t exist, and such represents an opportunity to further extend WordPress’ flexibility.

One example is WordPress’ handling of 404s. Currently, WordPress parses a URL into query arguments, executes the query, then attempts some additional lookups if the original query doesn’t return any results. If these steps fail, then a 404 header is sent, and the theme’s 404 template is loaded.

The opportunity for a new action arises in situations where data may be available to help WordPress locate the correct post. For example, if a site migrates from another CMS, postmeta may contain some identifying information that can aid with redirecting requests for old URLs to their new addresses. I saw this many times when migrating clients from Moveable Type or a custom solution to WordPress.com VIP; often, we would store some unique identifier as postmeta. Our use of this postmeta, unfortunately, was less than ideal owing to the actions available to us.

Returning to the URL parsing mentioned previously, the latest action available before the 404 status headers are sent is parse_request. This forced us to write redirection handlers that fired for every request, even if the request represented a proper WordPress URL and would return a result from the database naturally. In some cases, simply checking for a file extension (aspx or html, for example) would be enough to short-circuit the postmeta checks, but many times, such discernable patterns didn’t exist. In these latter cases, many meta queries and cache additions were used to limit the negative performance impact our code introduced.

The solution to this problem is rather simple: add another action to WordPress. As I learned today (after submitting a new ticket), I’m not the first person to encounter this situation and think that a new action or filter could help; within a few hours, my ticket was closed as a duplicate of two others (#10722 and #11312). Now, #10722 will host patches for this issue. My solution is a simple one-line addition (two, if you count the preceding comment) in the WP class’s handle_404() method.

With this addition, rather than using parse_url to determine if a postmeta check (or other lookup) is needed, the pre_send_404_header action could be used. By the time this new action fires, WordPress has tried all of its magic and is ready to send up the “I can’t find what you’re asking for” flag. What better place to let developers intercede and potentially deliver the user to the content he or she requested?