When I’m developing a site I always have an st_error_log( $var ) function that writes to an error log so I can dump variable data there to figure what’s going. On three separate occasions now I’ve had a wtf moment when it seems as though a filter or action has been firing twice for a single page load.
I’ll have a function hooked to get_header, say, and in that function I’ve got my error logging function. When I hit refresh, hey presto, my data appears in the error log. But wait, it’s appeared twice? Wtf?
The hook hasn’t fired twice for a single page load – but the server has been hit with two requests. The first time it took me an eternity to figure it out, the second time an age, and the third time, well, better but still longer than it should have. In short, the first request gets a response from the server, but that response itself then triggers a second request to the server. Here are the three different ways I’ve been tripped up:
Pagination attributes
Sometimes in the <head> of a page you’ll find something like this:
<link rel="next" href="http://www.example.com/topic/page/2" />It’s to do with pagination and is often used to help prevent search engines getting confused by what is in reality a single page spread over many. It seems however that some browsers also use this to “prefetch” content – trying to be helpful by anticipating that this next link is probably about to be viewed. So if your theme has this enabled, then yes, every time a page is requested, the server gets hit twice.
It’s up to you whether you want to remove them. They are there for a reason so it’s not cut and dry. If you do want to remove them, something like this should do the trick:
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 );
I say “something like” because it assumes the theme has hooked the function to wp_head and used the priority 10. (When removing an action you must specify the same priority as was set when it was added.)
And if you don’t want to remove them, then you may be able to at least stop the prefetch on your browser while you’re debugging – just so you can be sure there’s not something else weird going on. If like me you use Firefox it’s the setting network.prefetch-next in the advanced settings (accessed by typing about:config into the address bar).
Favicon
If you don’t set a favicon using the Theme Customizer, then WordPress uses its standard logo. The request is to a file favicon.ico at the website root, but actually this generates a 302 response and a redirect to /wp-includes/images/w-logo-blue-white-bg.png – which hits the server again. So to prevent the double hit you can either set a favicon, or keep the default by copying the w-logo-blue-white-bg.png file to the root and renaming it to favicon.ico.
Source map
The final one was my own fault. I’d copied a Bootstrap grid CSS bundle on to the site server, but hadn’t also included the source map that came with it. This again triggered a second request, and including the source map fixed it.
The lesson
The console is your friend! Problems 2 and 3 were solved by checking what resources were not being successfully fetched. Problem 1 was just googling, and well, where would we be without Google and Stack Overflow?