Purge Old Slug Redirects

When the url of a published post is updated in WordPress, the previous url slug is saved into a meta key called _wp_old_slug and a 301 redirect is created automatically. In most cases this is exactly what you would want to happen, but there are rare cases where it can cause a problem.

I hit an odd edge case when upgrading to WordPress 4.4 on WP Engine. At some point the slugs for two WooCommerce products had been swapped, so the _wp_old_slug for ‘product-1’ was ‘product-2’, and ‘product-2’ was ‘product-1’. This should have caused an infinite redirect immediately, but for some reason those rules were ignored until the WordPress 4.4 upgrade. (more…)

Limit Search Form to Specific Post Types

If you’d like to limit the search form on WordPress site to specific post types globally, there’s and easy way to do that:

// Change search function globally to search only post, page and portfolio post types
function prefix_limit_post_types_in_search( $query ) {
if ( $query->is_search ) {
$query->set( 'post_type', array( 'post','page', 'portfolio' ) );
return $query;
add_filter( 'pre_get_posts', 'prefix_limit_post_types_in_search' );

But let’s say you want to have a specific search form search limited to one post type, but allow other search forms to search all post types?

Most tutorials I’ve run across suggest that you re-create all the search form markup and then add a hidden input to the form like this:

/* Hidden input field that can be added to search form */
<input type="hidden" name="post_type" value="portfolio">

You can then conditionally load that hidden field on the specific templates where where it is needed.

However, if you’re using get_search_form() and don’t want to completely replace all the search form markup, an alternative would be to do a string replace before outputting the form:

// Output a search for that only searches portfolio post types
$search = get_search_form( false );
$find = '</form>';
$replace = '<input type="hidden" name="post_type" value="portfolio">' . $find;
$search = str_replace( $find, $replace, $search );
echo $search;

For more reading on how this filter works, you can read the great inline docs in the WordPress codebase itself.

Better Blockquotes

WordPress has a button in the editor for adding blockquotes to a post. But what if an author wants to add a citation? Unfortunately, it’s not possible without a little HTML knowledge.

This is a problem I’ve thought about a bit when designing DevPress themes (what markup should I be styling for?), but it’s also come up on a few client projects recently. Citations are a pretty common use-case, and it would be great if they were easier to add.

My solution was to build a plugin that replaces the existing TinyMCE button for blockquotes with an enhanced one. (more…)

Command Line PHP Script for Zendesk API

Command line scripts can be excellent tools for fetching and quickly parsing data from an external API.

I recently wrote a script that allows you to search Zendesk tickets for a specific query term, and then returns a list of all associated e-mails. It’s something that’s impossible to do through the Zendesk UI (without a ton of clicking and copying), but really useful.

I thought I’d share it as a Gist in case anyone else might find it helpful.

Responsive Image Best Practices?

At 10up we have a guidebook of engineering best practices that all our teams follow. Now that responsive images finally have good browser support, we’ve been trying think through best practices with responsive images.

Some questions:

  • Is there a “best practice” for sizes to generate?
  • Should all images be generated at multiple sizes and updated with srcset values?
  • How will using srcset impact page weight (i.e. worth the effort)?

My initial assumption was “yes”, we should be using responsive images whenever we’re outputting a featured images. Using the “correct” size image can lead to huge performance gains.

But as I started to look at real world use cases, it got complicated. Let’s take a look at Twenty Fifteen as an example. (more…)

Programmatically Update Settings in Staging

When developing WordPress sites I generally have three environments: live, staging, and local. Since I like my staging environment to be a very close replica of production, I frequently overwrite the database and files in staging. This is especially true when working with a host like WP Engine that has one-click staging environments.

However, when the database is overwritten in staging, there’s a generally a few settings that still need to be different from production. For instance, with WooCommerce sites, I may need to deactivate SSL and put Stripe into testing mode.

Occasionally I’ll also need to deactivate certain analytics plugins or third-party API integrations like MailChimp.

After making these updates manually for months, I finally moved to a programmatic update routine for many of my sites. The code basically just checks which environment we’re in. If it’s one of the staging environments and the update script hasn’t been run already, it runs it. (more…)

Posts navigation