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

[morganestes]

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.

[scotthack]

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?

[boonebgorges]

Thanks for reporting this, morganestes.

[boonebgorges]

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.

[boonebgorges]

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.

[morganestes]

Replying to boonebgorges:

Thanks for reporting this, morganestes.

Thanks for the quick turnaround on it.