Skip to:
Content
Pages
Categories
Search
Top
Bottom

Table ‘wp_bp_optouts’ doesn’t exist


  • Steve Taylor
    Participant

    @gyrus

    I’m trying to solve an issue with replies to activity comments that aren’t appearing on the site (even though they’re in the database and not marked as spam). I tried posting a new reply to an activity comment as a test, and when the reply was posted, it came with 2 errors, SQL queries which failed because the table ‘wp_bp_optouts’ doesn’t exist.

    I’ve no idea if this is related to my original problem, but I want to see what the situation is with this missing table anyway. I can’t see it in the database. It’s possible there was an issue because we froze our version of BP a good few major releases back, then upgraded to the latest recently. However, I made sure to upgrade sequentially through the intermediate releases in order to pick up any e.g. database changes, and we’ve not noticed any issues until now (many months after our big upgrade). We’re currently on BP 9.0.0, WP 5.8.

Viewing 10 replies - 1 through 10 (of 10 total)

  • shanebp
    Moderator

    @shanebp

    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.


    Steve Taylor
    Participant

    @gyrus

    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.


    shanebp
    Moderator

    @shanebp

    Try deactivating BP, then update to the newest version and activate.


    Steve Taylor
    Participant

    @gyrus

    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.


    shanebp
    Moderator

    @shanebp

    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.


    Steve Taylor
    Participant

    @gyrus

    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.


    shanebp
    Moderator

    @shanebp

    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;`


    Steve Taylor
    Participant

    @gyrus

    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.


    Steve Taylor
    Participant

    @gyrus

    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?


    shanebp
    Moderator

    @shanebp

    Please ask your host.

Viewing 10 replies - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.
Skip to toolbar