Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#34091 closed defect (bug) (fixed)

Errors thrown after wp_termmeta table created but db updates not yet run

Reported by: morganestes's profile morganestes Owned by: boonebgorges's profile boonebgorges
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.4
Component: Upgrade/Install Keywords:
Focuses: Cc:


After [34529], a site that is auto-updated but hasn't had an admin user log in yet throws errors about a missing wp_termmeta table. If display errors are enabled on the site, visitors are shown a cryptic message that they can't do anything about.

[29-Sep-2015 03:38:15 UTC] WordPress database error Table 'wordpress_develop.wp_termmeta' doesn't exist for query SELECT term_id, meta_key, meta_value FROM wp_termmeta WHERE term_id IN (2,3,4,5,6,37,38,39,40,41,7,8,9,10,11,12,13,14,15,42,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,1,34,35,36) ORDER BY meta_id ASC made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/twentysixteen/index.php'), get_header, locate_template, load_template, require_once('/themes/twentysixteen/header.php'), wp_nav_menu, wp_get_nav_menu_items, get_terms, update_termmeta_cache, update_meta_cache

I tried switching themes and tried with Twenty Sixteen and Twenty Fifteen to rule out themes. I signed into /wp-admin/ and was prompted to update the database, which cleared the error message on the next page load.

If there's a way to prevent causing errors during the update/upgrade process when adding a new table, I think we should find it.

Change History (6)

#1 @scotthack
9 years ago

What is the purpose of the manual nature of logging into the backend to update the database? So there is a chance to back it up?

#2 @boonebgorges
9 years ago

  • Milestone changed from Awaiting Review to 4.4

#3 follow-up: @boonebgorges
9 years ago

Thanks for reporting this, morganestes.

#4 @boonebgorges
9 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 34718:

Bail out of termmeta functions if schema is not up-to-date.

Termmeta cache priming was throwing database errors on installations that had
not yet gone through the database update routine. To avoid errors in all cases,
the check has been added to all termmeta functions. These checks will be
removed in a future version of WordPress. (Hang on to your hats!)

Fixes #34091.

#5 @boonebgorges
9 years ago

In 34719:

Prevent Multisite term tests from hitting database for 'db_version'.

[34718] introduced a 'db_version' check to term meta functions, to ensure that
they don't run when the term meta schema is not yet in place. This call to
get_option() causes a database hit during Multisite tests, due to the
presence of the WP_INSTALLING constant. See #31130. The extra database
queries are causing cache tests to fail.

In similar cases, we have markTestSkipped() when is_multisite(). Because
the term meta API is so extensive - term meta caches can be primed anywhere a
WP_Query loop is fired up - we implement a more generous workaround in this
case. To prevent get_option( 'db_version' ) from hitting the database during
multisite unit tests, we use a 'pre_option_' filter.

Heaven help us.

See #34091.

#6 in reply to: ↑ 3 @morganestes
9 years ago

Replying to boonebgorges:

Thanks for reporting this, morganestes.

Thanks for the quick turnaround on it.

Note: See TracTickets for help on using tickets.