bp_invitations table not created on update

[shanebp]

BP 5.0.0 WP 5.2.3
localhost using VVV
I can create db tables from plugins without any issues.
I've toggled activation a few times.

Entry added to debug log on every page load:
[07-Oct-2019 22:35:34 UTC] WordPress database error Table 'wordpress_default.wp_bp_invitations' doesn't exist for query 
SELECT DISTINCT i.item_id FROM wp_bp_invitations i WHERE user_id IN (1) AND class IN ('bp_groups_invitation_manager') 
AND type = 'invite' AND invite_sent = 1 AND accepted = 0   made by require('wp-blog-header.php'), 
require_once('wp-includes/template-loader.php'), include('/themes/twentynineteen/page.php'), 
get_footer, locate_template, load_template, require_once('/themes/twentynineteen/footer.php'), wp_footer, do_action('wp_footer'), 
WP_Hook->do_action, WP_Hook->apply_filters, wp_admin_bar_render, do_action_ref_array('admin_bar_menu'), 
WP_Hook->do_action, WP_Hook->apply_filters, bp_setup_admin_bar, do_action('bp_setup_admin_bar'), 
WP_Hook->do_action, WP_Hook->apply_filters, BP_Groups_Component->setup_admin_bar, 
groups_get_invite_count_for_user, groups_get_invited_to_group_ids, groups_get_invites, 
BP_Invitation_Manager->get_invitations, BP_Invitation::get, QM_DB->query

[dcavins]

Hi @shanebp-

You do have to visit the WP-admin area after updating to cause the update routine to run. I just updated a bunch of sites today, and the invitations routine runs when you load a page in wp-admin after completing the actual update. (I loaded the "dashboard" page and it ran successfully every time for me.)

I'd rather it ran "at update" because you can update plugins from the plugins list, but this follows the BP pattern we've used in the past. I wonder if we can be slicker in the future?

Can you check that the invitations routine runs when you visit the dashboard?

[shanebp]

Yes, the error above is from loading any screen in wp-admin.

Here is an example of a front-end error:

[08-Oct-2019 00:44:51 UTC] WordPress database error Table 'wordpress_default.wp_bp_invitations' doesn't exist for query SELECT DISTINCT i.item_id FROM wp_bp_invitations i WHERE user_id IN (1) AND class IN ('bp_groups_invitation_manager') AND type = 'invite' AND invite_sent = 1 AND accepted = 0   made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/twentynineteen/page.php'), get_footer, locate_template, load_template, require_once('/themes/twentynineteen/footer.php'), wp_footer, do_action('wp_footer'), WP_Hook->do_action, WP_Hook->apply_filters, wp_admin_bar_render, do_action_ref_array('admin_bar_menu'), WP_Hook->do_action, WP_Hook->apply_filters, bp_setup_admin_bar, do_action('bp_setup_admin_bar'), WP_Hook->do_action, WP_Hook->apply_filters, BP_Groups_Component->setup_admin_bar, groups_get_invite_count_for_user, groups_get_invited_to_group_ids, groups_get_invites, BP_Invitation_Manager->get_invitations, BP_Invitation::get, QM_DB->query

btw - I have WP_AUTO_UPDATE_CORE set to false.

[dcavins]

What is your _bp_db_version in your wp_options table?

[shanebp]

What is your _bp_db_version in your wp_options table?

13731

[dcavins]

Huh, well, then bp_update_to_5_0() should have already run. Can you check that the other task in that function ran? (bp_xprofile_meta should be 'allow_custom_visibility' => 'disabled' for the "fullname" xprofile field-though it may have already been that way, so this is not a 100% check.)

Can you look back in your logs for any problems with bp_core_install_invitations() which would have relied on $GLOBALS['wpdb']->get_charset_collate(), bp_core_get_table_prefix() and dbDelta() (if that helps with looking in the logs for issues).

If you don't see any clues in the logs, you can manually set the _bp_db_version back to something less than 12385, and deactivate/reactivate to see if you can see any new errors from bp_update_to_5_0().

I wonder if anyone remembers any problems like what you're seeing with 2.5 and the introduction of the new email system.

[shanebp]

There is no fullname xprofile field field on my test install..

I wipe my local logs often to make them easier to handle.

I manually set the _bp_db_version to 12384
Then did an activation toggle.
And _bp_db_version changed to 12385
And the _bp_invitations table was created and the error is gone.

[dcavins]

Is there also now an entry in the wp_bp_xprofile_meta table that looks like this:

id  object_id  object_type  meta_key                 meta_value
1   1          field        allow_custom_visibility  disabled

I'm trying to understand whether the entire update routine failed to run, or if just the invitations part originally failed. Do you have an opinion about what went wrong previously?

Thanks for your help troubleshooting!

[shanebp]

