4.0.1 – 0 is a protected WP option and may not be modified

This WP bug is a paint in the ass. It comes from here:

wordpress/wp-includes/option.php

function wp_protect_special_option( $option ) {
        $protected = array( 'alloptions', 'notoptions' );
        if ( in_array( $option, $protected ) )
                wp_die( sprintf( __( '%s is a protected WP option and may not be modified' ), esc_html( $option ) ) );
}

My guess is that if WP tries to save a blank, null, false, empty, etc., option name (aka, “0”), the function above gets triggered because in_array() returns true for a null string.

You can see they’re fixes the bug in wordpress/wp-admin/network/site-settings.php, but why they didn’t also fix it in wordpress/wp-includes/option.php is a mystery.

I’d say you have a blank option name somewhere, and WP is choking on it.

I’ve been through the NGFB code several times now, making sure the option name can never be blank. I’m sure there are several conditions that trigger this, and unfortunately, I seem to be the one actually responding to bug reports on this. ??

If you know your way around the options table, look for a blank option entry.

js.

Alternatively, you could comment this section (temporarily) in wordpress/wp-includes/option.php:

if ( in_array( $option, $protected ) )
                wp_die( sprintf( __( '%s is a protected WP option and may not be modified' ), esc_html( $option ) ) );

I’m really tempted to remove and re-code that WP function properly…

js.

Well, I deleted the plugin once again, re-installed and reseted settings (from wp-config).

It started to work now but it’s always pain in ass to set up everything again.

Aside from revising the donate box in v4.0.2, I also made a small change to the upgrade_options() function to simply unset older option values instead of trying to delete them. I figure the less I use those problematic WP functions, the better. ??

js.

Just curious, but has anyone had users using Internet Explorer complaining that the problem persists? I use Chrome myself normally, but when my staff and some readers mentioned that IE was giving this error all the time, even with the fix posted, I gave it a shot, and sure enough, it’s persistent. Basically, I’ll go to the site, no issue, click on some articles, no problem, then head back to the main page using the HOME tab and it’ll give me the “0 is a protected WP option and may not be modified” error.

This is with or without the plugin installed. But the issues started when I started using it. I can see that there might be a possibility that WP code might be at fault (as you noted above) but is there we can work around this for now? My staff and my readers are getting annoyed.

Thanks!

The problem might be triggered by your theme. If you don’t mind editing the WordPress code, you can comment the two lines I mentioned above in the wordpress/wp-includes/options.php file.

js.

FYI – A little research returns known issues with PHP’s in_array() function — mostly when strict checking isn’t enabled. The following would probably fix this bug:

Turning on strict checking:

if ( in_array( $option, $protected, true ) )
                wp_die( sprintf( __( '%s is a protected WP option and may not be modified' ), esc_html( $option ) ) );

Or checking for an “empty” $option:

if ( ! empty( $option ) && in_array( $option, $protected ) )
                wp_die( sprintf( __( '%s is a protected WP option and may not be modified' ), esc_html( $option ) ) );

js.

I would normally think that except that both websites I run have exactly the same custom themes (with the exception of color/logo), down to the same plugins, running on the same server, with the exception that one of them, I installed this plugin, while the other one, I didn’t (tried out Yoast instead). The other site doesn’t exhibit the issue at all.

The other behaviour I noticed is that it seems to be exhibiting a “time out” period. For example, I’ll do what I did above in IE, then I hit the error. I’ll leave it alone for 10 – 20 seconds, refresh the page, and it’ll come up again. If I don’t wait long enough, it’ll attempt to load, then choke and return this error.

I just tried commenting out those two lines. Doesn’t affect Chrome because the problem wasn’t with that browser, but IE still has the issue, despite clearing out the caches, the site cache, even the CDN directly.

Does that give you any more data points?

Just tried option no 1 in your suggested PHP fixes. I’ll keep an eye on it and get some feedback from our staff and readers and report back.

Option 1 doesn’t fix it. I just got responses back from around the interwebz saying it’s still persistent. Going onto option 2.

FYI – Known bug with WP.

https://core.trac.www.ads-software.com/ticket/23289

js.

Just installed the updated option.php from that to see if there would be any change.

I love this one:

var_dump( in_array( 0, array( '1', 'a2' ) ) ); // bool(true)

var_dump( in_array( 0, array( '1', '2a' ) ) ); // bool(false)

??

And here’s a grep from NGFB v4.0.3 of all the delete/add/update_option() functions (that use wp_protect_special_option()):

$ egrep -R '(delete|add|update)_option *\(' wordpress/wp-content/plugins/nextgen-facebook/
wordpress/wp-content/plugins/nextgen-facebook/nextgen-facebook.php:                             delete_option( NGFB_OPTIONS_NAME );     // remove old options, if any
wordpress/wp-content/plugins/nextgen-facebook/nextgen-facebook.php:                             add_option( NGFB_OPTIONS_NAME, $opts, null, 'yes' );
wordpress/wp-content/plugins/nextgen-facebook/nextgen-facebook.php:                     delete_option( NGFB_OPTIONS_NAME );

The NGFB_OPTIONS_NAME constant has a value of “ngfb_options”, though an alternate value can be defined in the wp-config.php file.

js.

And I’ve noticed the following is done in add_option() and update_option(), but not delete_option():

$option = trim($option);
if ( empty($option) )
    return false;

    wp_protect_special_option( $option );

I’m guessing that adding it to delete_option() as well would be better — that way the delete_option() function would return false immediately if it was called with a blank option value.

js.

Just got word back from a few of our readers. Problem persists even with the option.php from the core.trac.

Sounds like there are definitely some things not right with the WordPress Core. But the only thing I’ve observed is that the install that had this plugin is the one having the hissy fit.

Not blaming you as you’ve made some good points as to how your plugin cannot be a cause. However, the site is still having the issue despite the recommended fixes, which are still appreciated.

Hopefully someone will pop their head in with a “Eureka” moment.