Page Cache method suddenly changed, causing error 503

Hello @silente08

Thank you for reaching out and I am happy to help!
I am sorry about the issue you are having and this is a very interesting problem, which honestly, was never reported before.

W3 Total Cache does not have the ability to swtich to differnt caching methods by itself. So the only way to do this is manually via the plugin, or changing the /wp-content/w3tc-config/master.php file which is a config file.
This being said, Have you ever used Redis for Page Caching in the W3 Total cache? Also, please chec your logs and see what happens in that time period when the caching method is somehow changed

Thanks!

Hi! It might be connected to the CDN that I have recently activated through my web hosting, as this has caused issues for me with another caching plugin on another website. But I activated it about a month ago and this website was not down in between. I probably experimented with Redis a long time ago, but not recently.

I should point out: ever since using the plugin, the “Test Page Cache” from the Setup Guide has never worked for me, always leading to the error message “Could not update configuration. Please reload the page to try again or click skip button to abort the setup guide”. So there might have been a problem with the plugin on my website since the beginning that has only now become apparent for some reason.

The logs I see in my Dashboard (my hosting provider is OVH) are not very helpful, I only see three error logs from last night (around the time I tried to fix it for the first time):

[Tue Sep 03 02:27:04 2024] [error] [client 54.37.63.15] [host sanremn.cluster030.hosting.ovh.net] AH00687: Negotiation: discovered file(s) matching request: /homez.1033/sanremn/www/index.html (None could be negotiated). [Tue Sep 03 02:29:44 2024] [error] [client 54.37.63.15] [host sanremn.cluster030.hosting.ovh.net] AH10141: FastCGI: comm with server "/homez.1033/sanremn/www/index.php" aborted: idle timeout (160 sec) [Tue Sep 03 02:29:44 2024] [error] [client 54.37.63.15] [host sanremn.cluster030.hosting.ovh.net] AH10149: FastCGI: incomplete headers (0 bytes) received from server "/homez.1033/sanremn/www/index.php"

Hello @silente08

Thank you for your feedback.

Do you have any custom security rules or security plugins that may be blocking the requests to the server, and possibly blocking or reverting the mentioned configuration file?

Thanks!

I don’t have any security plug-in installed currently, but if I remember correctly, I used to have Really Simple SSL for some time. Might be that some files have not been cleaned up. I would have to scan through the files, anything to look for specifically?

Hello @silente08

Thank you for your feedback.
This should not impact this at all, or I do not have any experience that this would be the cause of this.
Have you experienced the problem since the last time you saw it?

Thanks!

No, since that day it was stable on Disk: Enhanced, without visible errors. The Setup Guide Test is still stuck though, so something is not working properly.

Hello @silente08

Glad to know the issue is gone now.

As for the Setup Guide, please check the permalinks and change the permalink structure to anything other than default in your Dashboard – Settings>Permalinks. If this does not work, check if php-curl is missing.

Let me klnow if this helps!

Thanks!

I was testing a bit more and managed to make my site (including the backend) completely unavailable, presumably because of activating minify. Fixed it via FTP, now I am back to only PageCache. My permalinks have always been different than default and php-curl seems to be available. So no solution there, the Setup Guide still fails. I have also analysed my website with PageSpeed Insights before and after activating the PageCache: apparently, there is no improvement (performance 16–20 on mobile and 56–64 on computer). I think I will have to upgrade my webhosting before working any further on these improvements …

Okay, after upgrading my hosting and doing further testing, I have been able to reproduce the initial problem! Apparently, if I have page cache disabled and then try the Setup Guide, the page cache will automatically be enabled and set to the last option that the test tried before failing. Most of the times, the Page Cache Test for me fails after Redis, which is why that is where I ended up in the beginning. Not great of a behaviour, but the underlying problem is the Setup Guide failing, so I think I will open a new topic for that question! Thanks so far.