Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#46167 closed defect (bug) (fixed)

Network update does not create wp_blogmeta table

Reported by: waryn's profile waryn Owned by: flixos90's profile flixos90
Milestone: 5.1.2 Priority: normal
Severity: major Version: 5.1
Component: Networks and Sites Keywords: has-patch fixed-major
Focuses: multisite Cc:

Description

Can't update to 5.1 beta on multisite (localhost testing).

WordPress database error: [Table 'wpdev.wp_blogmeta' doesn't exist] SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (1) ORDER BY meta_id ASC

### WordPress ###

Version: 5.0.3
Language: en_US
Permalink structure: /blog/%year%/%monthnum%/%day%/%postname%/
Is this site using HTTPS?: No
Can anyone register on this site?: Yes
Default comment status: open
Is this a multisite?: Yes
User Count: 58
Site Count: 1
Network Count: 1
Communication with WordPress.org: WordPress.org is reachable
Create loopback requests: The loopback request to your site completed successfully.

### Installation size ###

Uploads Directory: 16.84 GB
Themes Directory: 2.08 GB
Plugins Directory: 494.77 MB
Database size: 14.34 MB
Whole WordPress Directory: 23.07 GB
Total installation size: 23.08 GB

### Must Use Plugins (1) ###

Health Check Troubleshooting Mode: Version 1.5.0

### Active Plugins (13) ###

Column Shortcodes: Version 1.0 by Codepress
Disable Comments: Version 1.8.0 by Samir Shah
Health Check & Troubleshooting: Version 1.2.5 by The WordPress.org community
Page Restrict: Version 2.2.8 by Matt Martz & Andy Stratton
Post Meta Inspector: Version 1.1.1 by Daniel Bachhuber, Automattic
Query Monitor: Version 3.2.2 by John Blackbourn & contributors
SQL Executioner: Version 1.4 by Justin Watt
Vulnerable Plugin Checker: Version 0.3.12 by Storm Rockwell
WordPress Importer: Version 0.6.4 by wordpressdotorg
WP-Optimize: Version 2.2.11 by David Anderson, Ruhani Rabin, Team Updraft
WP Add Custom CSS: Version 1.1.4 by Daniele De Santis

### Inactive Plugins (1) ###

WordPress Beta Tester: Version 1.2.6 by Peter Westwood

### Media handling ###

Active editor: WP_Image_Editor_GD
Imagick Module Version: Imagick not available
ImageMagick Version: Imagick not available
GD Version: bundled (2.1.0 compatible)
Ghostscript Version: Not available

### Server ###

Server architecture: Darwin 18.2.0 x86_64
Web Server Software: Apache/2.2.34 (Unix) mod_wsgi/3.5 Python/2.7.13 PHP/7.2.10 mod_ssl/2.2.34 OpenSSL/1.0.2o DAV/2 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.9 Perl/v5.24.0
PHP Version: 7.2.10 (Supports 64bit values)
PHP SAPI: apache2handler
PHP max input variables: 1000
PHP time limit: 30
PHP memory limit: 256M
Max input time: 60
Upload max filesize: 32M
PHP post max size: 8M
cURL Version: 7.60.0 OpenSSL/1.0.2o
SUHOSIN installed: No
Is the Imagick library available: No
htaccess rules: Your htaccess file only contains core WordPress features

### Database ###

Extension: mysqli
Server version: 5.7.23
Client version: mysqlnd 5.0.12-dev - 20150407 - $Id: 38fea24f2847fa7519001be390c98ae0acafe387 $
Database prefix: wp_

### WordPress Constants ###

WP_HOME: Undefined
WP_SITEURL: Undefined
WP_DEBUG: Enabled
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG_DISPLAY: Enabled
WP_DEBUG_LOG: Enabled
SCRIPT_DEBUG: Enabled
WP_CACHE: Disabled
CONCATENATE_SCRIPTS: Enabled
COMPRESS_SCRIPTS: Enabled
COMPRESS_CSS: Enabled
WP_LOCAL_DEV: Enabled

### Filesystem Permissions ###

The main WordPress directory: Writable
The wp-content directory: Writable
The uploads directory: Writable
The plugins directory: Writable
The themes directory: Writable
The Must Use Plugins directory: Writable

Attachments (4)

blogmeta_issue.gif (2.2 MB) - added by xkon 5 years ago.
Preview of blogmeta issue
46167.0.diff (419 bytes) - added by vanyukov 5 years ago.
check WP_INSTALLING
46167.1.diff (497 bytes) - added by spacedmonkey 5 years ago.
46167.2.diff (622 bytes) - added by spacedmonkey 5 years ago.

Change History (56)

This ticket was mentioned in Slack in #core by waryn. View the logs.


5 years ago

#2 @desrosj
5 years ago

  • Focuses multisite added
  • Milestone changed from Awaiting Review to 5.1

This ticket was mentioned in Slack in #core-multisite by desrosj. View the logs.


5 years ago

#4 @desrosj
5 years ago

  • Keywords close added

Hey @waryn, thanks for this very detailed ticket!

As I mentioned in #core-multisite, I am unable to reproduce the issue that you are describing. To add to the details above, @maryn had performed the update using the beta tester plugin.

I am going to leave this open for visibility just in case someone else also encounters this issue, but I think that this was either a botched upgrade, or the attempted upgrade may have happened when the nightlies were being rebuilt, or something similar.

This ticket was mentioned in Slack in #core-multisite by desrosj. View the logs.


5 years ago

#6 @desrosj
5 years ago

  • Keywords close removed
  • Milestone 5.1 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

I am going to close this one out. I am still not able to reproduce the issue, and after discussing it in #core-multisite, it seemed that no one else has encountered the issue in there testing.

This ticket was mentioned in Slack in #core by desrosj. View the logs.


5 years ago

#8 @xwolf
5 years ago

  • Resolution worksforme deleted
  • Severity changed from blocker to major
  • Status changed from closed to reopened

Hi,

i just updated my local WP 5.0.3 installation to 5.1 and got that error notice, which was described above, too:

table  'mytestsite-wp.wp_blogmeta' doesn't exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (9) ORDER BY meta_id ASC

I rerun the update and also rerun the upgrade process fro all registered multisites, bit it doesn't chance: The new table was not created.
The error message was also prompted during the update process.
Deactivating all plugins, including the he multisite plugin, did not help.

My wp-config.php looks normal:


define( 'WP_ALLOW_MULTISITE', true );
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'mysite.somewhere');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

