add_option followed by update_option not always working

[YellowSwordfish]

I have an update script that brings a plugin from any version up to the current version. Early on there is an add_option request. Later I need to add to the content so I perform a get_option, modify the content and perform an update_option. This also happens a second time in the script. Results can vary. For some the sequence works fine. For others the final option content may only contain the final two 'update' calls having lost the original. In tests I have just performed I ended up with two option rows (with the same option_name) - the first with the original content, the second with the two modifications combined. I do not believe this ever happened (to my knowledge) prior to 2.2 but seems to be quite common on 2.2. It's almost as if the subsequent calls are not pulling the original option from the cache.

Subscribe to Comments has been triggering this bug too. I finally nailed down the issue.

add_option() tries to erase the "notoptions" cache entry for the option too early... that is, it performs it before a get_option() call. The get_option() call marks (or re-marks) the option as "notoptions" (caches its non-existence). So now when you call update_option(), it thinks the option doesn't exist, so it adds a new one. Patches coming.

add_option() fix for trunk

add_option() fix for 2.2.x

This is a pretty critical function, so I'd appreciate a second pair of eyes on these patches.

(In [5788]) Properly unset notoptions cache in add_option() so that get_option() and update_option() work on the same load. fixes #4429 for trunk

Re-open for 2.2.2

(In [5789]) Properly unset notoptions cache in add_option() so that get_option() and update_option() work on the same load. fixes #4429 for 2.2.x