Fresh install Setup Guide fails on Test Page Cache – Could not update config

Hello @brettmerrick

Thank you for reaching out and I am happy to assist you with this.

The admin-ajax.php request with a 500 error suggests that something is blocking the Ajax request to the server. Please check if you have any security plugins, and if so, disable the plugin temporarily and run the Setup guide.

You should also try disabling the plugins one by one and see which one may be preventing the ajax call.

Thanks!

Thanks for the quick response!

I had read through the similar issues here and thought the same thing at first, however the debug log seems to show that the request is getting to the server and that the uncaught exception is in the W3TC hook that handles the ajax request.

I can confirm that this is a fresh install of wordpress, and the only plugin is W3TC. The problem persists.

Could it be a compatibility issue with the wordpress:6.2.2-php8.0-apache image? This should be an easy thing for a developer to check.

The browser network log shows 16 requests to admin-ajax.php after I press the Test Page Cache button, and it is only the sixth request that gets the 500 error.

A “500 Internal Server Error” response code indicates that?the server encountered an unexpected condition that prevented it from fulfilling the request.

Examining the request, it seems to be enabling the file_generic test that fails:
_wpnonce=391cb87411
&action=w3tc_config_pgcache
&enable=1
&engine=file_generic

Hello @brettmerrick

Thank you for your feedback.

I was not able to replicate this, however, I’ll dig more and see what I can find and get back to you with more information.

Thanks!

@sterndata I appreciate your moderation, but does it really make sense to create 3 duplicate topics about the exact same issue? Marko mentioned he will dig into it, and after soon 4 months, to I think it is okay to add some comment as reminder, especially when it adds additional information in my case, pointing to a possible reason due to changed PHP behaviour. Hence I would appreciate if you could recover my comment. IMO that would make everyone involved’s live easier than 3 duplicates.

If what I write does not make any sense, then I’m sorry, and I will stop arguing.

I found the issue: It appears when permalinks are disabled (set to “Plain”). In this case, a set of rewrite rules are removed from the .htaccess:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase /wordpress/
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]

I thought that the missing rewrites are the actual issue, not so much whether permalinks are resolved or not. However, removing these manually does not break the cache test. They do not actually enable the permalinks, but just assure that requests are rewritten to use the index.php. Since this is the default index, this is however mostly the case anyway. The permalinks are then resolved/served internally from the backend. Not sure why the W3TC cache test would rely on this, but I am perfectly able to toggle the issue by switching in Settings > Permalinks between “Plain” and “Post name” (or any other).

• This reply was modified 1 year ago by Micha.
• This reply was modified 1 year ago by Micha.
• This reply was modified 1 year ago by Micha.