I also deactivated multisite and rerun the update process then. Then I activated multisite again.
At this point I would expect, that once i save the network settings, at least then the new table would be generated. But this also didnt happen..

Cause it doesnt affect the sites itself (they are working) and I cannot detect any failure beneath the debug message yet, i think the severity is not that high.

#9 @bogdanguenther
5 years ago

Hi everyone,

I after updating three WP multisite installs from 5.0.3 to 5.1 I am getting the same database error in my log:

'db393191_10.wp_blogmeta' doesn't exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (1) ORDER BY meta_id ASC

Reinstalling WP 5.1 didn't help.

#10 @duttoluca
5 years ago

Same here, upgrading my local multisite wp installation to 5.1 doesn't create wp_blogmeta table.
Reinstalling 5.1 and doing a network upgrade didn't help.

PHP Notice:  wp_check_site_meta_support_prefilter è stato richiamato <strong>in maniera scorretta</strong>. La tabella wp_blogmeta non è stata installata. Esegui l'upgrade del database del network. Leggi <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in WordPress</a> per maggiori informazioni. (Questo messaggio è stato aggiunto nella versione 5.1.0.) in C:\xampp2\htdocs\wpa_test_multi\wp-includes\functions.php on line 4667
WordPress errore sul database Table 'wpa_multi_test.wp_blogmeta' doesn't exist per la query SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (1) ORDER BY meta_id ASC fatta da require_once('wp-admin/network/admin.php'), require_once('wp-admin/admin.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), require('wp-includes/ms-settings.php'), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

#11 @desrosj
5 years ago

  • Milestone set to 5.1.1

This ticket was mentioned in Slack in #core-multisite by desrosj. View the logs.


5 years ago

#13 @captainbri
5 years ago

Happens on my local dev as well.

[22-Feb-2019 16:17:54 UTC] WordPress database error Table 'localwp.wp_blogmeta' doesn't exist for query SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (14) ORDER BY meta_id ASC made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), require('wp-includes/ms-settings.php'), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

#14 @pbiron
5 years ago

It has now happened to me, when updating from 5.0.3 to 5.1 from wp-admin/network/upgrade-core.php (i.e., not via wp-cli, the wp-beta-tester plugin, etc).

I've tried several more times but haven't been able to get it to happen again after that one time.

Luckily, the one time it did happen I was actually stepping through the upgrade process in a debugger (not an easy task, since the line numbers where you have breakpoints set change when the new files get copied over :-).

As this was the first time I really followed what happens during a core update, I think I stepped over the part that actually caused the blogmeta table to not be created. But, as far as I could tell, somewhere before L2593 in dbDelta() $cqueries ended up as an empty array...rather than containing the CREATE TABLE statement that is supposed to create the blogmeta table.

