Limited and experimental support for site Aliases, YML configs and SSH commands is in 1.0.3, but a number of commands have been disabled with these combinations as they are untested yet.
This is a rather complex issue, but one that if solved would make WPX a lot more flexible for managing WordPress installs across servers/hosts as many developers need to do daily.
A local YML config (wp-cli.yml or wp-cli-local.yml) may specify a local install path, which is easy enough to handle given WPX can do this already, but it may also specify an SSH path instead. Further, a site alias could specify either a local path or SSH one.
What complexifies this issue a little is whether the YML config file is a global or specific one. WP CLI unfortunately does not have a switch to specify a local config file, but rather looks in the current path. So the simple solution is to switch to that path first, which seemed to be working - but now does not seem to be. :-/ ( Solution discussion: wp-cli/wp-cli#5136 )
A WP_CLI_CONFIG_PATH environment variable can be set instead, but in the case that someone is using a global config already (ie. /root/.wp-cli/config.yml), a site @alias stored there might be missed if that is overridden by specifying a local config path via that method instead. Sure, the global config could be explicitly inherited by the local config, but that makes things even more complex because wpx has to parse both YML files to try to work things out. While a working YML parser functions are in WPX, this seems like a somewhat hacky solution, and it is preferable to find a way to simply provide the needed config to WP CLI and let it handle it as it knows best. Hopefully just changing directories does work somehow (like it was, not sure what changed that whether WPX or WP CLI) - and hopefully this solution might work via SSH somehow also.
Here is a list of commands which are currently disabled in 1.0.3, because they incorporate some commands that are not issued directly via WP CLI:
- (Install) installcore, reinstallcore (currently use delete functions)
- (Core Locking) - lockcore, unlockcore, checkcorelock, checkowners, fixowners
- updatecore (half-disabled, will work but not with core locking)
- (Delete) - deleteplugin, deletetheme, reinstallplugin, reinstalltheme
- (Rsync) - all of the SYNC family of commands
Given these complexities, finishing off the current enhancements list for version 1.0.5 and 1.0.6 will probably happen first so this can hopefully receive full attention for 1.0.7
Limited and experimental support for site Aliases, YML configs and SSH commands is in 1.0.3, but a number of commands have been disabled with these combinations as they are untested yet.
This is a rather complex issue, but one that if solved would make WPX a lot more flexible for managing WordPress installs across servers/hosts as many developers need to do daily.
A local YML config (
wp-cli.ymlorwp-cli-local.yml) may specify a local install path, which is easy enough to handle given WPX can do this already, but it may also specify an SSH path instead. Further, a site alias could specify either a local path or SSH one.What complexifies this issue a little is whether the YML config file is a global or specific one. WP CLI unfortunately does not have a switch to specify a local config file, but rather looks in the current path. So the simple solution is to switch to that path first, which seemed to be working - but now does not seem to be. :-/ ( Solution discussion: wp-cli/wp-cli#5136 )
A WP_CLI_CONFIG_PATH environment variable can be set instead, but in the case that someone is using a global config already (ie.
/root/.wp-cli/config.yml), a site @alias stored there might be missed if that is overridden by specifying a local config path via that method instead. Sure, the global config could be explicitly inherited by the local config, but that makes things even more complex becausewpxhas to parse both YML files to try to work things out. While a working YML parser functions are in WPX, this seems like a somewhat hacky solution, and it is preferable to find a way to simply provide the needed config to WP CLI and let it handle it as it knows best. Hopefully just changing directories does work somehow (like it was, not sure what changed that whether WPX or WP CLI) - and hopefully this solution might work via SSH somehow also.Here is a list of commands which are currently disabled in 1.0.3, because they incorporate some commands that are not issued directly via WP CLI:
Given these complexities, finishing off the current enhancements list for version 1.0.5 and 1.0.6 will probably happen first so this can hopefully receive full attention for 1.0.7