Set defaults for new options on update #734
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a fix for #727, but in a way that we won't run into future problems when adding new defaults for options.
It took me a bit to figure out what was going on here, so here's a walkthrough for posterity.
$option
array are introduced, their default values never hit the database.of_set_option()
to update various settings. When this function is called, three things happen:update_option()
.optionsframework_validate()
.checkbox
ormulticheck
that is absent gets a default value offalse
. Since this list is originally from the database, it doesn't include any newly added options. Thus all newly added options of type checkbox or multicheck default to zero on the firstof_set_option
call.The tl;dr is for the optionsframework to behave properly, the defaults have to be saved to the database. This pull request does that with the new update function
largo_set_new_option_defaults()
. This is the first function that runs because any other update functions that callof_set_option()
will override the defaults.