#61045 closed defect (bug) (fixed)
Options: Update default autoload values used in core
Reported by: | joemcgill | Owned by: | joemcgill |
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | has-patch changes-requested |
Focuses: | Cc: |
Description
Following r57920, WordPress will now use one of 'on', 'off', 'auto-on', 'auto-off', or 'auto' for the autoload value stored in the DB, while still supporting the previous 'yes' and 'no' values for backwards compatibility.
However, there are still many places in core that will create new options using the previous values. These should be updated to use the new schema for consistency.
Most notably, populate_options()
sets options on a new site using the previous 'yes' or 'no' values.
Other functions to update:
set_transient()
add_network_option()
wp_ajax_wp_compression_test()
There may be others that I missed in a quick scan of the codebase, but those should cover most cases.
Change History (17)
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
8 months ago
This ticket was mentioned in PR #6417 on WordPress/wordpress-develop by @pbearne.
8 months ago
#2
- Keywords has-patch added
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
8 months ago
#4
@
8 months ago
- Keywords commit added
- Owner changed from pbearne to joemcgill
I have reviewed PR #6417 and am marking for commit. I'll handle unless someone beats me to it or additional feedback is raised.
#5
@
7 months ago
- Keywords changes-requested added; commit removed
A couple of small revisions are needed. Removing the commit
keyword.
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
7 months ago
@joemcgill commented on PR #6417:
7 months ago
#8
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
7 months ago
#10
@
6 months ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening this because I just realized that [58105] confused the stored database values 'on'
/'off'
with the parameter values true
/false
for add|update_option()
.
This ticket was mentioned in PR #6791 on WordPress/wordpress-develop by @joemcgill.
6 months ago
#11
This fixes some instances of autoload values changed in r58105 where the database values of 'on'
or 'off'
were passed to option functions rather than the supported values of true
or false
.
Trac ticket: https://core.trac.wordpress.org/ticket/61045
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
6 months ago
@rajinsharwar commented on PR #6791:
6 months ago
#13
@joemcgill Should we change the one at schema.php as well?
https://github.com/WordPress/wordpress-develop/blob/459d99618c4dd6d412d7ad5a5d96e79e87602dc6/src/wp-admin/includes/schema.php#L599
@joemcgill commented on PR #6791:
6 months ago
#14
@Rajinsharwar
Should we change the one at schema.php as well?
No, I don't think so. There were many cases like this one in the original commit that were updating values directly in the DB via direct queries, rather than through the add|update_option()
functions. Those cases should be using "on"
and "off"
.
@joemcgill commented on PR #6791:
6 months ago
#16
Committed in https://core.trac.wordpress.org/changeset/58416
Updated values of 'autoload' option from 'yes' or 'no' to 'on' or 'off' respectively, across several PHP files. This change was implemented in the functions handling options and lock settings, enhancing clarity and consistency of the code.