Display Posts or Pages Based on a Navigation Menu

For a site I’ve been working on there’s a section of “featured content” near the bottom of the home page. I was using a simple WP_Query to generate the markup, but after the third time updating the post IDs (because different content needed to be featured), I decided this needed to be managed somehow through the dashboard.

selections

The most common way to do something like this is generally to have a WP_Query that pulls from a specific taxonomy term (like a “featured” tag), however this doesn’t give you any control over the order of the posts. Also, in my case, I needed to display pages and a custom post type “guide” in addition to standard posts.

Thankfully, the WordPress Navigation Menus provide an easy built in interface that can be used to select content. So, I swapped my hardcoded query to pull Post IDs from a navigation menu instead. I thought it would be worth sharing the solution since this could be used in many types of situations: sliders, setting featured products for a specific template, or featuring content in a sidebar or footer. Continue reading

Theme Update Script for Custom Logo

I’ve been updating several of my themes to support the new custom logo feature that is being introduced in WordPress 4.5 (read about it here).

Most of my themes already had a logo option, so part of adding support for this new feature has been to build an update script to migrate the previously saved value (generally saved to the theme mod “logo”), to the new theme mod “custom_logo”.

I assume a lot of other theme authors will also be doing this, so I’m sharing my update code in case it can save someone a few minutes. Continue reading

Query by JetPack Related Posts

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

Background Images and the Customizer

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.

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

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

Customizer Control: Arbitrary HTML

Sometimes it’s really useful to be able to output HTML in the Customizer that’s not a label or description for a specific control. You may want to output a line break, an image, a button, or simply some additional text.

There isn’t a native Customizer control in WordPress to do this, but you can add your own custom control to output arbitrary HTML. This was a request for the Customizer Library, and the GitHub issue explains the thought process behind the code. Continue reading