This strange thing happened to me earlier today – added a custom post type earlier this week, published an article this afternoon – but then I couldn’t view the published version – WordPress said it couldn’t be found (404 error).
Go to your dashboard, and then to settings/permalinks.
Scroll to the bottom and click “Save Changes”. This will force WordPress to update permalink settings and your posts in your custom post type should now work.
WordPress loves to add a wide range of CSS classes to the body of a page, 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 );
}
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' );}
I’m a big fan of modularising functions and only loading resources when needed. This snippet should be in your functions.php file and will only load an include file if a visitor is on the login or registration page. You can then squirrel your functions that customise the login experience or style it with CSS away here.
if ( in_array( $GLOBALS['pagenow'], array( 'wp-login.php', 'wp-register.php' ) ) ) {
require_once locate_template( 'INSERT_FILENAME_HERE.php' );
}
WordPress – or should I say JetPack – has a lovely habit of loading a large amount of cruft that you may not want on your page. After the recent WP 4.6.x update I found the custom login page on one of my sites didn’t load properly anymore, because all the custom css was being over-ridden by css files WP was injecting at page load. This function stops this injection:
add_action( 'login_init', function() {
wp_deregister_style( 'login' );
wp_register_style( 'login', "" );
wp_deregister_style( 'buttons' );
wp_register_style( 'buttons', "" );
wp_deregister_style( 'l10n' );
wp_register_style( 'l10n', "" );
wp_deregister_style( 'forms' );
wp_register_style( 'forms', "" );
wp_deregister_style( 'dashicons' );
wp_register_style( 'dashicons', "" );
} );
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.
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.
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.
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:
Want to move terms between tags or categories and taxonomies? Want to rename/combine tags? Term Management Tools does that.
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.
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.
Don’t believe me? Go to a taxonomy template. Add this:
var_dump($wp_query->query_vars);
Categories, tags, taxonomies… all the same thing.
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.
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.
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:
__( 'Right Hand Sidebar' ), 'id' => 'right-sidebar', 'description' => __( 'Widgets in this area will be shown on the right-hand side.' ), 'before_title' => '', 'after_title' => '
' )); ?>