Fatal error in Util_Environment

Hello @prasunsen

Thank you for reaching out and I am happy to assist you with this.
Is the DB cluster enabled by any chance in your case? Can you please try to disable DB caching, save all settings, and then re-enable it again and save all settings?
Let me know if this helps!
Thanks!

Thank you @vmarko

We aren’t using the DB cluster option but will the suggested solution.

I’ve also just encountered this error across a bunch of sites that use Redis for DB, Object, etc. caching via W3TC.

My sites were all working fine until I updated to WordPress 6.3 today, and now they (while oddly not all sites [definitely the majority, though] even though their setups are effectively the same since a more recently built site on that same exact hosting with effectively the same W3TC settings seems to be working okay) are giving this error that’s more or less what’s mentioned above of:

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function W3TC\\Util_Environment::is_dbcluster(), 0 passed in wp-content/db.php on line 56 and exactly 1 expected in wp-content/plugins/w3-total-cache/Util_Environment.php:176
Stack trace:
#0 wp-content/db.php(56): W3TC\\Util_Environment::is_dbcluster()
#1 wp-includes/load.php(666): require_once('/usr/local/apac...')
#2 wp-settings.php(124): require_wp_db()
#3 wp-config.php(99): require_once('/usr/local/apac...')
#4 wp-load.php(50): require_once('/usr/local/apac...')
#5 wp-admin/upgrade.php(18): require('/usr/local/apac...')
#6 {main} thrown in wp-content/plugins/w3-total-cache/Util_Environment.php on line 176

Huh… I’m wondering if this wp-content/db.php file was given a revision at one point so that line 56 of:

if ( ( ! $is_installing && $config->get_boolean( 'dbcache.enabled' ) ) || \W3TC\Util_Environment::is_dbcluster() ) {

became:

if ( ( ! $is_installing && $config->get_boolean( 'dbcache.enabled' ) ) || \W3TC\Util_Environment::is_dbcluster( $config ) ) 

with the rest of the file staying as-is (comparing my one newer site that didn’t encounter this issue to older ones that did, this addition of $config to is_dbcluster() on this one line was the only difference.)

However, while this db.php file was write-enabled by the web server process, it seems like this revision to the db.php file wasn’t ever pushed out for sites that previously had them created before this was added. That then became problematic with the various changes (probably performance-related changes) in WordPress 6.3 (causing a fatal error on these sites missing this one parameter after updating when trying to then access the site admin, etc.)

Thankfully, it seems that simply updating this wp-content/db.php file to include this update to that one line resolves the issue (would be good to confirm if this is also the case for others)!

Not sure why this change to this file didn’t get pushed out until I do it manually to address a fatal error, though. I figure it would be better late than never to have a future W3TC update enforce making this change present in the db.php file on sites that might’ve generated that file before it was included (then having this be done for future updates to files like this.)

On that note, it seems like W3TC version 2.4.0 made note of this per its “Fix: Database Cluster configuration file save issue” changelog detail which seems to go back to https://github.com/BoldGrid/w3-total-cache/commit/4378f17dcd0c60a506db32d71bdba112fd3a11ea as the associated commit, but I had sites update to that version of W3TC ~5 days ago that didn’t ever get that added to their wp-content/db.php file (does/did it need to have someone re-save the W3TC settings manually to then have it take effect [or something] which then never happened on these sites so the issue persisted?) where it then lead to this fatal error upon updating these sites to WP 6.3.

Man you saved me! I’ve got the same error. I was missing the $config variable in db.php.

Added, everything works again.

Thank you

@xholicka Glad to hear my proposed fix also worked for you (technically it’s W3TC’s fix that just didn’t get fully propagated for everyone in the 2.4.0 update for whatever reason.) Sometimes something so small can make all the difference, hah.

Hello!

We had forgotten to turn off automatic WP core upgrade, and when it automatically upgraded WP to version 6.3, the same error occurred when logging in to the administrator and WP tried to upgrade DB:

thrown in /var/www/mysite.com/wp-content/plugins/w3-total-cache/Util_Environment.php on line 176" while reading response header from upstream, client: 111.111.111.111, server: mysite.com, request: "POST /wp-admin/upgrade.php?step=upgrade_db HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.4-fpm.mysite.sock:", host: "mysite.com"
2023/08/09 03:15:47 [error] 2845037#2845037: *171636 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function W3TC\Util_Environment::is_dbcluster(), 0 passed in /var/www/mysite.com/wp-content/db.php on line 56 and exactly 1 expected in /var/www/mysite.com/wp-content/plugins/w3-total-cache/Util_Environment.php:176
Stack trace: 0 /var/www/mysite.com/wp-content/db.php(56): W3TC\Util_Environment::is_dbcluster() 1 /var/www/mysite.com/wp-includes/load.php(666): require_once('/var/www/mysite…') 2 /var/www/mysite.com/wp-settings.php(124): require_wp_db() 3 /var/www/mysite.com/wp-config.php(101): require_once('/var/www/mysite…') 4 /var/www/mysite.com/wp-load.php(50): require_once('/var/www/mysite…') 5 /var/www/mysite.com/wp-admin/upgrade.php(18): require('/var/www/mysite…') 6 {main}

And of course, the quick fix was to log into the server, check what’s causing the error and to rename/remove w3-total-cache plugin folder and wp-content/db.php , wp-content/advanced-cache-2.php, wp-content/object-cache-2.php .

• This reply was modified 1 year, 3 months ago by martinsdzerve.
• This reply was modified 1 year, 3 months ago by martinsdzerve.
• This reply was modified 1 year, 3 months ago by martinsdzerve.

Hi @kzeni

Thanks for the solution, after implementing the above suggestion now the problem is solved.

thank you again

Hello @shantanu198713 @martinsdzerve @kzeni @xholicka

Thank you for your feedback and for confirming the solution.
Please make sure to either disable DB caching, save all settings, and then re-enable it again and save all settings, or simply delete the db.php file which will then be automatically created again by the W3TC.

Thanks!

Adding $config to line 56 as described by @kzeni worked well for me too. You’ve saved me untold stress. Many thanks!

• This reply was modified 1 year, 3 months ago by tomfoley.

Hello @prasunsen @tomfoley @shantanu198713 @martinsdzerve @kzeni @xholicka

We have just released the W3 Total Cache 2.4.1
Please make sure to update the plugin to the latest version.

Once again, thank you all for reporting this and for your patience!

Thanks!

@prasunsen Can we consider this topic resolved?

@vmarko Thanks for the update! I see the 2.4.1 release changelog mentions the addition of a fallback for the older wp-content/db.php file so at least it doesn’t cause a fatal error when a site’s caught using the older version of that file still.

That said, is there / could there be a way to help ensure that sites are using the updated wp-content/db.php file as soon as a change was made (and possibly the same thing goes for similar files that might need to be updated now and/or in the future) to avoid continually needing fallbacks & needing to account for this if it ever has something similar happen in the future?

I wonder if it could be handled similarly to how some database updates happen on plugins where a change needs to be made outside of the plugin itself so it then either does it upon update/install of the plugin automatically (then only notifying if the auto-update failed) or has a notice in the site admin telling administrators they should manually press a button when they feel it’s safe to do so to then perform that action (only this would be for a file update [effectively re-save W3TC settings if that results in files like this to be updated] rather than a database update, in this case, while the rest of it seems like it could actually be kinda similar; I’m somewhat leaning on the former of it not needing a prompt to manually do it if it’s lightweight enough of a task & it just does it upon the update/install of that plugin version [while then maybe then showing the prompt to do it manually if it doing so automatically failed due to write permissions or something like that where it sees any of W3TC’s config/files are still using an older version.])

Currently, it’s kinda like there was a database update made to a plugin, but it’s indefinitely pending on their site since it wasn’t automatically applied nor does one know about it to manually accommodate it. Only those that either recently fresh-installed the plugin or happened to have manually re-saved the settings then get things upgraded as an unknown side-effect of their action (which those that have set their settings & no longer need to make changes likely won’t be doing.) This doesn’t seem all that great since some sites could be getting plugin updates & things while just not re-saving their settings or anything like that to find they’re still using the old setup for much longer than it probably should (making older versions of files like this able to linger probably longer than they probably should.)

Just an idea. Also, this could already be doing this or has accommodated this in a different way that I’m just not fully aware of (it was just a bit surprising to see that I had W3TC fully up-to-date on sites [running 2.4.0 for multiple days at that point] to then find my sites were crashing after the WP 6.3 update due to a file W3TC generates & manages was not up-to-date on the vast majority of these sites [again, the fallback added in 2.4.1 is better than a fatal error, but it does still seem weird to have the reason the fallback is even needed is still potentially happening… why not, as the plugin that created & manages files like this one, have it so an update also makes sure these files are updated so fallbacks like this one are much less necessary?])

@kzeni sounds like that, thanks!

Hello @kzeni

Thank you for your feedback and your suggestion.
Yes, this is the idea moving forward. There are some problems we may encounter, and we still we need to keep compatibility.
Plugins may update without being active, permissions may be locked, wp may be deployed from repo and those files kept as “fixed”…
This is a lesson to learn and moving forward we will make sure that any other files that may be updated in the future do not cause issues like this or similar.

Thank you again for your feedback and suggestion.

Thanks!

@vmarko Ah, very good points to consider. Thanks for the update regarding that approach, and it’s nice to hear it’s being taken into consideration. ??