As far as I can tell, I did not have any plugins active that hook into dbdelta_queries or dbdelta_create_queries, which is the only way I can see for $cqueries to be empty.

Hopefully, this will help someone else find the problem.

#15 follow-up: @pento
5 years ago

Thanks for the debugging, @pbiron!

I'm wondering if the table isn't being created due to wp_should_upgrade_global_tables() return false.

This could happen in one of the following circumstances:

  • The DO_NOT_UPGRADE_GLOBAL_TABLES constant is defined.
  • The upgrade was initiated from a network other than the main network.
  • The upgrade was initiated from a site other than the main site.

#16 in reply to: ↑ 15 @pbiron
5 years ago

Replying to pento:

I'm wondering if the table isn't being created due to wp_should_upgrade_global_tables() return false.

This could happen in one of the following circumstances:

  • The DO_NOT_UPGRADE_GLOBAL_TABLES constant is defined.

That was not defined (I didn't even know it existed, and I just checked, none of the plugins on the site had defined it).

  • The upgrade was initiated from a network other than the main network.

There was only 1 network.

  • The upgrade was initiated from a site other than the main site.

There was only 1 site in that one network. It used to be a single site (on my local dev machine). Since I needed to upgrade it, I figured I'd turn it into a multisite first so that I could try to debug this ticket.

Like I said, I think the upgrade process didn't even execute the line with wp_should_upgrade_global_tables() because $cqueries was already an empty array a few lines above that. I say "I think" because my memory of stepping through the code is a little fuzzy at this point.

#17 @Tim Reeves
5 years ago

Several users have noticed this problem and started a support thread https://wordpress.org/support/topic/not-creating-table-wp-blogmeta/#post-11243776.

#18 follow-up: @Joseba286
5 years ago

Same issue and my site is down for days. Any solution?

Can someone please get the SQL query to manually create the missing table?

#19 in reply to: ↑ 18 ; follow-up: @captainbri
5 years ago

Replying to Joseba286:

Same issue and my site is down for days. Any solution?

Can someone please get the SQL query to manually create the missing table?

temporarily you can replace the wp-includes and wp-admin folders with an older version to get your site back up.

#20 @spacedmonkey
5 years ago

I think there is an issue around the fact the check if table exists is in wp_check_site_meta_support_prefilter. This filter is only applied in ms-default-filters.php which is loaded pretty late in the bootstrap process. get_site_by_path is very early in the bootstrap process. So the wp_check_site_meta_support_prefilter is not in place, generating this error.

The function update_sitemeta_cache need to be an updated with a call to is_site_meta_supported()

function update_sitemeta_cache( $site_ids ) {
        if ( ! is_site_meta_supported() ) {
                /* translators: %s: database table name */
                _doing_it_wrong( __FUNCTION__, sprintf( __( 'The %s table is not installed. Please run the network database upgrade.' ), $GLOBALS['wpdb']->blogmeta ), '5.1.0' );
                return false;
        }
        return update_meta_cache( 'blog', $site_ids );
}

Looping in @flixos90

#21 in reply to: ↑ 19 @Joseba286
5 years ago

Replying to captainbri:

Replying to Joseba286:

Same issue and my site is down for days. Any solution?

Can someone please get the SQL query to manually create the missing table?

temporarily you can replace the wp-includes and wp-admin folders with an older version to get your site back up.

Ok thanks, done that.

This ticket was mentioned in Slack in #core-multisite by andraganescu. View the logs.


5 years ago

#23 @andraganescu
5 years ago

not much help, but on a clean local VVV based wp 5.0.3 install, configured for multisite, clean, everything default, the upgrade to 5.1 works perfectly. No error and the wp_blogmeta is there all empty.

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


5 years ago

#25 @spacedmonkey
5 years ago

  • Component changed from Upgrade/Install to Networks and Sites
  • Keywords needs-patch added

Regarding my point above, I have created another ticket regarding the priming of site meta caches. See #46357

This ticket was mentioned in Slack in #core by lukecarbis. View the logs.


5 years ago

#27 follow-up: @jeremyfelt
5 years ago

I've stepped through the code looking for a way to reproduce this and so far have had no luck unless I prevent it by making wp_should_upgrade_global_tables() return false.

I'm going to talk through this just in case I'm missing something.

Setup fresh site:

  1. wp db drop && wp db create && rm wp-config.php
  2. wp core download --version=5.0.3 --force
  3. wp core config ...
  4. wp core install ...
  5. wp core multisite-convert

Upgrade from 5.0.3 to 5.1:

  1. Go to wp-admin/ and click "Please update now" (wp-admin/network/update-core.php).
  2. Click "Update Now" to update to WordPress 5.1.
  3. Success, redirected to wp-admin/network/about.php.
  4. Click "Upgrade Network" (wp-admin/network/upgrade.php).
  5. Click "Upgrade Network".... All done!

The wp_blogmeta table now exists as expected.

Ways I can get wp_blogmeta to not be created after running the upgrade routine:

  1. Define DO_NOT_UPGRADE_GLOBAL_TABLES as true.
  2. Filter wp_should_upgrade_global_tables to false.
  3. Make wp_should_upgrade_global_tables() fail in some other way.
  4. Not GRANT CREATE privileges to the WP database user (unlikely).

I'm not seeing where a bug would be here.

There's a good chance in some cases that people are seeing the PHP notice just because they haven't yet updated all sites on the network. As @spacedmonkey highlighted, we should take care of that notice.

For the rest, we need to figure out what the reason is for the database table not being created, even after running the routine at wp-admin/network/upgrade.php.

#28 in reply to: ↑ 27 @xwolf
5 years ago

Replying to jeremyfelt:

There's a good chance in some cases that people are seeing the PHP notice just because they haven't yet updated all sites on the network. As @spacedmonkey highlighted, we should take care of that notice.

This was my first thought too. But upgrading the network (even more as one time) didn't change anything, as i mentioned above in my comment 8. :(

#29 @johnbillion
5 years ago

Could a failure occur silently if the database user doesn't have permission to create a new table?

#30 @johnbillion
5 years ago

For those of you experiencing this issue:

  • Are there any errors appearing in your PHP error log?
  • Can you provide your PHP and MySQL/MariaDB versions?

@xkon
5 years ago

Preview of blogmeta issue

#31 @xkon
5 years ago

@johnbillion , I could reproduce the error everytime with 100% "success" on my end with some really easy steps:

1] Install a 5.0.3 multisite ( no need to have subsites etc ).
2] Enable debugging to keep logs.
3] Start the Update process.

