Remove a specific TinyMCE item from the WordPress editor

When filtering a row of TinyMCE buttons, here’s a way to remove a specific button by name. This is useful for cases where you’re editing the default editor instead of declaring your own editor. In this example, we’ll remove the underline button from the second row:

function my_mce_buttons_2( $buttons ) {
	$index = array_search( 'underline', $buttons );
	if ( $index !== false ) { unset( $buttons[$index] ); }

	return $buttons;
}
add_filter( 'mce_buttons_2', 'my_mce_buttons_2' );

Drop that code in your functions.php file to remove a specific item from your WordPress editor buttons. For more information about the individual TinyMCE toolbars available see this codex page. To list all buttons by name for a given toolbar, temporarily add print_r( $buttons ); to your filter callback function.

Determine if a WordPress post or page has children

Here’s a simple function to determine if a post, page, or custom post has children in WordPress. It works by getting the children of the current post and returning a count. It will return 0 (false) if there are no children and some positive integer (true) if there are children.

function has_children() {
	global $post;
	return count( get_posts( array('post_parent' => $post->ID, 'post_type' => $post->post_type) ) );
}

Use it in your page or post templates:

if ( has_children() ) {
	// do something if this item has children
}

Clean up a bloated wp_term_relationships table

Sometimes the wp_term_relationships table becomes bloated with many orphaned relationships. This happens particularly often if you’re using your site not as a blog but as some other type of content site where posts are deleted periodically. I recently worked on a site that had 18,000 term relationships for posts that no longer exist, and it was slowing the site down. In my case it was the way a real estate plugin from Placester IDX manages real estate listings, but you may find similar problems caused by other custom functionality.

Fortunately, MySQL can help you find these orphaned relationships with a pretty simple query:

SELECT * FROM wp_term_relationships
    LEFT JOIN wp_posts ON wp_term_relationships.object_id = wp_posts.ID
    WHERE wp_posts.ID is NULL;

It can even automatically delete the orphaned entries for you! Make sure you back up your database before running the following query:

DELETE wp_term_relationships FROM wp_term_relationships
    LEFT JOIN wp_posts ON wp_term_relationships.object_id = wp_posts.ID
    WHERE wp_posts.ID is NULL;

The number of rows deleted should match the number of rows returned in the SELECT query above.

Once you’ve deleted the unnecessary items, make sure to optimize the database table.

OPTIMIZE wp_term_relationships;

Prevent WordPress from guessing if users hit a 404 error

Update: I’ve put together a plugin for this. It’s only a few lines of code, but if you don’t want to add it to your site manually, you can now use the Stop 404 Guessing plugin.

WordPress has a feature called Canonical Redirects which attempts to make sure that users always end up on the one true URL for a given request. That’s great for SEO. Built in to this feature, however, is something that mystifies a lot of developers: when a user reaches a 404, WordPress will use some fuzzy matching try to guess what they meant and redirect them.

To me, this is pretty much the polar opposite of a canonical redirect. I’d much rather have 404s result in a helpful 404 page which I can track in analytics. It can also be very confusing when you’re trying to add your own rewrite rules to WordPress.

Fortunately, you can filter the Canonical Redirect to prevent this strange 404 behavior. Add this to functions.php in your theme:

function stop_404_guessing( $url ) {
	return ( is_404() ) ? false : $url;
}
add_filter( 'redirect_canonical', 'stop_404_guessing' );

Now WordPress will continue redirecting to the canonical URL, unless you hit a 404 in which case it will display your 404 page as expected.

Posting some WordPress tips at the day job

During the week I work at a Vermont-based web agency called Union Street Media, where I’m fortunate to spend every day working with a great team on WordPress-powered websites. I’m going to start posting some of the things you’d usually expect to see here at scottnelle.com on the company blog. It will mostly be tips that I uncover during the work day after failing to find a good solution via Google. The first of these posts covers adding content to the end of all posts of a specific type. I’ve used that technique to build a plugin which allows our project managers to create project milestone signoff forms directly on the site.

Stay tuned for more WordPress posts from me both here on scottnelle.com and over at the USM Interactive Blog.

Lower the WordPress SEO meta box priority

WordPress SEO by Yoast is a great plugin, but its meta box gets high priority on your post edit screen and that can be a little annoying–particularly when it shows up in the middle of your other meta boxes. Fortunately, Yoast has put a filter in place so you can adjust the priority.

To lower the priority of the WordPress SEO meta box, you can put the following code in your theme’s functions.php file:

function lower_wpseo_priority( $html ) {
    return 'low';
}
add_filter( 'wpseo_metabox_prio', 'lower_wpseo_priority' );

Pretty simple fix for a common annoyance.

Import multiple WordPress posts with the same name

