#61045 closed defect (bug) (fixed)
Options: Update default autoload values used in core
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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.
2 years ago
This ticket was mentioned in PR #6417 on WordPress/wordpress-develop by @pbearne.
2 years ago
#2
- Keywords has-patch added
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
2 years ago
#4
@
2 years 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
@
2 years 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.
2 years ago
@joemcgill commented on PR #6417:
2 years ago
#8
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
2 years ago
#10
@
2 years 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.
2 years 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.
2 years ago
@rajinsharwar commented on PR #6791:
2 years 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:
2 years 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:
2 years 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.