The error occurs as soon as Maintenance mode is disable and the DB updater starts to run.

On this machine I'm using PHP 7.2.11 & MySQL 5.7.24 and the SQL user has full access as well. I'm managing various live sites and I did a research on all of the installations that where updated & had debugging on and I could see the error on all of them so PHP/SQL versions most likely are not relevant here. I hadn't even noticed it until I saw this ticket :D .

Since the error spanws at exactly that point of the Update process, I couldn't see anything broken either as it might be a minor error due to the update process itself. If there's no debugging as well since there are no other problems after the update is actually finished and the table exists not many might've noticed this especially if debugging is off.

You can easily see when the error happens in the blogmeta_issue.gif (sorry for the gif being big-ish but it's the easiest way to showcase this :) ).

I hope this helps a bit!

*Edit:*
Also just as a note, on my case the table is actually always created spawning the error only 1 time, after that everything is as supposed to be. I couldn't reproduce a way of not creating the table at all.

Last edited 5 years ago by xkon (previous) (diff)

This ticket was mentioned in Slack in #core by pbiron. View the logs.


5 years ago

@vanyukov
5 years ago

check WP_INSTALLING

#33 @vanyukov
5 years ago

  • Keywords has-patch added; needs-patch removed

Maybe we can check for 'WP_INSTALLING' before calling update_sitemeta_cache()? The table will be created once the installation finishes. But it seems the update_site_cache() is called prior to the upgrade scripts.

Last edited 5 years ago by vanyukov (previous) (diff)

#34 follow-up: @pbiron
5 years ago

It seems to me that 46167.0.diff and the suggestion in comment 20 are just bandaids and don't solve the underlying problem.

In fact, I wonder how many people would have noticed that the wp_blogmeta table wasn't created on update if the error messages weren't being displayed.

#35 @lukecarbis
5 years ago

  • Milestone changed from 5.1.1 to 5.2

Looks like this ticket warrants a little more discussion. I don't want to rush it for the 5.1.1 RC tomorrow.

#36 @captainbri
5 years ago

Maybe others were not clear, but after the multi site upgrade process we get a 500 error and the sites no longer display. I dont have the same issue on single site installs.

#37 in reply to: ↑ 34 @vanyukov
5 years ago

Replying to pbiron:

In fact, I wonder how many people would have noticed that the wp_blogmeta table wasn't created on update if the error messages weren't being displayed.

But the table is created on update. It's just the order of things how it's happening.
The wp-admin/upgrade.php script bootstraps WordPress

/** Load WordPress Bootstrap */
require( dirname( dirname( __FILE__ ) ) . '/wp-load.php' );

prior to running the db upgrade

wp_upgrade();

#38 follow-up: @johnbillion
5 years ago

@Joseba286 @captainbri You've both mentioned that this causes your site to go down with a 500 error. Can you find the corresponding fatal error message in your PHP error log please?

@spacedmonkey
5 years ago

#39 @spacedmonkey
5 years ago

In 46167.1.diff I check to see if site meta is supported before priming the cache. This is because this function can be called from anywhere.

@spacedmonkey
5 years ago

#40 follow-up: @spacedmonkey
5 years ago

After a chat with @flixos90 , I have updated the patch. In 46167.2.diff we force the wp_check_site_meta_support_prefilter filter to be applied, to make sure that it is applied.

#41 in reply to: ↑ 40 ; follow-up: @vanyukov
5 years ago

Replying to spacedmonkey:

After a chat with @flixos90 , I have updated the patch. In 46167.2.diff we force the wp_check_site_meta_support_prefilter filter to be applied, to make sure that it is applied.

Both of your solutions add 2 extra queries which will be executed on every page load to fix an issue that happens only on WordPress update from 5.0.3 to 5.1

#42 in reply to: ↑ 41 @flixos90
5 years ago

Replying to vanyukov:

Both of your solutions add 2 extra queries which will be executed on every page load to fix an issue that happens only on WordPress update from 5.0.3 to 5.1

What do you mean by 2 extra queries? Site meta not being supported is a consideration that needs to be accounted for throughout, some sites may not run the network update for a long time. Doing one extra check for whether the filter already exists doesn't add significant overhead.

Regarding the approach, I prefer 46167.2.diff - although a direct function call certainly seems more elegant, we introduced those filters in #44467 and #45091 to get rid of exactly this. Hooking the filter in on the fly helps clarifying to someone reading the code that filters should be used here.

#43 @spacedmonkey
5 years ago

I have updated a patch on #46357 that will help with this issue. Not know should be part of this ticket.

#44 @miekedm
5 years ago

Hello,

I have the same issue on updating to 5.1
This is part of the error message

support_prefilter was called incorrectly. The pcf_blogmeta table is not installed. Please run the network database upgrade.

How should I resolve this ?

thanks

This ticket was mentioned in Slack in #core by lukecarbis. View the logs.


5 years ago

#46 @spacedmonkey
5 years ago

  • Milestone changed from 5.2 to 5.1.2
  • Owner set to flixos90
  • Status changed from reopened to assigned

After a little more research, this error is happening in get_site_by_path function. This is because the checks for site meta table exists happen in filters, which are applied much later in the bootstrap process.

To fix this issue, both of these patches 46167.2.diff and 46357.diff should merged together and be part of 5.1.2.

Assigning to @flixos90 to merge.

#47 in reply to: ↑ 38 @malithmcr
5 years ago

Here is what I have if this could help:

WordPress database error Table ‘malith_wordpress_prod.wp_blogmeta' doesn't exist for query SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (1) ORDER BY meta_id ASC made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), require('wp-includes/ms-settings.php'), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

