How to Change the Featured Image Labels

When creating a site for a client or creating a plugin, I’ve found its helpful to customize things as much as possible to the intended usage. This is especially important for client work since most clients have an internal language, or terminology they use for things. In the case of Featured Images, the site or plugin might be using the featured image differently than how one might use it on a news or blog post.

I’m currently writing a plugin with a custom post type and using the featured image as a headshot for an employee. While “featured image” may work fine, “headshot” is more specific and makes more sense in this context. I haven’t been able to find anything recent about how to change the labels on the existing Featured Image metabox. The most commonly referenced code only works some of the time. Specifically, when one removes a featured image, the label for the link changes back to referencing “featured image” instead of the customized label.

I dug through the core and found the post_type_labels_{$post_type} filter, which was added in version 3.5. This filter makes customizing the featured image labels super easy:

/**
* Changes strings referencing Featured Images for a post type
*
* In this example, the post type in the filter name is "employee"
* and the new reference in the labels is "headshot".
*
* @see https://developer.wordpress.org/reference/hooks/post_type_labels_post_type/
*
* @param object $labels Current post type labels
* @return object Modified post type labels
*/
function change_featured_image_labels( $labels ) {
$labels->featured_image = 'Headshot';
$labels->set_featured_image = 'Set headshot';
$labels->remove_featured_image = 'Remove headshot';
$labels->use_featured_image = 'Use as headshot';
return $labels;
} // change_featured_image_labels()
add_filter( 'post_type_labels_employee', 'change_featured_image_labels', 10, 1 );
view raw gistfile1.txt hosted with ❤ by GitHub

The labels are in an object and we then reset the values of each specific item to what we want. Then return the object.

Child themes for WooThemes

I’ve been using child themes for several years now, but I’d never used one with a theme by WooThemes. Most of my clients needed simple customizing, so I used WooTheme’s backend options to make the changes.

A recent client needed a bit more than I could do through their backend though. I started off making the customization directly in the theme, which is never a good idea. Catching my mistake, I decided to throw my changes in a child theme and work from there. However, reloading with the child theme activated, everything was borked. Looking at the source, I noticed how the stylesheets were loading because my child theme stylesheet should be last in the cascade, therefore overriding all other styles. There were two files from the parent theme loading after mine. I tried several solutions, hoping a newer one using wp_enqueue_style to load the parent stylesheet instead of @import would work, but that didn’t affect the other two stylesheets.

Thankfully (before pulling my hair out), I found this page in the WooThemes support docs. What they don’t spell out on the page (not helpful WooThemes!) is that you don’t actually make CSS changes in the child theme style.css. You make a second CSS file called custom.css and make your changes there. The custom.css file is loaded next-to-last, only followed by styles put into their custom CSS field on the backend forms, and therefore overrides all the other stylesheets.

Subversion, Coda, and WordPress

I’ve been using Panic’s Coda to develop my WordPress plugins and manage my sites and I love it.  When I published my first plugin, it took me quite a while to find any real resources on using Coda with WordPress’s Subversion servers.  It’s fairly simple stuff really, but updating plugins baffled me for the longest time and I’ve finally figured out the proper steps to do it without errors or partial uploads (as evidenced by the version 0.32 of ArtistDataPress plugin that didn’t include the widget, css, or images folders…).

Random tip: when developing, use the trunk files.  These files aren’t the ones given to the public and if you have more than one developer, this is where each of checks out the files you’re working on.

For those using Coda and wanting to develop for WordPress, these are tested instructions for updating a plugin:

Make changes as needed to your plugin files.  Be sure to update the stable version number in your main plugin and readme files.

Go into the tags folder.  Duplicate the latest tag folder in there.  When it asks if you want to update, say yes.

Change the name of the folder to the latest version number.  Say yes to updating.

Copy the updated files from the trunk folder into the newly-created tag folder.  At this point, there should be a green A next to that tag folder.

After all the files have been copied to the tag folder, click the green A.  This will add this folder to the SVN repository.  Coda will ask you to type in notes about the changes – make them as detailed as possible, this is the only thing people in the future will see when looking at why the plugin was changed to a new version.

The new tag folder and all the updated files should be added to the SVN repository.  Wait about fifteen minutes and you should see the changes reflected on the plugin’s page in the WordPress plugin directory.

If the steps above don’t work or you start getting odd errors (like you need to force an update), copy your trunk files to your desktop and remove the site.  Then add the site back and check out the repository again.  Then follow the steps above.  I just ran into this today (2/11/2012) and this worked for me.