Add --force-check flag to wp plugin list and wp theme list.

[baizmandesign]

Hi @danielbachhuber,

In the process of updating my fork, I somehow accidentally closed the existing pull request for this feature.

Here's the code and tests. Please let me know if you have any feedback!

Saul

[ernilambar]

@baizmandesign Please make sure all tests except PHP 8.4 are passing in Actions.

[baizmandesign]

Hi, @ernilambar. I added another commit, and it failed three tests: 2 related to PHP 8.4 and one test due to a GitHub API rate limit issue. Is there a way to re-run the one failed test unrelated to PHP 8.4?

[swissspidy]

PHP 8.4 tests are expected to fail, PHP 8.4 is still in alpha and WP-CLI is not yet compatible. Feel free to ignore those.

[baizmandesign]

Thanks for the info, @swissspidy. Is there a way to re-run the one test unrelated to PHP 8.4 that failed?

[baizmandesign]

Hi, @ernilambar. I've made the changes you requested. Please let me know if there's anything else I need to do. Thanks!

[BrianHenryIE]

Looks good to me; tests run locally.

I like the When I run wp eval-file update-transient.php trick.

[baizmandesign]

Hi, guys. Any update on the status of this pull request? Thanks!

[mrsdizzie]

I notice that we use --force in most other commands for similar behavior. Would it be better to name this --force and not --force-check to match existing commands?

[swissspidy]

It's a good question. For commands like install or update, the intention of --force seems clear.

But for wp plugin/theme list, only --force seems too ambiguous to me.

[BrianHenryIE]

--force makes sense in terms of something being written which is already known. It's more of a push word, whereas the point of this PR is to pull/fetch the latest information. I found myself using --refresh in a premium plugin licence update command I was writing.

I do see --skip-check elsewhere, so --force-check makes sense as its opposite. Also worth considering that --flag automatically comes with --no-flag (utils.php) (Configurator.php).

--force-check is probably fine here.

In terms of premium plugins, this does now suggest that when the update_plugins transient value does not have the premium plugin's update status, it should fetch it from its remote server and not to use cached information (which is fine, just not so explicit before).