KZeni

@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. ??

@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?])

@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.

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.

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

@w8tts Ah, so manually updating the plugin to the latest version fixed the issue? It’d probably be good to mark this topic as resolved, if so. ??

@w8tts Huh? I suggested that you manually re-upload the plugin files and you just repeated what you just said before my message giving no further information regarding anything else I said other than how this should probably be mentioned in the Pro add-on’s support & how you posted the issue there…?

Hopefully the pro add-on’s support can help, but they might suggest the same thing you seem to have ignored here (make sure you’ve fully installed the latest version of everything using a method outside of WordPress for better reliability & feedback on individual details.)

@w8tts Have you tried re-uploading the files for both the free & Pro add-on plugins via (S)FTP or a hosting control panel to make sure there are no missing files? That might be the next step here.

If it’s confirmed that you’ve manually uploaded the latest files for both of these plugins & nothing’s missing (per what was used to upload these files giving no errors [something that WordPress’ plugin update feature doesn’t really surface by default]) and it’s still giving that same error, then I’d probably recommend reporting the issue via https://www.wpgmaps.com/forums/forum/pro-add-on/ to get that issue resolved via the Pro add-on’s support forum.

Btw, the main (free) plugin did receive 2 updates today (there was a bug that was happening with those running PHP 7.2.x that the subsequent release fixed) so you updating it to then update it again (while maybe a seeming a bit odd) likely has nothing to do with this issue. Seems like you just went through the normal plugin update process & simply encountered an error with the Pro add-on after doing so (the possibility that I explained of the plugin not finishing updating properly can also be more likely on some hosting environments when chaining together updates where one update might halt the other; again, shouldn’t really be a thing that happens as long as the hosting environment is adequate, but sometimes hosting setups simply aren’t ideal.)

Are you certain your updated version extracted all of the files properly? I’ve found that sometimes a plugin doesn’t finish installing/updating properly (or gets caught mid-update) to find it’s then wanting to call a function/etc. that’s missing due to the file that’s defined in currently being missing (usually most common when the website’s hosting environment interrupted the upgrade, it’s in the process of updating & that error was triggered with it then being okay once it finishes the update, or something similar to that.)

Also, it’s probably worth noting that this error seems to be regarding the Pro add-on rather than the specific plugin here (free plugin) per the folder name & things mentioned in the error details of where the undefined method was called from (“wp-google-maps-pro/includes/3rd-party-integration/class.pro-gutenberg.php” on line 28 with it also calling “ProGutenberg” which also points to what’s being called & is missing as something that’s likely entirely within the Pro add-on [it 100% isn’t in the free version’s code anywhere.])

While I don’t have the latest version of the Pro add-on to test at the moment, myself, I’d be somewhat surprised if this error is larger than it just not finishing updating/installing properly given your specific website’s hosting environment/setup since trying to call something that’s undefined really isn’t something that should be conditional (would be encountered by everyone when that code’s executed) nor able to slip through into an officially released version (any amount of testing should’ve found it to then be fixed before release unless that code is really only ever tried to be used in rare situations.) Compared to the larger possibility that your hosting might’ve just had a hiccup that caused an issue (files for the plugin were left as missing) that just happened to occur with this one plugin for any number of reasons your hosting provider would need to then look into (very specific to a given hosting provider/setup where some never encounter anything like this while others are much more likely [then usually no fault of the plugin it happened with] due to any number of factors.)

If that doesn’t turn out to be the problem (making sure it fully uploaded/extracted all of the Pro add-on’s files), you might find better results in going to https://www.wpgmaps.com/forums/forum/pro-add-on/ and mentioning the issue there as that’s the support forum that’s dedicated to those that have purchased the Pro add-on to discuss things in further detail for Pro-specific support.

Are you making sure to regenerate image assets after making these changes?

Previously uploaded images don’t immediately follow any image size adjustments (nor would it if an image size was added via WordPress’ add_image_size() function [which is what this uses behind the scenes & is just surfacing in a more user-friendly way.]) This is a reason why plugins like Regenerate Thumbnails Advanced (among others) exist so that image size additions/adjustments can then be offered by any/all images with that latest image size setup.

One can see at https://github.com/99robots/99robots-custom-image-sizes/blob/9d9bfbea9940b4df7739a1907aa7fe468759de14/views/settings.php#L66C13-L66C13 as well as https://github.com/99robots/99robots-custom-image-sizes/blob/9d9bfbea9940b4df7739a1907aa7fe468759de14/99robots-custom-image-sizes.php#L176 that it really is just passing the crop setting along to WordPress’ standardized add_image_size() function (https://developer.www.ads-software.com/reference/functions/add_image_size/) with it providing things like “Center Center” along as an array for the x & y value as add_image_size would expect (or otherwise true/false for yes/no, respectively.) Again, this really is just passing your settings along to WordPress’ core functionality to then do the heavy lifting (with this then providing the settings in the way WP expects so any issue like that doesn’t seem like an issue with this plugin.)

As such, I’m a bit confused why this wouldn’t be working unless your site’s add_image_size isn’t working for some reason, if there was some user error in not regenerating the images after making adjustments, there’s a misunderstanding of the underlying add_image_size() function’s crop settings, or something like that.

Definitely seems odd to then give a 1 star review with it seeming like it’s one of those cases (also then seemingly to have not reached out via the Support Forum, GitHub, or elsewhere to bring this up as an issue to be resolved [rather than, again, oddly giving a 1 star review when it’s likely a matter of support/user error when one didn’t then reach out for support before giving this review; almost akin to a “I tried nothing and it still isn’t working” type of review when it seems like the issue legitimately has nothing to do with this plugin.])

Marking as resolved since the release of version 1.2.9 addressed this.

I’m thinking this topic could/should probably be marked as resolved per the most recent release (1.2.9) having removed that problematic timezone code.

https://github.com/99robots/99robots-custom-image-sizes/pull/8#issuecomment-1652109503 looks promising for a release with this fix being made available soon.

Well dang, it looks like version 3.9.7 released about a week ago didn’t include this fix so the site that was using this fixed version had the issue be re-introduced so I needed to re-patch it to stay on the up-to-date version (with it auto-updating to keep things up-to-date [which is fine for every other purpose] that meant a few users had their user role removed when their profile was updated due to this bug being re-introduced in the meantime.)

Again, I’d love to see this be patched in a future version that’s sooner than later since it’s a pretty bad bug (ex. imagine an admin updating their profile to find they no longer have a role on their site due to it removing their role when it’s not being changed & someone with the ability to change roles having updated their profile) when it’s a native feature of Profile Builder (telling it to not try to use multiple user roles per user which then has this update_profile bug.)

Thanks for the update! Things look to be behaving better with this update.