Removing page, post, tag, category and taxonomy IDs from the body_class in WordPress

Posted on by

WordPress loves to add a wide range of CSS classes to the body of a page through, depending on what type of page it is, what resources it uses, and so on. Some of this is helpful (like ‘archive’, ‘post’ and the page format classes – ‘single-format-gallery’, ‘single-format-image’ etc.), but some of the tags are just noise – like the tags that have the post/page/category/tag/term IDs. There are a couple of ways to remove tags that you don’t want by filtering the body_class function. You can remove all generated classes, or add new ones, but selectively removing classes is a bit more tricky, depending on what you want to remove.

This function will strip out the IDs WordPress adds to tags, categories, pages, posts and taxonomy pages.

add_filter('body_class','remove_ID_classes_from_body', 50 );
function remove_ID_classes_from_body( $classes ) {
	global $wp_query;
	$page_query = $wp_query->get_queried_object();
 
	if(is_tag() || is_tax() || is_category()) {	
		$classes = array_diff( $classes, [( is_tag() ? 'tag-' : ( is_tax() ? 'term-':'category-') ) . $page_query->term_id] );
	} elseif (is_single() || is_page() ) {
		$classes = array_diff( $classes, [( is_page() ? 'page-id-' :'postid-').$page_query->ID] );
	}
	return array_unique( $classes );
}

How to stop WordPress adding responsive images to your RSS feed

Posted on by

I have spent a lot of time hacking/munging how WordPress handles RSS output, as I often want different titles/image sizes etc. for RSS feeds than I do for the original web posts. I was just a bit unhappy to find out that WordPress’ automatic generation of responsive images (via the ‘srcset’ attributes) now adds this code to images in RSS files as well.

This is simply fixed by turning the srcset generation code off for RSS files:

if (is_feed()) {add_filter( 'wp_calculate_image_srcset_meta', '__return_null' );}

Variable names in WordPress (or why you should never use $category as a variable name)

Posted on by

The great thing about WordPress and PHP is that you can call variables anything you like. The bad thing about WordPress and PHP is that you can call variables anything you like…

Think about these variables:

$post, $category, $template

What do they have in common? Well, they all look like good, descriptive variable names don’t they? What if you changed this to

global $post, $category, $template;

and then put this in a template for a post…?

echo $post; echo $category; echo $template;

Well, you’d get all sorts of interesting things, as $post, $category and $template are all global variables in WordPress.

FYI: there is a (partial) list of WordPress global variables in the Codex.

So if you use these variable names, and you also access global variables with those names… sometimes you’ll be thinking: why doesn’t my code work? And you’ll find out that when you thought you were changing a local variable you were actually changing a global variable, and that affected something else…

See also: Global variables and understanding scope in WordPress.

Working with taxonomies in WordPress

Posted on by

I’ve really started to get into using taxonomies in WordPress. One of the early problems I had though was trying to get them to work – so here’s a few things I’ve learned about WordPress taxonomies.

Don’t define taxonomies in functions.php

This is the classic mistake users (and some developers) make. They register (i.e. define) taxonomies in a theme file, change the theme… and wonder where their taxonomies went! (Hint: they’re still there in your database – but if they’re not registered they can’t be accessed.) The solution to this is simple: use a functionality plugin. Then it doesn’t matter which theme you use: as long as the plugin is active, any theme can access your taxonomy data.

Managing taxonomies

WordPress doesn’t have the most robust set of tools for managing taxonomies – you can’t add them via the interface for example, and there are no built in tools for moving things between tags/categories/taxonomies. There are a couple of plugins that I’ve found very helpful:

Term Management Tools

Want to move terms between tags or categories and taxonomies? Want to rename/combine tags? Term Management Tools does that.

TC Custom Taxonomy Filter

You know those helpful dropdown menus you can use to filter posts by category etc.? TC Custom Taxonomy Filter lets you do that for every taxonomy you define. Very useful.

Making taxonomies appear – aka ‘why doesn’t it work’?

So you’ve defined your taxonomy, you’ve added new items/tags, you click on ‘View’ and you get… a 404 page. Go to Settings: Permalinks and select ‘Save Changes’. (NB: you don’t have to make any changes…!) That will update the rewrite rules and your taxonomy should work… assuming of course that you’ve got posts in that taxonomy.

A taxonomy is just a… category

Don’t believe me? Go to a taxonomy template. Add this:

var_dump($wp_query->query_vars);

