![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#51011 closed defect (bug) (fixed)
Empty string comparison on home option during DB upgrades is invalid
| Reported by: | fjarrett | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.5.1 |
| Component: | Upgrade/Install | Version: | 5.5 |
| Severity: | minor | Keywords: | |
| Cc: | Focuses: |
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