![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 13 years ago
Closed 13 years ago
#25015 closed defect (bug) (fixed)
Options cache updated by update_option() and add_option() even on failure
| Reported by: | jdgrimes | Owned by: | nacin |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.7 |
| Component: | Cache API | Version: | 2.2 |
| Severity: | normal | Keywords: | has-patch commit |
| Cc: | Focuses: |
Description
The add_option() and update_option() functions both update the 'alloptions' cache before performing the insert/update query on the database. It is therefore possible to do the following:
add_option( 'test_option', 'foo' ); // Lets say this fails. $option = get_option( 'test_option' ); // $option == 'foo' !
But now if we attempt to delete or update the option, we can't:
var_dump( delete_option( 'test_option' ) ); // bool(false) var_dump( update_option( 'test_option', 'bar' ) ); // bool(false)
This was introduced in [4855].
Attachments (2)
Change History (8)
#1
@
13 years ago
- Summary 'alloptions' cache updated by update_option() and add_option() even on failure → Options cache updated by update_option() and add_option() even on failure
#3
@
13 years ago
- Keywords has-patch added
That patch moves the cache updating to inside of the if-success blocks for these two functions. I'm not sure if that is the best approach. Should we be invalidating the cache in some way if the add/update queries fail, or should we assume that the cache is still reliable? This patch does the latter.
Note:
See TracTickets
for help on using tickets.
This does not only affect the
'alloptions'pseudo-option, it affects any option.