smarx80
Member
Posted 2 years ago #
Hi,
I've noticed that if I put the home page in cache, editing one post, the home page (in Supercache) still contains the outdated version of the post.
After editing the post, wp-super-cache invokes the code for rebuild several pages, including the home page, some categories and the single one.
While the text of the post in the single (Supercache version) is updated properly, the Home page continues to have the outdated version.
If I delete the home page file in Supercache thus forcing regeneration, all is updated correctly.
That's odd. I haven't seen that and the homepage is supposed to update whenever a post is updated. See the wp_cache_post_change() function in wp-cache-phase2.php.
Can you debug it? Enable debugging on the admin page and you should see the text "Post change: deleting post cache files for" and the cache filename when you edit a page.
Visit the front page and note the cache file served first. (You may need to use the development version from the download page)
smarx80
Member
Posted 2 years ago #
Hi,
I've enabled the debug, level 5.
Changing a post, the debug logs this:
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/index.html
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/index.html.gz
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/index.html
15:12:53 /wp-admin/post.php rebuild_or_gc: deleted /home/xxx/wp-content/cache/supercache/www.abcdefg.com/index.html.gz
This is logically correct.
But unfortunately it seems that the home page is re-created meanwhile and has the unmodified content!
Thanks for trying that. Are you viewing the homepage as the user that published the post (ie. as a logged in user) or an anonymous user?
smarx80
Member
Posted 2 years ago #
Anonymous one, in another PC, clearing browser cache+cookie.
Check the headers sent to those users - perhaps your server is missing one of the modules required (and for some reason the plugin's checks for those modules has failed).
The headers normally tell the browser how long the page should be cached by the browser but maybe they aren't being sent.
Did you check the actual supercached file on your server? Was it updated (despite seeing the delete commands above)
smarx80
Member
Posted 2 years ago #
No, this isn't a browser issue / HTTP Expire header...
If I view the HTML in che supercache page (via SSH or FTP - so we can exclude browser issues ), I see the the unmodified content!
After few seconds, deleting the supercache page, the new page is rebuilt with the correct content.
Thank you, donncha.
That is weird. You could search for the debug "delete" line listed above in wp-cache-phase2.php and remove the "@" from in front of the unlink() command. That will drop an error message in your PHP error log if there is one.
smarx80
Member
Posted 2 years ago #
I'll do that.
But, I've seen that the atime / mtime / ctime is updated...
Mah...
smarx80
Member
Posted 2 years ago #
Hi Donncha,
we got 0 PHP errors.
On http://www.binpaste.com/v.php?id=fmzsw
you can find the debug log we see updating a post.
Ok, if the atime/mtime/ctime change your visitors might be seeing old versions because of missing Apache modules. The readme.txt lists the required ones.
Does the problem happen in half-on mode?
smarx80
Member
Posted 2 years ago #
Donncha,
the atime/mtime/ctime changes, but the content of the supercache page - seeing it via an ssh/FTP connection is the old one...
No missing apache modules (list of active modules achieved with httpd -l):
mod_filter.c
[...]
mod_deflate.c
mod_mime_magic.c
[...]
mod_expires.c
mod_headers.c
[...]
mod_mime.c
[...]
mod_rewrite.c
mod_so.c
But, yes: the problem seems to disappear in half-on mode (but half-mode on = less than half speed...)
You could play around with the wp-content/cache/.htaccess then. There's a "Header set Cache-Control 'max-age=300, must-revalidate'" line you can change.
Try changing 300 to 0. Does that help?
In that file, you could also take out the IfModule .. and ending IfModule tags from that file and check for 503 internal errors, *just in case* the modules aren't loaded.
smarx80
Member
Posted 2 years ago #
Donncha,
I've changed the expiration: from 300 to 0.
It does not help.
I've cut off the <ifmodule> tag, keeping the line between the starting/closing tag: two hours of intensive traffic without any kind of error ( no 50x errors in Apache logs, no PHP errors ).
We are missing something.... is there a cache mechanism that WP use to store something?
Thank you.
smarx80
Member
Posted 2 years ago #
Good news, maybe I've found the bug.
It appears to be related to the $cache_rebuild_files option.
Disabling it, everything seems to be cached properly.
Any ideas for the reasons of this bad dehaviour?
That's the cache rebuild feature. I have it enabled on my blog and it works here. It's odd that it doesn't work for you. Do your pages take a long time to regenerate? If they did, users would see the old version until it was recreated.
Normally this is only for 2-3 seconds but perhaps something is happening on your site to either cause pages to take ages to create, or to kill the process that's recreating the cache page. It renames the supercache rebuild file back to the index.html/index.html.gz but if the process dies (which is very unusual) before completing, it won't update the supercache file.
smarx80
Member
Posted 2 years ago #
<!-- Dynamic page generated in 2.138 seconds. -->
Usually, it takes from 0.7 to 2.8 seconds to be regenerated.
Any suggestion to debug this function, specially if the process dies before creating the new index.html?
Are there any seg faults in your error logs? You could add error_log() calls to wp_cache_phase2() in wp-cache-phase2.php - the cache rebuild code that renames the "rebuild" files back to index.hml/index.html.gz is there.
The supercache file is written at the end of wp_cache_get_ob() - there's a chance the function is bombing before the end. You should error_log() that function maybe before any return commands.
smarx80
Member
Posted 2 years ago #
Hi donncha,
I'm sorry, but I could not understand the cache reduild feature.
At line 86 of wp-cache-phase2() you say:
If the .needs-rebuild file was modified less than 30 seconds ago, rename it back to the .html file.
Ok. So, if somebody visits the page in less than 30 seconds after the rename to .needs-rebuild, wp-super-cache will update the content very late, when the page expires. It's correct?
If someone visits the page within 30 seconds of the page being updated (and the rebuild file being created), the plugin will remove the .rebuild extension. That way other people who see that page will get a slightly outdated page for the few seconds it takes for the cached page to be regenerated by the current process.
In wp_cache_get_ob() the cached page is generated and overwrites the files that were temporarily served to users for the few seconds the page took to be generated.
Does that make sense?
btmorex
Member
Posted 2 years ago #
I had the same problem. Disabling cache rebuild solved it. I noticed in the cached files list a bunch with ".needs_rebuild" at the end. Apparently, they never got rebuilt.
