post edit should use local EDITOR not EDITOR on the server

[nextgenthemes]

Feature request

Turns out I was wrong about vi being hardcoded.

I changed this to a feature request.

WP-CLI seems to have the wrong concept of "local" at least for installing plugins from zip file, it requires the file to be on the server that is the opposite of "local". The edit command never speaks of local anywhere I guess but I think its the same thing. WP-CLI should do things where you call it, locally, not on the server.

[nextgenthemes]

I do not intend to learn vi or vim btw.

In case someone cares, here is my wp-update-page script that takes the slug as argument.

#!/bin/bash
set -Eeuxo pipefail

id="$(wp @stage post list --field="ID" --name="$1" --post_type=page)"

wp @stage post get "$id" --field="post_content" > /tmp/temp-page.html

codium --wait /tmp/temp-page.html

wp @stage post update "$id" --post_content="$(cat /tmp/temp-page.html)"

[mrsdizzie]

It does use EDITOR when EDITOR is set in environment:

https://github.com/wp-cli/restful/blob/78a717bb41dfecd003a7088a0d862aaa1b455f85/features/bootstrap/utils.php#L341-L357

And defaults to vi if it is not set. So something is causing EDITOR not to be set. I looked and the previous closed ticket said:

If I'm logged into my web server via ssh

But that is technically a bit different than running a command remotely (via alias) which is described here. You could verify what wp-cli thinks the EDITOR value is on the remote server by running:

wp @stage eval "echo empty(getenv('EDITOR')) ? 'EDITOR is empty' : getenv('EDITOR');"

I suspect it would be empty. This is just a guess, but I know a default in lots of .bashrc files is to have something like this near the very top:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Which causes it to exit if it isn't an interactive SSH login. So that might be preventing it from running if your export EDITOR=nano code is below that. If that is the case, you can move the export command above that code and it should work. If not, something else is causing the .bashrc code to not run for a non interactive session but the code above should help debug that.

[nextgenthemes]

@mrsdizzie Thanks, that is exactly it. Moved the export above that line and it works now. I do not get why a ssh session that may as well be interactive and it actually is in this cases opening an editor and w8ing for user input not counts as interactive.

I still think the command should use the local editor. Also looking at the code is tries to launch notepad on windows. Notepad is a GUI app, does that even work? I never used windows server and I should not care at all but it seems to make no sense to me. I know there is x-forwarding, but windows does not use X server so that can't work. I also looked it up and there is a "Windows server core" that is actually headless so I am curious.

// And it seems I am right https://superuser.com/questions/186857/how-do-i-edit-text-files-in-the-windows-command-prompt

This suggests it should be edit and there are comments "notepad does not work over ssh" and "This will not work in a Docker container based on 'windowsservercore' " confirming my guess.

[dsXLII]

By "local" editor, do you mean the editor that is defined on the machine from which you're connecting (as opposed to the machine into which you are connecting remotely)? That would be very unusual; off the top of my head I can't think of any *nix-flavored utility that works that way.

For doing "local" edits, I think a better approach is to do a wp post get, save that to a temp file, edit it, then wp post update to push your changes. You could probably make an argument for extending wp post edit to take an optional param defining what editor to use, and use that to do your editing remotely, but that feels like a potential minefiield.

[danielbachhuber]

I moved this to the main repo because it's more of a framework issue.

I agree that the developer experience of aliases and --ssh is less than optimal. However, I'm not sure that "remote environment magically uses local environment configuration" is necessarily the solution either.

I'd be open to reviewing a more holistic proposal, if someone wants to do the research, get feedback from users, etc.