Micha

Many thanks for solving this so quickly. I just applied the update, did scan, and can verify that the this test does now pass on our instance. Great work!

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 11 months, 3 weeks ago by Micha.
• This reply was modified 11 months, 3 weeks ago by Micha.
• This reply was modified 11 months, 3 weeks ago by Micha.

@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 face the same error when trying to empty the comments spam. It deletes one comment, throws this error and aborts.

Commenting the line as suggested helps indeed, thanks!

I like to run my PHP environments minimal and hence disable all modules that are not used.

As said, aside of documentation, the Tools > Site Health > Status checks seem to be a good place to add a respective check. There is a general “recommended modules” check, not sure whether plugins can hook into it and add their own modules. Otherwise I see other plugins adding their own checks, which Wordfence could do as well.

For completeness: It was Wordfence requiring the PHP ctype module since v7.8.0. I updated Wordfence shortly after it’s release >1 month ago, so not sure why I faced the issue just today right after updating Simple Local Avatars, but I guess W3 Total Cache and/or the OPcache itself have something to do with it.

Ah sorry, not an issue of this plugin, but the update seems to have been just a trigger for some issue in combination with Wordfence and W3 Total Cache.

Great that it is implemented. Wishing all of you a Happy New Year!

Here is a fix until a new version has been released:

cd /tmp
curl -LO https://github.com/johnbillion/wp-crontrol/archive/refs/tags/1.13.2.tar.gz
tar xf 1.13.2.tar.gz
mv wp-crontrol-1.13.2/vendor /var/www/wordpress/wp-content/plugins/wp-crontrol/
rm -R 1.13.2.tar.gz wp-crontrol-1.13.2

Adjust the path to your WordPress accordingly, of course.

Here is a fix until a new version has been released:

cd /tmp
curl -LO https://github.com/johnbillion/wp-crontrol/archive/refs/tags/1.13.2.tar.gz
tar xf 1.13.2.tar.gz
mv wp-crontrol-1.13.2/vendor /var/www/wordpress/wp-content/plugins/wp-crontrol/
rm -R 1.13.2.tar.gz wp-crontrol-1.13.2

Adjust the path to your WordPress accordingly, of course.

Here is a fix until a new version has been released:

cd /tmp
curl -LO https://github.com/johnbillion/wp-crontrol/archive/refs/tags/1.13.2.tar.gz
tar xf 1.13.2.tar.gz
mv wp-crontrol-1.13.2/vendor /var/www/wordpress/wp-content/plugins/wp-crontrol/
rm -R 1.13.2.tar.gz wp-crontrol-1.13.2

Adjust the path to your WordPress accordingly, of course.

• This reply was modified 2 years, 3 months ago by Micha.
• This reply was modified 2 years, 3 months ago by Micha.

This issue is that the newly introduced (in v1.13.0) wp-crontrol/vendor/autoload.php file is tried to be loaded but missing, the whole vendor directory.

Confusing is that the last two patch versions (1.13.1 and 1.13.2) were already about fixing missing files, obviously not this one, while it is so fundamentally crashing the plugin right when activating it.

Great. I’ll send an email then, when facing PHP8.1 related issues, until it is supported officially by WordPress and by Wordfence. Makes sense to not spam a support/bug tracker with unsupported setup/beta testing.

I’ll review more carefully before posting next time. Sorry for the extra moderation work.

Also WordPress itself does not officially support PHP8.1 but is working on it for WordPress v5.9. But as it doesn’t hurt to have PHP8.1 related issues collected or even resolved before its official release, I didn’t hesitate to report it. If there is a better place to do so, instead of a ticket here, please redirect me.

Best regards,

Micha

Subsequent edits of a topic trigger an automatic mark as spam? Please tune this algorithm…