Need to define 'MULTISITE' constant in wp-config.php
While debugging the WebAuthn plugin database prefix problem in #16245, I found out that we have never set the following line in our
define( 'MULTISITE', true );
This explains why our main site's database tables are prefixed with
wp_1_ rather than just
wp_. See https://github.com/WordPress/WordPress/blob/c70a5c547f187e3a8c58779ae18155874cb412df/wp-includes/wp-db.php#L1065-L1069.
I just did a SQL query to see how many DB tables are affected and this is the result:
mysql> show tables like 'wp\_1\_%'; +---------------------------------+ | wp_1_2fa_webauthn_credentials | | wp_1_2fa_webauthn_users | | wp_1_ak_twitter | | wp_1_avhec_category_groups | | wp_1_bdprss_errors_v3 | | wp_1_bdprss_items_v3 | | wp_1_bdprss_lists_v3 | | wp_1_bdprss_sites_v3 | | wp_1_cac_invites | | wp_1_cac_library_items | | wp_1_commentmeta | | wp_1_comments | | wp_1_contact_form_7 | | wp_1_eo_events | | wp_1_eo_venuemeta | | wp_1_flickr_post | | wp_1_links | | wp_1_ngg_album | | wp_1_ngg_gallery | | wp_1_ngg_pictures | | wp_1_now_reading | | wp_1_now_reading_books2tags | | wp_1_now_reading_meta | | wp_1_now_reading_tags | | wp_1_options | | wp_1_podpress_statcounts | | wp_1_podpress_stats | | wp_1_pollsa | | wp_1_pollsip | | wp_1_pollsq | | wp_1_postmeta | | wp_1_posts | | wp_1_quotescollection | | wp_1_ratings | | wp_1_redirection_404 | | wp_1_redirection_groups | | wp_1_redirection_items | | wp_1_redirection_logs | | wp_1_redirection_modules | | wp_1_rg_form | | wp_1_rg_form_meta | | wp_1_rg_form_view | | wp_1_rg_incomplete_submissions | | wp_1_rg_lead | | wp_1_rg_lead_detail | | wp_1_rg_lead_detail_long | | wp_1_rg_lead_meta | | wp_1_rg_lead_notes | | wp_1_subscribe2 | | wp_1_term_relationships | | wp_1_term_taxonomy | | wp_1_termmeta | | wp_1_terms | | wp_1_wordtube | | wp_1_wordtube_med2play | | wp_1_wordtube_playlist | | wp_1_wpo_campaign | | wp_1_wpo_campaign_category | | wp_1_wpo_campaign_feed | | wp_1_wpo_campaign_post | | wp_1_wpo_campaign_word | | wp_1_wpo_log | | wp_1_wysija_bounce | | wp_1_wysija_campaign | | wp_1_wysija_campaign_list | | wp_1_wysija_custom_field | | wp_1_wysija_email | | wp_1_wysija_email_user_stat | | wp_1_wysija_email_user_url | | wp_1_wysija_form | | wp_1_wysija_list | | wp_1_wysija_queue | | wp_1_wysija_url | | wp_1_wysija_url_mail | | wp_1_wysija_user | | wp_1_wysija_user_field | | wp_1_wysija_user_history | | wp_1_wysija_user_list | +---------------------------------+ 78 rows in set (0.27 sec)
Most of these tables are for plugins we do not use on the main site anymore, so we can safely delete and ignore them. But before we add in the
define( 'MULTISITE', true ) line to
wp-config.php, we'd have to copy the affected DB tables to use the
wp_ prefix first.
This is not really urgent to address (we've gone this long without the MULTISITE constant!), so we can look at this when Boone is back from vacation.
Updated by Boone Gorges about 2 months ago
My understanding (from long ago!) is that WPMU named tables like this, and after the MU merge in WP 3.0, you'd have to change table names if you wanted to add the MULTISITE flag. Does that seem right?
The PR linked to in #16245 is interesting, but I wonder whether it's a bug that really needs fixing on our end. The assumption there (if I'm understanding it on a quick reading) was that the main site's table prefix would be identical to the global base prefix. I've never assumed that this is the case (in part because of the MU issues and the Commons). Do we know of other bugs that might be caused by our current configuration? What kinds of side effects might we expect if we made the switch? Are there places in our custom tools where we've hardcoded