Is there also now an entry in the wp_bp_xprofile_meta table that looks like this:

Yes. For the name field.

I don't have an opinion.
I have encountered edge cases where db operations failed when called as part of a plugin update.
Usually those cases are solved by toggling activation and visiting a wp-admin page.
Not much help, but I've found that these procedures can be squirrelly when distributed.

[sjregan]

I had the same issue, the invitations table was not created during an upgrade from v4.4.0 to v5.1.0.

Once the upgrade was complete a fatal error was thrown within BP because a function was already previously declared in another plugin.

While the other plugin was at fault for incorrectly defining a function with the same name as a BP function, it demonstrates a scenario where a faulty plugin can cause the BP upgrade to fail in a way where the invitations table is not created.

[sjregan]

Additionally I now have two entries in my wp_bp_xprofile_meta table where object_id = 1, object_type = field, meta_key = allow_custom_visibility, meta_value = disabled.

(This was after manually changing the DB version to 12384 and deactivating/reactivating the plugin)

[needle]

Just encountered the same missing table problem. Plugin updated via git from the BuddyPress GitHub repo -- unfortunately I can't confirm previous version. I also have the duplicate entry in wp_bp_xprofile_meta like @sjregan when deactivating/reactivating after downgrading the DB version to 12384.

[dcavins]

Thanks for your comments on this issue. It's sounding to me like the "install at upgrade" routine we've used in the past is not entirely reliable.

If there had been a tool to fix these problems at WP Admin > Tools > BuddyPress, would you have known to use them? Or, would that have been sufficient?

Thanks again for your feedback and troubleshooting help.

[shanebp]

I've been seeing this error a lot recently.
It seems that the table is only ( unreliably ) created during the initial install or upgrade.
This isn't a fix, but it is a workaround hack that works.
It just checks for the table on activation.
Perhaps a BP Tool is more appropriate.

function bp_check_invitations_db_table() {
	global $wpdb;

	require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

	$sql             = array();
	$charset_collate = $GLOBALS['wpdb']->get_charset_collate();
	$bp_prefix       = bp_core_get_table_prefix();
	$sql[] = "CREATE TABLE IF NOT EXISTS {$bp_prefix}bp_invitations (
		id bigint(20) NOT NULL AUTO_INCREMENT PRIMARY KEY,
		user_id bigint(20) NOT NULL,
		inviter_id bigint(20) NOT NULL,
		invitee_email varchar(100) DEFAULT NULL,
		class varchar(120) NOT NULL,
		item_id bigint(20) NOT NULL,
		secondary_item_id bigint(20) DEFAULT NULL,
		type varchar(12) NOT NULL DEFAULT 'invite',
		content longtext DEFAULT '',
		date_modified datetime NOT NULL,
		invite_sent tinyint(1) NOT NULL DEFAULT '0',
		accepted tinyint(1) NOT NULL DEFAULT '0',
		KEY user_id (user_id),
		KEY inviter_id (inviter_id),
		KEY invitee_email (invitee_email),
		KEY class (class),
		KEY item_id (item_id),
		KEY secondary_item_id (secondary_item_id),
		KEY type (type),
		KEY invite_sent (invite_sent),
		KEY accepted (accepted)
		) {$charset_collate};";
	dbDelta( $sql );

}
add_action( 'bp_activation', 'bp_check_invitations_db_table' );

[dcavins]

I'll write a tool this weekend. Thanks for the reminder.

[shanebp]

It'd be nice to know why this issue occurs for the invitations table but not the other tables.
Here's a tool.

[dcavins]

Expand Shane's patch to also migrate group invitations.

[dcavins]

Hi @shanebp-

Thanks a million for your patch. I've expanded it in the following ways:

• Use the existing bp_core_install_invitations() function to create or update the invitations table.
• Also migrate group invitations if necessary, using the function bp_groups_migrate_invitations().

@imath: What do you think about including this very narrow change in BP6.0, even though we've passed beta1? The code is run only when fired by the site owner, so it's scope is very limited; however, there are several new strings that will need to be translated.

Thanks again @shanebp for submitting a working patch!

[imath]

Hi @dcavins

Sure no problem, could you commit it before packaging beta2 (April 15) ?

Also, I've added an additional suggestion above. I believe the bp_core_install_invitations() function should be included into the bp_core_install()one as this function is always used (install and upgrade) and all custom table creation is included there.

Also, could you add some ponctuation like below into your patch?

// Invitations:
// - maybe create the database table.

[dcavins]

In 12616:

Add invitations repair tool.

Add tool to the WP Admin Dashboard > Tools > Buddypress screen
to create the invitations table when table creation has failed
during the plugin update process.
Additionally, this tool will migrate any outstanding
group invitations once the table is created.

Props shanebp.

Fixes #8141.