Multisite error: wp_options’ doesn’t exist

  • Resolved rsoareslangara

    (@rsoareslangara)


    2 years, 1 month ago

    Hello iThemes team,

    thanks for your great plugin.
    We have experienced an error which has been flooding the debug.log file. Apparently there’s no functional issues, only the issue of the debug.log file.

    A sample of the error:
    WordPress database error Table 'wp_options' doesn't exist for query INSERT IGNORE INTOwp_options(option_name,option_value,autoload`) VALUES (‘itsec-lock-cron_test_fail_safe’, ‘*****’, ‘no’) /* LOCK */ made by require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters, itsec_cron_test_fail_safe, ITSEC_Lib::get_lock
    `
    Apparent “root-cause”: the plugin code has a bug to get the prefix for multisite options table. There’s no ‘wp_options’, only options table for each site (eg. wp_1_options = main site options table).

    Workaround found by us: After some technical investigation, we could fix it by changing the follow file and lines:

    /wp-content/plugins/better-wp-security/core/lib.php

    Changing:
    $main_options = $wpdb->base_prefix . 'options'; // wrong: //--> wp_

    By:
    $main_options = $wpdb->prefix . 'options'; //--> wp_1_

    It’d be great if you can fix it, because every time we need to update the plugin, we lose this customization.

    Thank you,
    Rafael

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

  • Hi Rafael,

    Did you “Network Activate” the iTSec plugin?

    If I’m not mistaken, the iTSec plugin only supports “Network Activate” in multisite.

    +++++ To prevent any confusion, I’m not iThemes +++++

    Hi Rafael,

    As a temporary workaround you can try and add the line below to the wp-config.php file:

    define( 'ITSEC_DISABLE_CRON_TEST', true );

    Thread Starter rsoareslangara

    (@rsoareslangara)

    Hello iThemes team,

    thanks for your promptly response.

    Our iThemes is Network activated, and we also had setup the suggested directive (ITSEC_DISABLE_CRON_TEST, true), and we are still getting lots of that error for each page load.
    Our WP version is 6.0.3 and iThemes is 8.1.3. The PHP version is 7.4.32 (Supports 64bit values).

    Thanks,
    Rafael

    Hi Rafael,

    Please remember as mentioned in my first post:

    +++++ To prevent any confusion, I’m not iThemes +++++

    If the ITSEC_DISABLE_CRON_TEST constant is properly defined and set to true in the wp-config.php file, the iTSec plugin itsec_cron_test_fail_safe() callback hooked to the WordPress init action (as can be seen in the better-wp-security/core/modules/global/active.php file) will stop executing. This prevents the failing ITSEC_Lib::get_lock( 'cron_test_fail_safe' ) code from executing. Which in turn should prevent the error with the stack trace you reported.

    However the ITSEC_Lib::get_lock() function is called in many places throughout the iTSec plugin code.

    So you may still be running into the same error but with a different stack trace.

    Anyway, any idea why there is no wp_options table in your multisite ? (The wp_options table exists in my multisite test env).

    Thread Starter rsoareslangara

    (@rsoareslangara)

    Hi @nlpro,

    many thanks for all information provided and insights, very resourceful. And sorry for the confusion I made.
    Regarding why there’s no xx_options in out installation, not sure, perhaps because this is a very old installation (over 10 years), but we’ve kept it upgraded and very secure (just to mention).
    Perhaps that’s why iThemes didn’t foresee our situation in their business scenarios / code. But we hope they could fix it.

    Thanks,
    Rafael

    nlpro

    (@nlpro)

    Hi Rafael,

    Please check for the current value of $table_prefix in the wp-config.php file.
    It should look like the line below:

    $table_prefix = 'wp_';

    If it is the same, then there must be wp_ tables (including wp_options) in your database.

    What other database tables do you have ? (wp_1_, wp_2_ etc)

    To get a better idea/view on what tables should exist in a WordPress multisite database I recommend to read the WORDPRESS MULTISITE DATABASE TABLES EXPLAINED article.

    • This reply was modified 2 years ago by nlpro.
    Thread Starter rsoareslangara

    (@rsoareslangara)

    Hi @nlpro,

    we are aware of how multisite database is structured and how the prefix is setup on wp-config.php.
    The “root cause” of the original issue is because our “root website” has its tables with the sequence “1”: PREFIX_1_options, PREFIX_1_links, PREFIX_1_posts, so on so forth.
    Each individual website has their own tables, like PREFIX_2_options, PREFIX_3_options, etc. This is totally normal.
    As I said before, probably because our installation is old and that’s the way the DB structure was setup long time ago by WP core.
    We won’t reveal our PREFIX here for security reasons (SQL injection).

    Thanks,
    Rafael

    nlpro

    (@nlpro)

    Rafael,

    Ah ok, I see.

    It looks like $wpdb->base_prefix is equal to wp_ where in your multisite env it should be equal to wp_1_. If you can get that right when the WordPress core wpdb class is instantiated there is probably no need to change the iTSec plugin code.

    Actually forget I mentioned that. It will break the WordPress core (wpdb class) get_blog_prefix() function.

    • This reply was modified 2 years ago by nlpro.
    nlpro

    (@nlpro)

    Rafael,

    Actually the WordPress core get_blog_prefix() function is already broken in the current situation.
    So that makes me think using the wp_1_ prefix for the tables of the main site can’t be right.

    The get_blog_prefix() function will only function properly (return correct prefix values) when the $wpdb->base_prefix equals the prefix as used for the tables of the main site. On a page load of a network administrator or for the main site the get_blog_prefix() function is probably returning wp_. I’m pretty sure that is not a bug in the get_blog_prefix() function ??

    Thread Starter rsoareslangara

    (@rsoareslangara)

    Hi @nlpro,

    thanks for further checking the base prefix issue.
    So I think we are going to close this case as this is not an issue with iThemes.
    We aren’t going to touch the main site prefix because everything else is working seamlessly, it’s an installation with over 500 websites and over 100 stakeholders.

    Thanks for your help.
    Rafael

    nlpro

    (@nlpro)

    Rafael,

    Yup, this is not an iTSec plugin bug.

    Workaround is provided for the reported error/stack trace. Frequency of the reported error/stack trace is high since it is init hook related. Init hook is executed on every page load.

    Even with the workaround applied there is still a chance of incidentally running into the same error but with a different stack trace and far lower frequency.

    I guess this topic can be marked as ‘Resolved’ ??

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Multisite error: wp_options’ doesn’t exist’ is closed to new replies.