---

This section details on the original issue you should resolve

<issue_title>Fix --skip-update-check in new admin context</issue_title>
<issue_description>In the framework we made some changes to how --context works:

• Set default context to "auto" wp-cli#6255
• Set $pagenow in 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
      """
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>