#51011 closed defect (bug) (fixed)
Empty string comparison on home option during DB upgrades is invalid
Reported by: | fjarrett | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 5.5.1 | Priority: | normal |
Severity: | minor | Version: | 5.5 |
Component: | Upgrade/Install | Keywords: | |
Focuses: | Cc: |
Description
The private __get_option()
function used during database upgrades was recently changed in WordPress 5.5 to use a strict comparison operator to check whether the home
option value is empty string. However, wpdb::get_var
returns NULL
if the option is empty, so this condition never actually exists.
This was discovered because of an oddity that manifested when using WP-CLI to run database upgrades on sites that has an empty home
option, and it was only reproducible with WordPress 5.5. Full discussion can be found in the #cli Slack.
https://wordpress.slack.com/archives/C02RP4T41/p1597352867393200
Some possible solutions are:
- Correct the strict comparison to use
null === $option
- Use a more generous empty comparison like
! $option
- Refactor
__get_option()
to usewpdb::get_col
like itsget_option()
cousin
---
The WP-CLI oddity is fairly easy to reproduce:
- Empty the
home
option value in the WordPress database:
$ wp db query "UPDATE wp_options SET option_value = '' WHERE option_name = 'home';"
Note:
wp option update home ''
won't work because the core fallback tositeurl
prevents it.
- Set the
db_version
option to anything less than 48748:
$ wp option update db_version 47018 Success: Updated 'db_version' option.
- Execute the database update:
$ wp core update-db Success: WordPress database upgraded successfully from db version 47018 to 48748.
- Check the option value:
$ wp option get home http://http://example.com
Use null for strict comparison of home option value