Make WordPress Core

Opened 18 years ago

Closed 17 years ago

#5702 closed defect (bug) (wontfix)

update_option should accept $autoload parameter

Reported by: adamrbrown's profile adamrbrown Owned by: jacobsantos's profile jacobsantos
Milestone: Priority: normal
Severity: normal Version: 2.3.2
Component: General Keywords: has-patch needs-testing
Focuses: Cc:

Description

update_option should accept the $autoload parameter. The codex claims that it already does (here), but that is incorrect (at least in version 2.3.2).

Many plugin developers--myself included--never call add_option directly. Instead, I only ever call update_option, which will call add_option if necessary.

But if update_option will call add_option, then update_option should accept all of add_option's parameters--including $autoload.

'Tis a very simple patch, without much chance of screwing anything up.

Attachments (2)

update_option.patch (713 bytes) - added by adamrbrown 18 years ago.
Patch
5702.r9125.diff (2.4 KB) - added by jacobsantos 17 years ago.
Adds optional autoload parameter to update_option() based off of r9125

Download all attachments as: .zip

Change History (9)

@adamrbrown
18 years ago

Patch

#1 @lloydbudd
18 years ago

  • Milestone set to 2.5

#2 @DD32
18 years ago

Only problem with the patch is that if you're updating an option which allready exists, then it ignores the autoload parameter.

It also requires you to dodge around the 3rd parameter(Which is no longer used) -- What was that param. used for originally? Maybe its possible to take over that param instead (and only do something if its a true/false/yes/no value?)

#3 @adamrbrown
18 years ago

Taking over the 3d parameter is a bad idea. Check the codex entry on update_option for why it's there. Since there are probably plugins out there that expect the third and fourth args to look like that, changing them can only hurt.

As for making the autoload parameter get recognized even for an existing option, sure, that wouldn't be a problem. It would take a little more work with the patch, though. I'll take a look at how difficult it would be.

#4 @DD32
18 years ago

Ah, I forgot the 3rd was description & didnt read the codex(No mouse :))

#5 @jacobsantos
17 years ago

  • Owner changed from anonymous to jacobsantos

After thinking about this, it should be possible to set an option to autoload after the option has been created. In order to do it now, you would have to get the option, delete the option and then readd it if you want to autoload the contents. The SQL queries aren't very efficient in the amount of queries it would take. Instead one should be given to set an existing option to be autoloaded after it has been created.

@jacobsantos
17 years ago

Adds optional autoload parameter to update_option() based off of r9125

#6 @jacobsantos
17 years ago

  • Keywords needs-testing added
  • Milestone changed from 2.9 to 2.7

#7 @markjaquith
17 years ago

  • Milestone 2.7 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I think it's a rare case where you want to change the autoload. Most options SHOULD be autoloaded.

If you need to add an option that is not autoloaded, use add_option() on an activation hook.

Note: See TracTickets for help on using tickets.