You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SSH: Allow to specify path of remote wp-cli or full command #5245
Describe your use case and the problem you are facing
The SSH feature is incredibly convenient as it allows my web agency to manage 40+ WordPress installation from a central point regardless of where they are hosted.
In particular, it is so useful being able to specify the path parameter for each site directly in the YAML config file.
However, our clients use different hosting providers; each remote machine has a different location for wp-cli, which is not always accessible through wp.
To make things worse, most of the times we do not even have sudo access.
I know there are ways to solve this problem, but AFAIK they require to alter something on the remote machine (docs) and they might not be that intuitive (see for example #5219).
Describe the solution you'd like
It would be so convenient to have a wp-cli-path option in config.yaml where the user can specify the location of the remote wp-cl installation:
The main advantage of this approach is that the only action required on the remote machine would be to do the curl command to get wp-cli.phar.
In particular, there would be no need to mess with the $PATH or other environment variables, or with PHP files.
Why is it not possible for you to configure the machine once to set it up for WP-CLI? If you can curl the Phar file, you should also be able to rename it and point PATH to it as well for the SSH user...
Can you elaborate on what specific issues you're facing with this?
That's actually how we do it now :-)
For us, having the feature would just be a convenience matter: we prefer to have everything in a single file configuration shared amont the team (config.yaml) than having to mv + modify$PATH on each remote server.
In general, it makes sense not to force the user to use wp as the executable.
Maybe I have different versions of wp installed and depending on the case I might want to use a different one...
But I understand this is not something crucial, it's just a minor UX improvement... so no problem if you decide to close the issue.
Fails for me as I cannot run shellscripts (=file with shebang plus execution flag) on my webhost at all.
So I can not execute the wpi-cli.phar file at all (also if renamed to "wp" and with execution flag) .
I have to invoke it as php ~/bin/wp.
I aliased wp to php $HOME/bin/wp in my .bashrc which I source in my .bash_profile.
That way I can use wp just fine when logged in via SSH in the interactive shell.
But running wp --ssh on my Mac to call the remote wp on the webhost, which runs in the non-interactive shell, the aliases don't seem to be defined in that non-interactive shell environment.
The path is not a problem, it get's through, which this test shows:
On the webhost created my ~/.ssh/environment like this
# export PATH="$HOME/bin:${PATH}" # That won't help b/c the PATH is not the problem but that execution is forbidden.
alias wp="php $HOME/bin/wp" # Trying to create an alias with the "php" invocation prefixed
Invoking from my Mac again fails:
$ wp theme list --ssh='webuser@webuser-ssh.services.mywebhost.com:12345/data/web/webuser/html/apps/mydomain-production/'
bash: /data/web/webuser/bin/wp: Permission denied
So the ~/.ssh/environment was obviously ignored, likely the sshd on the webhost has PermitUserEnvironment=no.
Because it actually again invoked wp via $PATH so as ~/bin/wp which is the phar, whose execution on that webhost seems forbidden.
3) Using the before_ssh hook (on the client machine, my MacBookPro)
WP_CLI::add_hook( 'before_ssh', function() {
$host = WP_CLI\Utils\parse_ssh_url(
WP_CLI::get_runner()->config['ssh'],
PHP_URL_HOST
);
switch( $host ) {
case'example.com':
<!-- Executing the wp-cli-phar file seems to be forbidden hence I decativate this -->
<!-- putenv( 'WP_CLI_SSH_PRE_CMD=export PATH=$HOME/bin:$PATH' ); -->
<!-- Alternatively attempt: Set alias in remote environment -->
putenv( 'WP_CLI_SSH_PRE_CMD=alias wp="php $HOME/bin/wp"' );
break;
}
} );
When calling wp now in it's short form (as the parameters are in the config.yml) it first echoes the contents of pre-ssh.php except the last line } ); and then comes the password entry which works, and then again fails with permission denied. Btw, that echoing of the PHP part always happens, also if I remove the comment lines and have only a single line between the case line and break line.
$ wp theme list
wp theme list
WP_CLI::add_hook( 'before_ssh', function() {
$host = WP_CLI\Utils\parse_ssh_url(
WP_CLI::get_runner()->config['ssh'],
PHP_URL_HOST
);
switch( $host ) {
case 'example.com':
<!-- Executing the wp-cli-phar file seems to be forbidden hence I decativate this -->
<!-- putenv( 'WP_CLI_SSH_PRE_CMD=export PATH=$HOME/bin:$PATH' ); -->
<!-- Alternatively attempt: Set alias in remote environment -->
putenv( 'WP_CLI_SSH_PRE_CMD=alias wp="php $HOME/bin/wp"' );
break;
}
webuser@webuser-ssh.services.mywebhost.com's password: # Password entry works fine.
bash: /data/web/webuser/bin/wp: Permission denied
Did I get anything wrong?
Or is wp-cli: php wp-cli.phar the only possibility to get remote wp running on a webhost configured like mine?
After 1.5 days of research and trial'n'error and tears and sweat, I finally found a 4th method which also works on the most restrictive webhost! I integrated this to the manual and created this pull request: Running commands remotely: On restrictive webhost handbook#425
Hope this manual addition will help those who arrive to this issue here and similar/related issues:
Nevertheless I also vote +1 for this issue here, b/c if you could simply specify wp-cli: php wp-cli.phar it would spare you to jump through all the hoops outlined in the comment above.
The odyssey outlined in the comment above is a true testimonial that this feature would simplify the situation with tricky/restrictive webhost configurations a lot!
Activity
schlessera commentedon Jun 25, 2019
Why is it not possible for you to configure the machine once to set it up for WP-CLI? If you can curl the Phar file, you should also be able to rename it and point
PATHto it as well for the SSH user...Can you elaborate on what specific issues you're facing with this?
coccoinomane commentedon Jun 25, 2019
Hi @schlessera, thank you for your reply!
That's actually how we do it now :-)
For us, having the feature would just be a convenience matter: we prefer to have everything in a single file configuration shared amont the team (config.yaml) than having to
mv+ modify$PATHon each remote server.In general, it makes sense not to force the user to use
wpas the executable.Maybe I have different versions of
wpinstalled and depending on the case I might want to use a different one...But I understand this is not something crucial, it's just a minor UX improvement... so no problem if you decide to close the issue.
Cheers,
Guido
endriu84 commentedon Apr 28, 2020
I also think that this would be a great UX improvement if I could just type:
in my wp-cli.yml
porg commentedon Dec 13, 2022
👆
wp-cli: php wp-cli.pharmay be the only possible way to get remote wp working on some webhosts like mine.The official instruction Making WP-CLI accessible on a remote server lists 3 possibilities which all failed for me:
1) Copy WP-CLI binary to $HOME/bin
wpi-cli.pharfile at all (also if renamed to "wp" and with execution flag) .php ~/bin/wp.wpto php$HOME/bin/wpin my.bashrcwhich I source in my.bash_profile.wpjust fine when logged in via SSH in the interactive shell.wp --sshon my Mac to call the remotewpon the webhost, which runs in the non-interactive shell, the aliases don't seem to be defined in that non-interactive shell environment.2) Specify the $PATH in ~/.ssh/environment
~/.ssh/environmentlike this~/.ssh/environmentwas obviously ignored, likely thesshdon the webhost hasPermitUserEnvironment=no.wpvia$PATHso as~/bin/wpwhich is the phar, whose execution on that webhost seems forbidden.3) Using the before_ssh hook (on the client machine, my MacBookPro)
/usr/local/bin/wp — Was installed via brew.
~/.wp-cli/config.yml
wpnow in it's short form (as the parameters are in theconfig.yml) it first echoes the contents ofpre-ssh.phpexcept the last line} );and then comes the password entry which works, and then again fails with permission denied. Btw, that echoing of the PHP part always happens, also if I remove the comment lines and have only a single line between thecaseline andbreakline.Did I get anything wrong?
wp-cli: php wp-cli.pharthe only possibility to get remote wp running on a webhost configured like mine?porg commentedon Dec 13, 2022
Yes!
After 1.5 days of research and trial'n'error and tears and sweat, I finally found a 4th method which also works on the most restrictive webhost! I integrated this to the manual and created this pull request:
Running commands remotely: On restrictive webhost handbook#425
Hope this manual addition will help those who arrive to this issue here and similar/related issues:
WP_CLI_SSH_PRE_CMDshould be shown when executing remote calls #5196Nevertheless I also vote +1 for this issue here, b/c if you could simply specify
wp-cli: php wp-cli.pharit would spare you to jump through all the hoops outlined in the comment above.The odyssey outlined in the comment above is a true testimonial that this feature would simplify the situation with tricky/restrictive webhost configurations a lot!
coccoinomane commentedon Dec 14, 2022
Thank you for pointing out this
~/.bashrctrick, @porg 💪I agree that
wp-cli: php /home/wp-cli.pharwould be more convenient, but at least now we have a workaround that works withoutsudoprivileges.porg commentedon Dec 14, 2022
@schlessera @danielbachhuber do you consider this feature?
porg commentedon Dec 14, 2022
@coccoinomane could you maybe adapt your issue title to include the command prefix possibility:
SSH: Allow to specify path of remote wp-cli plus command prefix
[-]SSH: Allow to specify path of remote wp-cli [/-][+]SSH: Allow to specify path of remote wp-cli or full command[/+]