DeployBot

By Devin

I’ve started using DeployBot to manage a lot of my code deployments. It works great if you develop custom themes for clients and keep your repositories in hosted version control (like GitHub or BitBucket).

I generally work in a “staging” branch (when I’m working solo), which auto-deploys to the staging environment. I trigger deploys to production with commit messages to the master branch, i.e. “Version 1.2.2 [deploy production]”.

One really nice feature Deploybot added recently is the ability to run build tasks on a cloud server before transferring via SFTP to the final destination. This means you can keep generated assets (sass files, minified js) out of your git repos, which keeps the committed changesets cleaner and avoids generated code conflicts when working with teams.

The only issue I had when using build tasks with deployments was this occasional error “DeployBot failed to establish or maintain connection to your server.” I found if I added “rm -rf node_modules” as the last step in the build, that resolved the issue. It also sped up the deploy and kept those files off the destination server.

If you’re interested in how other WordPress agencies/freelancers use Deploybot, this post highlighting Reaktiv is also a nice resource.

Query by JetPack Related Posts

By Devin

A site I’ve been working on had a list of “recent posts” displaying underneath the main content. The feature used a WP_Query loop to display an image, title, and author link for each recent post.

The client wanted to update this to use a “related posts” algorithm instead, but didn’t want to change anything else about the design or display. That got me curious if it would be possible to fetch the IDs from the Related Posts module in JetPack, but then run them through WP_Query to output the existing custom markup. Continue reading →

How to Overwrite a Theme

By Devin

If you’re trying to install a theme update manually, you might get this message:

Installing the theme…
Destination folder already exists.
Theme install failed.

In order to update the theme, you’ll actually need delete the current version before you can upload the new one.

Here’s how to do that:

  • Go to “Appearance > Themes”
  • Temporarily switch to an alternate theme
  • Then, click “Theme Details” for the theme you are trying to replace
  • Click the “Delete” link in the bottom right
  • Now click the “Add New” button and upload the new theme version
  • Switch to the new version of the theme you uploaded

Background Images and the Customizer

By Devin

The WordPress Customizer does not have a built-in control for setting background images. The background feature simply consists of four different controls:

  • background_image (WP_Customize_Background_Image_Control)
  • background_repeat (radio)
  • background_position_x (radio)
  • background_attachment (radio)

For this feature, the Customizer also loads javascript that reveals the radio fields once an image has been uploaded. And on the front-end, inline styles are used to apply the background image to the body tag.

If a developer wanted to build additional background image options, the simplest option would be to take the same route: register four settings, load four controls, add custom javascript to show/hide fields if an image is set. Repeat as needed.

However, I started experimenting with a single control and thinking through how that could be implemented.

Issues with Current Implementation

Trac is a great place to find feedback on a particular WordPress feature, and there were a number of suggestions for background enhancements:

Prior Art

The Make Theme by Theme Foundry implements some of these suggestions, including UI changes:

make-theme

The Kirki Toolkit also implements a background control, which supports repeat, size, attach and position.

Custom Background Control

I haven’t completely finished the custom background control I’ve been working on, but I feel like it’s time to share and open it up for collaboration. Here’s what it does now:

  • A single control generates all the field markup (image, repeat, size, attach, position)
  • The control also saves an attachment ID if a setting is defined (making it easier to generate alternate sizes)
  • The control automatically loads the javascript to hide/show the select fields

At the moment, six settings need to be registered (with their defaults and sanitization) if all the fields are going to be displayed. This still feels like a lot of syntax and I’d like to simplify it further- perhaps by saving all the data into a single serialized array for the theme_mod or option setting that is registered.

It also doesn’t address cropping, alternate UI ideas, or retina- mainly just because I haven’t had a chance to explore it yet. But it does have support background-position-y (added to the position field) and background-size (new select field).

I’d love for other people to take a look at this control and give me any thoughts, feedback, or pull requests. You can find the Custom Background Control on GitHub along with all its documentation.

Check out the project here.

Unit Tests for WooCommerce Extensions

By Devin

I am completely new to PHP unit testing, but I decided it was time to learn after discovering a critical bug in a small WooCommerce extension I had built for a client.

The extension I built added a feature that allowed administrators to limit specific coupons to new customers only. I had done some manual testing and made sure that new customers could use the coupon and existing customers could not. But there was a logic bug I missed that prevented existing customers from using any coupons, even ones that did not have the “new customer” restriction.

After finding the bug, I knew there were several use cases I would need to check every time an update was made to the plugin:

  • New customer should be able to apply a coupon
  • New customer should be able to apply a coupon with a “new customer” restriction
  • Existing customer should be able to apply a coupon without a “new customer” restriction
  • Existing customer should *not* be able to apply a coupon with the “new customer” restriction

Obviously, checking this manually each time would be rather tedious- which is why I turned to unit tests. Continue reading →

Purge Old Slug Redirects

By Devin

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. Continue reading →

Limit Search Form to Specific Post Types

By Devin

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' );
view raw limit-search-to-post-types.php hosted with ❤ by GitHub

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">
view raw limit-search-to-post-types.php hosted with ❤ by GitHub

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:

<?php
// 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;
?>
view raw limit-search-to-post-types.php hosted with ❤ by GitHub

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