By default, the WordPress import plugin will not create multiple posts with the same name which were created on the same date. I’m not entirely certain why this is the default, non-configurable behavior but in an era where WordPress is so much more than a blogging engine there is no limit to the number of cases where it isn’t desirable. Maybe you have a post type for business locations that is arranged hierarchically and each location has a child page called “Contact Us.” Maybe a hundred other things.

In such cases, I’ve found moving a site from my production server to the live server is problematic, because the WordPress Importer plugin discards all but the first instance of a post. Fortunately, this behavior is easily changed with a small modification to the WordPress Importer.

When the plugin iterates through all of the items in the import file, it checks to see whether or not it should create a post for the current item. It only takes a minor tweak to make it always create the post.

In your plugins directory, find ./wordpress-importer/wordpress-importer.php and look for the following bit of code, currently on line 557 as of plugin version 0.6.1. In future versions the location might be different or it might be rewritten. I’ll try to keep this article up-to-date:

$post_exists = post_exists( $post['post_title'], '', $post['post_date'] );
if ( $post_exists && get_post_type( $post_exists ) == $post['post_type'] ) {
...
}

Simply modify that as follows, and WordPress will create all posts as defined in the import file:

$post_exists = 0;
if ( $post_exists && get_post_type( $post_exists ) == $post['post_type'] ) {
...
}

By setting $post_exists = 0 you are telling the importer that the post doesn’t exist, which makes it work the way you probably want it to. I hope that this behavior will change (or be configurable) in future versions of the plugin, but for now this simple mod will get you going.

Redirecting from WordPress.com to a self-hosted blog

I am occasionally asked if Simple 301 Redirects will allow you to redirect your old blog on WordPress.com to your new self-hosted blog installed from WordPress.org. It won’t but there’s an easy way to do just that.

Simple 301 Redirects only works if you can install it on the site you’re redirecting from. Since you’re redirecting from a WordPress.com blog you won’t be able to install my plugin there. What you can do instead is utilize a premium upgrade offered by WordPress.com called Site Redirect, accessible from the WordPress.com dashboard.

As of January 2014 it costs $13 a year. What it does is redirect all of the URLs from your WordPress.com blog to the same URL at a domain of your choosing. It is, in essence, a domain-level redirect.

How long should you pay for it?

Determining how long to keep your Domain Redirect in place depends on where your traffic comes from. You should be OK to cancel it after a year or two if most of your traffic comes from search engines. Search engines will see the 301 redirect and update their indexes.

If most of your traffic comes from inbound links on other sites you may want to keep the redirect in place indefinitely so those links continue working forever.

Redirect all 404 pages to your WordPress home page

I’m occasionally asked to redirect every 404 error on a site to the home page. There are a couple of reasons why you might not want to do this (see below) but there are also valid cases where it could be the right move for your site. If you’ve decided it’s the right thing to do, here’s how to accomplish it easily in WordPress:

Edit or create 404.php in your theme directory. Replace all of the content inside with the following lines:

<php
wp_redirect(site_url(), 301);
exit();
?>

And that’s all there is to it!

Why shouldn’t you do that?

There are a couple of reasons that redirecting all 404 errors could be problematic.

First, search engines are said not to pass all of a page’s link equity to the redirected page unless the content is very similar. So redirecting pages that used to rank well to the home page won’t work as a sneaky way to boost your home page.

Probably more importantly, though, is the fact that it will be difficult to monitor which links are 404ing since they’ll all just end up on the home page. The usefulness of Google Webmaster Tools and other methods of monitoring 404 requests is not just in preventing future 404s. The real power is that it helps you identify what your users are looking for and where they’re failing to find it. Fixing all 404s in an automated way makes that more difficult.

Avoiding Timeout When Exporting Large WordPress Sites

When exporting large WordPress sites with thousands of posts and comments, I occasionally run into an issue where the WordPress export tool times out before it’s finished building the XML export file. This can usually be remedied by updating the config files for Apache and PHP. Temporarily increasing the amount of time allowed for a single request should solve the problem. Note that you’ll need access to your server’s config files to make these changes. If you don’t have access, explain to your web host what you’re trying to do and they should be able to help you out.

Assuming you have access, here are some values that you can try:

In the Apache config file, try setting Timeout 300, which means that a single request is allowed to take up to 300 seconds to process before it’s shut down.

You’ll have to make a similar change in the PHP config file. That line will look like max_execution_time = 300. While you’re in there, you may also want to increase the maximum amount of memory available to PHP for a single request. memory_limit = 256M should do the trick.

After you’ve made your config updates, restart Apache so that they take effect. Now you should be able to export your site without any problems. Be patient, as it can take several minutes to export a large site. The values above will give you up to 5 minutes. If it takes longer than that, the process will continue to timeout and you’ll have to make the values even larger.

It’s important to note that after you’re done with the export you should change the settings back to their initial values. No ordinary request should take 300 seconds. Leaving the timeout values that high will allow poorly written scripts to tie up Apache processes for a long time, which will seriously impact your server’s performance.