WordPress

I recently looked into creating a CSS-only navigation menu for WordPress, in an attempt to lighten the page payload. That’s a story that I’ll post separately, but it made me realise just how much effort WordPress goes to when creating the menu.

Of course, it’s all behind the scenes and it probably takes very little elapsed time, but it made me wonder whether its possible to cache the HTML. I’d used WP transients before to cache some custom site elements such as maps and galleries which don’t change frequently, so what about menus?

It turns out that it’s really straightforward to do. That said, there is a potentially major disadvantage, depending on the styles you’re applying to the menu items. I’ll come back to that shortly.

There are very few lines of code to add to your theme’s functions.php.

add_filter( 'wp_nav_menu', 'mt_cache_menu', 10, 2);
function mt_cache_menu($menu, $args) {
	set_transient ( 'mt_menu' , $menu, 3600 );
	return $menu;
}
add_filter( 'pre_wp_nav_menu', 'mt_cached_menu_check', 10, 2);
function mt_cached_menu_check($return, $args) {
	$menu = get_transient ( 'mt_menu');
	if ($menu) return $menu.'<!-- Cached -->';
	return null;
}
add_action ( 'wp_update_nav_menu', 'mt_delete_menu_cache', 10, 2);
function mt_delete_menu_cache($menu_id, $menu_data) {
	delete_transient ( 'mt_menu');
}

The first function, using the wp_nav_menu hook, saves the menu HTML when it’s just been created by WP. You need to decide on the key for the cache transient, and how long the cache will persist, in numbers of seconds. In the example above I’ve set it only for 3600 seconds, but in reality you’d probably choose a much higher value. If you leave this parameter out, it will default to “0”, which means “do not expire”.

The second function uses the pre_wp_nav_menu hook. WP calls this hook just before it sets about creating the menu. If you return a non-null value, WP will use that as the HTML, and save itself the bother of generating the menu afresh. So get_transient looks to see if the transient exists, and if so, whether it’s expired. If we get a value back, it must be the HTML we stored there, so we return it to WP. Otherwise, we return null so that WP will regenerate the HTML.

The final function here is to delete the cache when a menu is updated. It’s a simple hook into the wp_update_nav_menu action which fires in the admin back-end as a menu is changed. We simply delete the transient, with the result that next time round, WP will have to recreate the HTML and we can cache the new code.

Now, that major downside …

The menu HTML elements are dynamically assigned CSS classes. You can see the list at https://developer.wordpress.org/reference/functions/wp_nav_menu/#menu-item-css-classes. Classes such as .current-menu-item are designed for you to use to style (maybe highlight) the menu item for the current page. And if you cache the output, that class will be frozen in the HTML as it was when the menu was saved away into the transient. It won’t reflect the current page any more.

Hmm. Well, as long as you’re not styling anything like that, the cached version will be OK to use. But it could be a big disadvantage to caching. I’ve seen some blog posts where people suggest caching the menu separately for every page (every post?) on the site. Well maybe, but on a site with a big menu structure, maybe not.

I’ve one site where this will not be an issue – the menu styling doesn’t use current page highlighting. So I’ll go with this caching approach and see how we get on.

The WordPress login is quite possibly secure enough, but on a couple of my sites I’ve added a piece of custom authentication. This also acts as a bot-filter, given that the required input (in theory) isn’t obvious.

I figured it might be useful to describe the process of adding a field to the login form, and subsequently validating the user’s input.

A note – the algorithm I’ve used on my other sites isn’t the same as this, and doesn’t depend on a session variable. Sessions are by default unavailable in WordPress, which strives to be stateless, but you can set up a session quite easily, as it turns out.

Another note – there are plugins that will do something similar, but I like to have more control over my sites, and it’s not difficult to code.

The idea is that I create a string containing pairs of characters and digits. For example, this might be p4s1g2d4b6c7m4t3. I display this on the login page. My users know the secret, which is that they must enter the digits following ‘c’ and ‘p’ respectively. In this case, they would enter 74.

The code is regenerated on every login form, in an attempt to make it tricky to see what’s going on. It’s not utterly fool proof but hopefully obscure enough to ward off casual intruders.

Step 1 – create and store a random ‘captcha’ value, and add a field to the login form.

This code would go in your theme’s functions.php or in a plugin. The PHP tags at start and end are only shown here to enable syntax highlighting.

<?php
add_action( 'login_form', 'my_login_form');
function my_login_form () {
  session_start();
  $chars = ['b','c','d','g','m','p','s','t'];
  for ($i = 0; $i < 8; $i++) {
    $chars[$i] .= rand(1,9);
  }
  shuffle($chars);
  $_SESSION['captcha'] = join('',$chars);
?>
<div style="height: 100px;">
  <label>
    <p><?php echo $_SESSION['captcha']; ?></p>
    <p>Enter security code numbers below</p>
    <input type="text" name="captchacode" value="">
  </label>
</div>
<?php }

So we hook into WP’s login_form, in which you are simply adding to the standard form. We start a session, create the random string, and store it in the session. Then we display the string, and add an input field to the form.

Step 2 – validate the user’s input against the stored string.

Again, this code would go in your theme’s functions.php or in a plugin.

<?php
add_filter('authenticate', 'check_captcha', 90, 3);
function check_captcha($user, $login, $password) {
  session_start();
  $session_code = $_SESSION['captcha'];
  session_destroy();
  if ($login == '' or $password == '') return $user;
  if (is_wp_error($user)) {
    $error = '<strong>ERROR</strong>: Login details not recognised';
    return new WP_Error( 'invalidcombo', $error );
  }
  $captcha = '';
  $chars = ['c','p'];
  foreach ($chars as $char) {
    $i = strpos($session_code, $char);
    $captcha .= $session_code[$i + 1];
  }
  $input = sanitize_text_field($_POST['captchacode']);
  if ($captcha != $input) {
    $error = '<strong>ERROR</strong>: Login details not recognised';
    return new WP_Error( 'invalidcombo', $error );		
  }
  return $user;
}
?>

We hook into WP’s authenticate filter, and pick up the session variable we stored earlier. Then just to be tidy, we destroy the session.

Next I have some code to check if WP has already have rejected the user, so there’s no point in continuing beyond there; we just return an error.

And then on to the check for the extra input field. The two characters to check are set up in an array (‘c’ and ‘p’ in this case). If you wanted to add more characters this is where you’d do it.

Then we concatenate the digits to the right of each of the key characters, and check the user’s input against the result. If it’s no good, we return an error, but if it looks good, we return the value that was originally supplied to the filter and let WP do the rest.