-
Notifications
You must be signed in to change notification settings - Fork 86
Closed
Labels
bugcommand:pluginRelated to 'plugin' commandRelated to 'plugin' commandcommand:plugin-listRelated to 'plugin list' commandRelated to 'plugin list' commandcommand:themeRelated to 'theme' commandRelated to 'theme' commandcommand:theme-listRelated to 'theme list' commandRelated to 'theme list' commandscope:testingRelated to testingRelated to testing
Description
In the framework we made some changes to how --context works:
- Set default context to "auto" wp-cli#6255
- Set
$pagenowin admin context more accurately based on current command wp-cli#6256
This combination caused the --skip-update-check tests to fail:
extension-command/features/plugin.feature
Lines 410 to 434 in a93ef03
| @require-wp-5.2 | |
| Scenario: Flag `--skip-update-check` skips update check when running `wp plugin list` | |
| Given a WP install | |
| When I run `wp plugin install wordpress-importer --version=0.2` | |
| Then STDOUT should contain: | |
| """ | |
| Plugin installed successfully. | |
| """ | |
| When I run `wp plugin list --fields=name,status,update --status=inactive` | |
| Then STDOUT should be a table containing rows: | |
| | name | status | update | | |
| | wordpress-importer | inactive | available | | |
| When I run `wp transient delete update_plugins --network` | |
| Then STDOUT should be: | |
| """ | |
| Success: Transient deleted. | |
| """ | |
| When I run `wp plugin list --fields=name,status,update --status=inactive --skip-update-check` | |
| Then STDOUT should be a table containing rows: | |
| | name | status | update | | |
| | wordpress-importer | inactive | none | |
extension-command/features/theme.feature
Lines 210 to 234 in a93ef03
| @require-wp-5.3 | |
| Scenario: Flag `--skip-update-check` skips update check when running `wp theme list` | |
| Given a WP install | |
| When I run `wp theme install astra --version=1.0.0` | |
| Then STDOUT should contain: | |
| """ | |
| Theme installed successfully. | |
| """ | |
| When I run `wp theme list --fields=name,status,update` | |
| Then STDOUT should be a table containing rows: | |
| | name | status | update | | |
| | astra | inactive | available | | |
| When I run `wp transient delete update_themes --network` | |
| Then STDOUT should be: | |
| """ | |
| Success: Transient deleted. | |
| """ | |
| When I run `wp theme list --fields=name,status,update --skip-update-check` | |
| Then STDOUT should be a table containing rows: | |
| | name | status | update | | |
| | astra | inactive | none | |
The reason for that is core doing add_action( 'load-plugins.php', 'wp_update_plugins' ); and add_action( 'load-themes.php', 'wp_update_themes' );. So the update checks runs all the time on that page.
The easiest solution would be to unhook these two callbacks when --skip-update-check is passed. Probably within CommandWithUpgrade.
The Behat tests could be hardened to verify no HTTP requests are made, e.g.
When I try `wp plugin list --fields=name,status,update --status=inactive --skip-update-check --debug=http`
Then STDERR should not contain:
"""
HTTP POST request to https://api.wordpress.org/plugins/update-check
"""
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugcommand:pluginRelated to 'plugin' commandRelated to 'plugin' commandcommand:plugin-listRelated to 'plugin list' commandRelated to 'plugin list' commandcommand:themeRelated to 'theme' commandRelated to 'theme' commandcommand:theme-listRelated to 'theme list' commandRelated to 'theme list' commandscope:testingRelated to testingRelated to testing