WordPress has a handy post revision feature which saves earlier states of a post as you make edits. Not everyone wants or needs this feature, however, and it’s handy to be able to turn it off. Plugins exist for this, but I prefer code solutions that I can put in my themes or site-specific plugins. Here’s a simple method to disable post revisions without installing a plugin:

/**
 * Disable revisions for all post types.
 */
function my_disable_post_revisions() {
	foreach ( get_post_types() as $post_type ) {
		remove_post_type_support( $post_type, 'revisions' );
	}
}
add_action( 'init', 'my_disable_post_revisions', 999 );

If you’d like to disable post revisions for only specific set of built-in or custom post types instead of targeting all types, you can do that with an array:

/**
 * Disable revisions for all post types.
 */
function my_disable_post_revisions() {
	$types = array( 'post', 'my-custom-type' );
	foreach ( $types as $post_type ) {
		remove_post_type_support( $post_type, 'revisions' );
	}
}
add_action( 'init', 'my_disable_post_revisions', 999 );

The high priority, 999, means it’s almost certain to execute after any other code which adds revision support.

The ability to disable revisions is particularly helpful when moving a site from another system to WordPress. Frequent post editing and other operations may result in a large number of revisions saved in the database.

If you want to start saving revisions again, simply remove this code from your theme or plugin.

In the WordPress admin taxonomy edit screen, Tags and any hierarchical custom taxonomies include a tag cloud of “Popular Items” in the left column above the Add Term form. I find this feature useless in most cases, particularly on a large site that may have hundreds of terms in a taxonomy.

Strangely, the official way to disable this tag cloud is to set the popular_items label to null when registering your taxonomy. Indeed, this is the only place the label appears to be used at all. If you’ve registered your own taxonomies and you can override that label in your code, go ahead and do that to clear up the problem. If you have taxonomies registered by a plugin or another method that is outside of your direct control, you can remove it by filtering the taxonomy arguments to unset the label. Here’s how:

/**
 * Remove tag cloud from taxonomy edit screen.
 */
function my_remove_popular_term_cloud( $args ) {
	$args['labels']['popular_items'] = null;
	return $args;
}
add_filter( 'register_taxonomy_args', 'my_remove_popular_term_cloud' );

If you want to target specific taxonomies, you can check which taxonomy you’re working with by passing additional parameters to the filter:

/**
 * Remove tag cloud from taxonomy edit screen.
 */
function my_remove_popular_term_cloud( $args, $taxonomy ) {
	if ( 'post_tag' === $taxonomy ) {
		$args['labels']['popular_items'] = null;
	}
	return $args;
};
add_filter( 'register_taxonomy_args', 'my_remove_popular_term_cloud', 10, 2 );

Now your taxonomy edit screens will be nice and tidy!

Here’s a quick helper function to find the top level ancestor of a given term. If you like to organize your categories in nested fashion, this function will find the very top level parent no matter how deep down the term your working with is nested.

/**
 * Get the top level parent of a given term.
 * @param WP_Term|int The term who's ancestors we'll be tracing.
 * @param string Name of taxonomy to search. Required only if $term is an ID instead of a WP_Term object.
 * @return WP_Term|bool The top level parent of $term. If $term has no parent, return false.
 */
function get_term_progenitor( $term, $tax = 'category' ) {
	if ( is_int( $term ) ) {
		$term = get_term_by( 'id', $term, $tax );
	}

	if ( 0 == $term->parent || ! $term instanceof WP_Term ) {
		return false;
	}

	while ( $term instanceof WP_Term && 0 != $term->parent ) {
		$term = get_term_by( 'id', $term->parent, $term->taxonomy );
	}
	return $term;
}

To use it feed in a term object or a term id and taxonomy combo to get the original ancestor of your term. If your term has no parent, it will return false. This is helpful if you need to apply a class to a whole tree of terms, for example. If your

It’s worth noting that this function will call get_term_by() multiple times, and it is known to create slower database queries. If you have nested your terms more than a few levels it may be worth storing the results of this function in a persistent object cache to speed up performance.