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:
<?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>' )); ?> |
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); |
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…?