This is also connected to my previous question I thought this is happening by the reason of Cloud Flare as you said but it is not. I totally disabled Cloud Flare using my own normal nameserver, ther eis not other caching service or similar plugins just WP Super Cache.
I epsecially checked Extra Homepage Checks as I want to keep my homepage fresh. So, in the end when someone visits the homepage, if it is the time for preparing the new version of homepage the WPSC, it doesn’t send the old cache, instead keep waiting user more than normal like 14 seconds the line (I really mean 14 seconds), and than shows the page. After this process, any other users from any other devices gets the cached page in 1 to 2 seconds.
This is a serious problem and I couldn’t find what am I doing wrong.
Screen shots are below:
Have you looked at the debug log in the plugin to see what’s happening?
Maybe something you have installed is updating a post continuously which triggers the WordPress actions that go along with that. The plugin is connected to those actions to clear the cache of related pages, including the homepage.
I just visited your homepage and yes, it took 6.648 seconds to create but a reload happened instantly. Something is clearing the cache probably or you’re generating different cache files for every visitor. You’ll be able to tell all that from the debug log. Hopefully.
I respect your consideration on my case.
I couldn’t find hoe can I read debug log or even if it’s logging now because ther was a button Enable Logging, so does it means it was logging before that?
@donncha It started get logs after clicking that button it’s Ok but what I need to find in there? What exactly I need to search in lines?
Try to search lines related to deleting. These lines often contain wpsc_delete_files or prune_super_cache
First column is date, second is process id and third is request (you will easy recognize is it wp-admin, wp-cron or something else).
It seems that you are using “remote blogging”. I think that other website uses xmlrpc.php to publish new posts on your website. It removes front page from the cache because front page should show new posts. You could see it into your WPSC log.
You need to create cron job on your server which will run “real process” instead of default WP cron. You could see more details:
If you do it, then you should run preload (eg. daily) to refresh posts. Second issue is front page, but I’ll share PHP script which will refresh more frequently (you need to create additional cron task for this). Other possibility is to you add some WP hook (which will run at end of xmlrpc.php) which will refresh front page.
Also, rendering time for front page is too long, but it could be consequence of virtual cron processes (which you could solve). It’s recommended to update PHP to 7.2 if it’s possible.
I’m totally disabled Heartbeat and WP Cron. I’m using server real cron via cPanel setup with the command of:
wget -q -O – https://wuwei.today/wp-cron.php?doing_wp_cron >/dev/null 2>&1
It trigger every 15 minutes and I see it works Ok on WP Crontol logs.
I use IFTTT to send posts and it dosn’t have a function to delete or do nothing with the FrontPage. It must just send the new posts.
The 1st thing I don’t understand is why XMLRPC deleting the frontpage,
2nd thing is even it’s deleted why WPSC doesn’t answers with the cache. I tested this on different server clone of this website I was sure I’m the only user coming in with a tracer. Same thing was happening. How much it spend doesn’t matter, first time visit hits so long like 6 to 18 seconds. It’s longer than normal page creation time like as 3 to 5 seconds on default settings.
So, the problem is why I’m not getting cached file in the first. As I see XMLRPC is not deleting the cache file it’s just refreashing the homepage. Homeapge real files are not related to cached files directly but more indirectly.
I’m still thinking this is sort of problem happening on the side of WPSC because whatever happens on real page WPSC must send cache file when it’s creating the new one as I selected the Cache Rebuild function.
If you use rewrite rules (Advanced delivery method) then Apache (LiteSpeed) will serve static HTML files. Could you try to set “Simple” method and send debug log when you access first time to front page?
I think that you could use hook xmlrpc_call to run PHP code which will refresh front page (after publishing new post). It’s possible that xmlrpc.php removes front page (but you are right, I don’t see exact line in your debug snippet). If you want to try this solution, I think that I could create some PHP snippet for you.
@kayacanakin Please remove lines which contains cookies (Removing auth and similar lines) for security reasons…
I’ll try to reproduce your issue. It seems that you have set “Make known users anonymous so they’re served supercached static files.” which could make some “side effects”.
@stodorovic Unfortunately I can’t see the EDIT popup button for previous messages, great right?
Whatever I can always change the author name no problem for now but it’s a problem I can not change the previous messages older than the last.
I will also try to create the issue with completely new WP installation.
Thanks for your help. I really want to hear from @donncha.
I see EDIT button for my message (but it’s hidden until I move cursor to gray line ). Anyway, if you are logged out then cookies are destroyed.
We are working on https://github.com/Automattic/wp-super-cache/pull/657 which will improve code related to “Make known users anonymous so they’re served supercached static files.” and cookies caching (and I’ll try too test your issue with latest code from github). I see that wp cache file is created (instead super cache file) and it could be an issue (why “Cache rebuild” doesn’t work). We could wait comment from @donncha
@stodorovic I’ve archived the posts and please lay off the notification abuse. You do not need to
@anyone with each reply. That’s abusive, please do not repeat it.
Yes, I know that I used it just now but you
modlooked this topic and you need to stop pinging the author like that.
@jdembowski I was also using tagging option because that’s why it’s invented. Your comment doesn’t make anysense to me, we are not abusing any option but we always used when the person needs to look the exact point.
It is a feature. In the meaning of terms you can not abuse anyone if there is no restriction against the feature otherwise you can not call it feature. It means ther is a bug so you must change the feature options and limitations instead of moderating each posts.
Stop. Read what I wrote. Read who I wrote it to.
I’m not looking for any argument and I’m not getting into one with you either. Focus on your problem.
I was brought here by the
modlooktag to deal with auth cookies in the logs posted. That was dealt with.
While here I notices that the notifications were being abused. I dealt with that too.
I’m not looking to deal with you in an argument. There is not argument and I hope you get that. Focus on your problem in this topic. Picking a fight where there is none isn’t helping anyone.
It seems that’s an issue related to “Cache HTTP headers with page content.“. This option forces creating of wp-cache files instead of super cache files.
I’ve seen in your log (which I can’t find now), but I’m also confirmed in my testing:
13:33:27 22870 /wp-admin/post.php rebuild_or_gc: deleted non-anonymous file: /home/.../wp-content/cache/supercache/.../wp-cache-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.php 13:33:27 22870 /wp-admin/post.php rebuild_or_gc: deleted non-anonymous file: /home/.../wp-content/cache/supercache/.../wp-cache-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.php
I’ve updated post and it’s triggered this action.
If I disable “Cache HTTP headers with page content.” then I see:
13:45:47 21534 / wpcache_do_rebuild: found rebuild file: /home/.../wp-content/cache/supercache/.../index.html.gz.needs-rebuild
It confirmed my suspections that’s related to wp-cache files. I’ll check more details.
I’m really thankful for your effort, thank you so much for that.
I wanted to mention I’m still getting strange results like this
I totally unchecked the HEADER thing and also unchecked EXTRA HOMEPAGE CHECKS.
So, it’s pretty default now and setted up 1 Hour cache time and check on every 600 seconds. So basic setup nnothing special and advanced but stil geting the same results as the first created cache not served from super cache and also waits user more than normal on the queue for nothing.
I changed the server, closed all plugins and the result is same.
I’m trying to understand if any plugin interference cause this or any other thing I’m doing wrong.
And I don’t understand why I haven’t heard anything yet from the real author developer.
- The topic ‘First homepage load is not cached and served from cache’ is closed to new replies.