Try going to wp-admin > Tools > BuddyPress and selecting the last option:
Create the database table for Invitations and migrate existing group invitations if needed.
Thanks, I hadn’t seen this tools page. However, even though running the last repair item reported as successful, I still don’t see the wp_bp_optouts table. And when I go to the ‘Manage Opt-Outs’ tab on the tools page, I get the same ‘table doesn’t exist’ error.
Try deactivating BP, then update to the newest version and activate.
Sorry, no joy. I deactivated BP, updated from 9.0.0 to 9.1.1, re-activated, and still couldn’t see wp_bp_optouts in the DB. I tried re-running the tool mentioned, still no opt-outs table.
Is wp the database prefix? As set in wp-config.
If you are using caching, plugin etc., or something that minifies javascript files, that can cause problems re comments, etc. Try turning off caching and minification.
You can also switch momentarily to a theme like 2020 to see if it is theme-related.
Yes, all tables have the prefix wp_, as set in the config file.
On the production site our hosts run a caching system, but I’m working locally on this, no caching. All minification etc. is done using Grunt build scripts – so nothing in plugins or otherwise as the site runs on the server.
The theme is quite a beefy custom theme, but I switched to Twenty Twenty-One, ran the BP tool, deactivated BP, reactivated, ran the BP tool again – no sign of the table.
Is there anything I can do to debug? It seems odd that the BP tool specifically designed to create the tables doesn’t do anything, even though it reports success.
You could manually create the table:
CREATE TABLEwp_bp_optouts` (
id bigint(20) NOT NULL,
email_address_hash varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
user_id bigint(20) NOT NULL,
email_type varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
date_modified datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
—
— Indexes for table wp_bp_optouts
—
ALTER TABLE wp_bp_optouts
ADD PRIMARY KEY (id),
ADD KEY user_id (user_id),
ADD KEY email_type (email_type),
ADD KEY date_modified (date_modified);
—
— AUTO_INCREMENT for table wp_bp_optouts
—
ALTER TABLE wp_bp_optouts
MODIFY id bigint(20) NOT NULL AUTO_INCREMENT;
COMMIT;`
Thanks, that does the trick. I’ll let you know if we hit any problems down the line with this, but the table is there now at least.
Actually there’s an issue running the SQL on our live server, which I didn’t get locally. With the first ALTER TABLE statement I get:
‘Index column size too large. The maximum column size is 767 bytes.’
If I then run the next statement I get:
‘Incorrect table definition; there can be only one auto column and it must be defined as a key.’
Not sure if that’s separate, or a ‘cascade’ from the previous one giving an error. Doesn’t ring any bells for me – does it for you, or does it look like something I need to raise with my host?
