CLI: Fix confusing runtime environment setup order

[felixarntz]

Related to #597.

As of today, in WP-CLI the Runtime_Environment_Setup sets up the separate database tables after all the regular preparations have run (i.e. Universal_Runtime_Preparation). This is confusing and inconsistent with how it works in the AJAX based workflow, where the Runtime_Environment_Setup is executed in a previous request. This is how it was intended, as ideally setting up the separate database tables to run runtime checks against needs to be the earliest step. However, in WP-CLI this has not been happening so far, because it was invoked by the command implementation itself, which however is executed after the early initialization process.

For example, today the option_active_plugins filter is applied on the real database tables for WP-CLI, which means the separate database tables will only contain the filtered plugins. In the AJAX based flow on the other hand, all active plugins from the real database tables will be added to the separate database tables, and the option_active_plugins filter is only applied then. This is, to my knowledge, not causing an actual problem today, but it's just strange and error-prone to have to consider both execution orders.

I had mentioned in this comment that it's "just a technical nuance", but it's still weird and inconsistent, and it doesn't have to be.

This PR fixes it:

• Abstract relevant runtime initialization in the Abstract_Check_Runner class to a new protected method initialize_runtime().
• In CLI_Runner, override that method to first execute Runtime_Environment_Setup, and of course also add its cleanup callback to the list of callbacks.
• This furthermore allows to simplify the Plugin_Check_Command class:
  • Remove the separate use of Runtime_Environment_Setup since it's now handled by CLI_Runner.
  • By doing that, we can also remove the private (and somewhat duplicated) has_runtime_check() method, as well as an extra call to the get_checks_to_run() method which only existed for that purpose.

It now all works through the CLI_Runner, i.e. less technical and cognitive overhead for the Plugin_Check_Command implementation.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: felixarntz <[email protected]>
Co-authored-by: swissspidy <[email protected]>
Co-authored-by: ernilambar <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[felixarntz]

It took me a while to get the wp_install() call to work early, but I got it resolved now. So this PR is good for review!

[swissspidy]

Appreciate all the digging into this! 👏

[davidperezgar]

Awesome!