#51011 closed defect (bug) (fixed)
Empty string comparison on home option during DB upgrades is invalid
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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_collike itsget_option()cousin
---
The WP-CLI oddity is fairly easy to reproduce:
- Empty the
homeoption 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 tositeurlprevents it.
- Set the
db_versionoption 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