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?