Value type mismatch on is_site_meta_supported function

[lucascarvalhopl]

The function is_site_meta_supported on line 6249 retrieves the value from the database without any type correction.

The value saved enters as integer from update_network_option function and is retrieved as a string containing the value "0" or "1" so the if false in line 6250 doesn't work.

I'f for some reason the table was not created at multisite install and this functions runs, the function will start to retrieve false every time.

The fix for it is just add a type adjust in line 6249 to set the $supported as a bool.

[TimothyBlynJacobs]

Thanks for the ticket and welcome to trac @lucascarvalhopl!

I believe that's intentional. What the code is trying to do is check if a value has not been set at all for the option, in which case the third parameter, $default is returned instead. This will pass the strict equality check. Then, the option will be written to at which point that branch will no longer execute.

[lucascarvalhopl]

Hi @TimothyBlynJacobs,
Thanks for your feedback.

I believe it's in fact a bug as the intention of this check is ensure that the table wp_blogmeta was created before use.

If this check runs just once the miss of this table will persist forever if does not exist at first run, even if we create him.

It's an edge case but if you search about you can see that this is an error since 5.1 wen this table was introduced. It's perhaps not the full fix of this as I do not check if the table was created after run multisite upgrade, but even after run the multisite upgrade tool the problem still persists.

[SergeyBiryukov]

Introduced in [42836] / #37923.

Replying to lucascarvalhopl:

If for some reason the table was not created at multisite install and this functions runs, the function will start to retrieve false every time.

Looking at the function description:

This function checks whether the 'blogmeta' database table exists. The result is saved as a setting for the main network, making it essentially a global setting. Subsequent requests will refer to this setting instead of running the query.

It seems like this is indeed how it was intended to work.

I suppose that when the blogmeta table is eventually created, the site_meta_supported network option should be cleared and updated, like it's done in upgrade_network()​.

[lucascarvalhopl]

Thank you for your review @SergeyBiryukov.

As you've described, this is actually the intended behavior in this function, so I'll consider this as invalid.

However, allow me to kindly disagree with this behavior as it can create some issues in some cases like ​this on StackExchange or ​this on WP Support. While it is actually more efficient and possibly safer for a well-designed plugin to do this check, fix the problem if it exists and set the option correctly.

[desrosj]

I agree with closing this out as the function is working as intended.

I'm having a hard time understanding what is actually wrong here or why these _doing_it_wrong() warnings should be suppressed. In these instances, it seems like these users have encountered an incomplete update resulting in the missing database table.

The first time this function runs, it will correctly set site_meta_supported as 0 (type doesn't matter really matter), skipping the update in the conditional. Any functions that attempt to use the feature will correctly result in debug messages.

I did some testing and this is what I found:

• Installed a new multisite site using 5.0.
• Updated to version 5.1.
• Ran the network upgrade.
• Checked and the blogmeta table was created correctly.

If someone encounters this issue, the best remedy is to:

• delete the site_meta_supported meta key from the wp_sitemeta table.
• Re-run the upgrade network script in the admin.

This correctly adds the table that was missing, and the next time it's needed, will flag site_meta_supported as 1 in the database.

If there are specific scenarios in Core where the lack of a blogmeta table is not failing gracefully, then please open a ticket detailing steps to take to reproduce. But in general, any multisite >= WP 5.1 should have the table unless an incomplete upgrade was encountered or the site owner explicitly chose to set site_meta_supported to 0 to prevent the table from being created.