Open mlutfy opened 9 years ago
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.
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). https://github.com/wp-cli/wp-cli/issues/1924#issuecomment-122087860
Looks like someone did post a sort of solution, Dec 2016: https://github.com/wp-cli/wp-cli/issues/1924#issuecomment-269881103
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:
While we're at it, it would be nice to have proper logging redirection (wp-cli does an fwrite to STDOUT).