#1412 closed defect (bug) (wontfix)
Object unserialization using get_option fails
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | 1.5.1.1 |
| Severity: | normal | Keywords: | has-patch 2nd-opinion |
| Cc: |
Description
Basically, the object is serialized fine, however the code that retreives all the options, unserializes the object as soon as its retrieved from the DB, but since that code happens long before the plugin code is loaded, the class definition is non existant.
The 'correct' way to handle this, would be to not unserialize until the coder calls get_option, in this case, the class definition would be loaded and there would be more problems.
I originally laid out this problem here: http://ericanderson.us/blog/2005-03-08/hacking-wordpresss-get_option-object-unserialization/
Attachments (1)
Change History (6)
- Milestone set to 2.0.3
- Owner changed from anonymous to westi
- Status changed from new to assigned
- Component changed from Administration to General
- Keywords bg|has-patch bg|2nd-opinion added
- Milestone changed from 2.0.3 to 2.1
- Keywords has-patch 2nd-opinion added; bg|has-patch bg|2nd-opinion removed
Note: See
TracTickets for help on using
tickets.

Looking at this and the code I think all we need do here is remove the maybe_unserialize}} from {{{get_alloptions as get_setting does this anyways .
This way unserialization will be done on the get_option call.
We may want to recache the unserialized value in get_settings the first time an option value is asked for if we feel that unserializing _every_ time is too expensive an option - which the only reason for doing it get_alloptions that I can think of.