Find a better way to call wp-cli

[mlutfy]

Currently, the "provision-wordpress-install" and "provision-wordpress-cli" commands are calling wp-cli in a very unusual way: re-rewriting the $GLOBALS['argv'] variable, then doing an 'include' of wp-cli.php.

The main reason for doing this, instead of doing an 'exec', is to correctly include wp-config.php from the platform, while making sure that the $_SERVER variables are correctly set by the wpsite service.

However, there are alternatives that could work:

• - update: no, because we prefer to "cloak" database credentials in the vhost, for more security.
  

• finding out the correct way to call wp-cli.php so that it does not parse the $GLOBALS['argv'] variable.

While we're at it, it would be nice to have proper logging redirection (wp-cli does an fwrite to STDOUT).

[mlutfy]

I did some tests in hosting_wpplatform/drush/Provision/Service/wpsite.php to define/include the necessary things so that wp-cli can be later called with its "run command" function, rather than the include currently being done (and playing with the ARGV).

It would also be good to have a proper logger that uses drush_log, instead of the prints to STDERR/STDOUT (which we cannot catch)

However, the tests I did were unsucessful. For the installation, it would not run, and I would not get any error message. It's really not clear to me when the WP_INSTALLING constant must be defined, how wp-cli deals with that, etc. wp-cli has some special short-circuit in WP_CLI::get_runner()->before_wp_load() when running "core install", so that the DB credentials are not required, but I had trouble finding a good model to emulate it.

[mlutfy]

The wp-cli maintainer is against the idea of calling wp-cli from another application other than CLI because the WP-API should take care of this eventually (fair enough, but until then we're kind of stuck with the current solution).
wp-cli/wp-cli#1924 (comment)

[liberatr]

Looks like someone did post a sort of solution, Dec 2016: wp-cli/wp-cli#1924 (comment)