If you're reading this, it probably means that you are experiencing an odd behaviour on your WordPress home page: you are often unable to see your most recent posts, as if the browser is serving a cached version of your web page instead of the updated one. Such issue is also particularly common when visiting the web site from mobile devices.
What's the root cause of the problem, and what can we do to fix that?
Nine times out of then, the problem is due to caching issues: either your web server has a server-side cache - be it a reverse-proxy, a PHP-CGI based proxy, a caching plugin or anything else - which is not working properly, or it's sending some (or all) the pages with wrong response headers... or both. As a matter of fact, the former scenario is fairly common because most caching mechanisms - expecially the reverse-proxies - can be hard to configure properly: just to be sure, try to temporarily disable all of them and see if the problem persist. However, if the home page is the only affected page, it most likely means that you're dealing with the latter: more precisely, a rather obscure WordPress problem which is related to the Last-Modified response header.
The Issue
To fully understand the root cause of the problem, it can be useful to quickly recap what the Last-Modified response header is and why we should handle it properly.
As you might already know, the Last-Modified response HTTP header contains the date and time at which the origin server believes the resource was last modified. It is used as a validator to determine if a resource received or stored is the same: conditional requests containing If-Modified-Since or If-Unmodified-Since headers make use of this field.
What you probably don't know (yet) is that WordPress doesn't handle such response header properly: as a matter of fact, it doesn't deal with it at all, meaning that your WordPress pages - including the Home Page - do not have it at all. That's not an issue for post and pages, as they don't get modified frequently - in terms of SEO, either they do exist or not: however, the absence of such header can be troublesome for an Home Page, expecially for a blog or a news-based web site when it's most likely updated each and every time a new post is published.
There are a number of plugin - Clearfy being the most popular one - that provide a fix for that, by setting a Last-Modified response header accordingly to some given parameters: unfortunately, most of them - including Clearfy, at least as of today - tend to set it considering the actual post/page last modified date: again, although it can decently work for post and pages, it's definitely NOT a good choice for the Home Page for the aforementioned reasons.
As a matter of fact, in most Worpdress Home Pages are made of templates and/or widgets that gets updated each time a new post gets published - meaning that the last modified date of the actual page/template is absolutely meaningless and should not be taken into account. Conversely, we should find a way to retrieve the date of the last published post - aka the most recent post - and use that value instead.
The Fix
Luckily enough, this StackExchange thread comes to the rescue by providing a great way to set the Last-Modified response header of the Home Page in a suitable way - which is, as we wrote early on, getting the date of the most recent post.
Here's the relevant snippet: just place it in your WP's function.php file and you'll have a good chance to get rid of your home page caching issue.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
/* Set the Last-Modified header for visitors on the front-page based on when a post was last modified. */ /* ref.: https://www.ryadel.com/ */ add_action('template_redirect', function() use (&$wp) { // Only front-page (Home Page) if (!is_front_page()) return; // Don't add it if there's e.g. 404 error (similar as the error check for feeds) if (!empty( $wp->query_vars['error'])) return; // Don't override the last-modified header if it's already set $headers = headers_list(); if (!empty($headers['last-modified'])) return; // Get last modified post using the WP built-in function get_lastpostmodified $last_modified = mysql2date( 'D, d M Y H:i:s', get_lastpostmodified('GMT'), false); // Add last modified header if ($last_modified && ! headers_sent()) { header("Last-Modified: " . $last_modified . ' GMT'); } },1); |
IMPORTANT: If you're also using a plugin (such as the aforementioned Clearfy) that handles the Last-Modified response header in any way, remember to change its configuration settings to prevent it from doing that anymore to avoid the risk that the snippet's header settings will be overwritten during the WordPress response life cycle.
That's it for now: I sincerely hope that this workaround will help most WordPress developer that experienced this nasty issue!
I notice that this article is a bit dated (March 10, 2018 ). Does this fix still work? How can you test it to see if the functions.php code is actually rewriting the last modified date.
Yes, it still works: you can check the Last Modified date using Chrome developer tools (Network tab, headers sub-tab). Just try to set it to 2000/01/01 using the technique described by this post and then check it out to ensure it gets changed accordingly.