Categories, tags, taxonomies… all the same thing.

Learning from themes

Posted on by

A big part of learning how to use WordPress is learning how to do things: one of the best ways to do that is to pull themes and plugins apart and see how they work. There are some great themes and there are some rubbish themes: the more you look at, the more elegant solutions you find. I’ll admit I didn’t really get the big deal behind the twentytwelve theme, and I was distinctly underwhelmed by the underscore theme – though I learned a lot from pulling it to bits.

The upcoming twentythirteen theme is different though – I really like the way it uses post formats and can see how you can abstract a lot of formatting decisions that I used to make on a category basis.

add_node vs add_menu in WordPress

Posted on by

If you were modifying the admin bar in WordPress 3.x you used to call this:

// Add a link to the dashboard in the [pre-existing] site-name node
$wp_admin_bar->add_menu( array(
	'parent' => 'site-name',
	'id'     => 'dashboard',
	'title'  => 'Dashboard',
	'href'   => admin_url(),
) );

to add a new item to your admin toolbar. Now you just replace add_menu with add_node – they have exactly the same effect – and exactly the same syntax – just a slightly different semantic effect on the reader.

Changing the heading levels for WordPress widgets

Posted on by

If you want to change the heading levels for widgets in a sidebar, you shouldn’t use actions or filters or css to override WordPress: what you do is change how the sidebar is *defined* when it is first initialised.

If your theme uses a sidebar, it has to register it first. Somewhere in your theme (usually in your functions.php file) you will find a call to the register_sidebar( $args ); function, where $args is either a string or an array that defines how the sidebar is structured.

If there are no arguments for the register_sidebar() call then the defaults are used – this is to use h2 for the widget titles. If you want to use a different heading (or none at all) then you need to set the values for 'before_title' and 'after_title' when you call register_sidebar() like this:

<?php register_sidebar(array(
  'name' => __( 'Right Hand Sidebar' ),
  'id' => 'right-sidebar',
  'description' => __( 'Widgets in this area will be shown on the right-hand side.' ),
  'before_title' => '<h1>',
  'after_title' => '</h1>'
));
?>

What template am I using? Understanding the WordPress template hierarchy.

Posted on by

Sometimes I find that when I’m developing a theme, changes I make to .php and .css files sometimes don’t seem to have any effect on my theme, no matter how many times I reload the page in a browser or empty the browser’s cache. This is often because WordPress isn’t loading the template file I think it is. This is very true when you’re first developing a brand new site and may not have may posts/tags etc..

The standard advice is to familiarise yourself with WordPress’ template hierarchy – not only does the Codex explain when a template is being used, there is also a helpful flow chart provided by Chip Bennett. The problem is that the documentation often isn’t 100% accurate – for example WordPress won’t use an archive.php template if you’ve only got one post – it will use index.php instead.

A solution to this is to add some code that lets you check what template file WordPress is using: fortunately that value is stored in a global variable called $template. The code below adds a menu item to the WordPress Admin Bar that tells you what template is being used. The function checks if you are on an Admin screen or on your site, and adds an appropriate menu item.

// removes and adds links/menus from the admin bar
function edwp_admin_bar_render() {
	global $wp_admin_bar;
 
	$wp_admin_bar->add_group( array( 
		'parent' => 'site-name', 
		'id' => 'theme' ) 
		);
 
	if ( !is_admin() ) {
		global $template;
		$short_path = explode(get_stylesheet_directory(), $template,2); 
		$wp_admin_bar->add_menu( array(
		'parent'=>'theme',
		'id' => 'template',
		'title' => 'Template: '.$short_path[1],
		'href' => ''
		));
	}
 
	if ( is_admin() ) {
		global $current_screen;
		$wp_admin_bar->add_menu( array(
		'parent'=>'theme',
		'id' => 'cur_screen',
		'title' => 'Admin screen: '.$current_screen->base,
		'href' => ''
		));
	}
 
}
add_action( 'wp_before_admin_bar_render', 'edwp_admin_bar_render',10);

Whatever happened to metricmail.com?

Posted on by

Not so long ago there was a great little company called Metric Mail that sent you weekly emails that summarised your web traffic data that had been captured by Google Analytics. It was a really useful little service and I recommended it to many people who were just starting web sites and who found the whole process of tracking their web traffic complex and intimidating.

So whatever happened to metricmail? Their website just says ‘We know it’s been quiet lately’ and they’ve not sent out any analyses since June 2012…?