Replying to johnbillion:

@Joseba286 @captainbri You've both mentioned that this causes your site to go down with a 500 error. Can you find the corresponding fatal error message in your PHP error log please?

#48 @flixos90
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 44925:

Multisite: Ensure site meta caches are not primed unless the wp_blogmeta table is available.

Prior to this change, querying sites early in the bootstrap process could potentially cause a fatal error, since at that stage the filter to bail on updating site meta cache if the respective database table has not been installed yet is not hooked in yet. This changeset forces the filter to be added if that is not already the case.

Props spacedmonkey.
Fixes #46167.

#49 @flixos90
5 years ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

#50 @flixos90
5 years ago

In 44926:

Multisite: Do not prime site meta caches unless necessary.

Props spacedmonkey.
Fixes #46357. See #46167.

#51 @flixos90
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 44927:

Multisite: Ensure site meta caches are not primed unless the wp_blogmeta table is available.

Prior to this change, querying sites early in the bootstrap process could potentially cause a fatal error, since at that stage the filter to bail on updating site meta cache if the respective database table has not been installed yet is not hooked in yet. This changeset forces the filter to be added if that is not already the case.

Merges [44925] to the 5.1 branch.

Props spacedmonkey.
Fixes #46167.

#52 @flixos90
5 years ago

In 44928:

Multisite: Do not prime site meta caches unless necessary.

Merges [44926] to the 5.1 branch.

Props spacedmonkey.
Fixes #46357. See #46167.

Note: See TracTickets for help on using tickets.