Extend documentation with more examples, http use
AoiRei opened this issue · comments
I was trying to install WP theme via http. Used this command:
wp theme install https://wordpress.org/themes/adaption/ --allow-root --http=http://video.xxxxxxxxxx.info/ --debug Debug (bootstrap): No readable global config found (0.006s) Debug (bootstrap): No project config found (0.006s) Debug (bootstrap): Loading packages from: /root/.wp-cli/packages/vendor/autoload.php (0.094s) Debug (rest): No schema title found for /, skipping REST command registration. (0.795s) Debug (rest): No schema title found for /oembed/1.0, skipping REST command registration. (0.796s) Debug (rest): No schema title found for /oembed/1.0/embed, skipping REST command registration. (0.796s) Debug (bootstrap): ABSPATH defined: / (0.797s) Error: This does not seem to be a WordPress install. Pass --path=path/to/wordpressor runwp core download.
The website of course is a WP install, so i am not sure what is the problem, but i think i may be missing something in the params.
I am pretty sure there also needs to be username and pw in the params for it to work, but i dont see that in global params.
Agreed! I've been monkeying around with the --http flag for weeks and haven't been able to make it do anything yet, so any additional documentation is extremely welcome!
I agree that the documentation is lacking in that area.
Know that the --http flag is used to connect to a site using the WP REST API. What it does is discover the endpoints available on that site, and then map these endpoints to WP-CLI commands.
This means, though, that it will only work on WP REST API enabled sites and it only works for the available endpoints the site offers. There is no WP REST API endpoint to install a theme, so the above cannot currently work.
Here's an example (using my own site, for lack of a better example) of how to fetch the list of post titles through the restful interface:
wp rest --http=https://www.alainschlesser.com post list --field=title
This should help you get started.
Also try the following to get help on the discovered endpoints:
wp help rest --http=https://www.alainschlesser.com
Ah. That makes a bit more sense. The problem then, is that as far as documentation goes, it appears that the --http or --ssh flags are basically interchangeable as far as functionality goes. But from what you say, it sounds like the --http flag is only used for interacting with WordPress via the REST API, and that it requires the wp-cli/restful package (Is that on the you run the remote command from only? Or does that also include the server side of things?)
When you say that a site needs to have the WP REST API enabled, what exactly do you mean? I was under the impression that it was enabled by default, but running the wp --http=domain rest list --field=title returns Couldn't auto-discover WP REST API endpoint from domain, so it seems there is something else that I need to do config-wise on that server?
The wp-cli/restful package needs to only be installed on the machine we're you're executing WP-CLI. Contrary to the other connection methods, it does not connect with a remote WP-CLI installation, but rather directly connects to the WP REST API endpoints. WP-CLI does not need to be installed on the remote server at all for this to work.
The discovery of the REST API endpoints uses the https://api.w.org/ rel link provided through the page's <head>section:
If you don't have something like that, you are either running a WordPress Core version that is too old, or you might have some security plugin installed that removes this rel link to reduce exposure.
Interesting... (thanks for getting back to me on this, by the way, I really appreciate it).
An example site that I am trying to run commands against is teknik.byu.edu.
Running wp rest --http=pam.byu.edu help yields Error: Couldn't auto-discover WP REST API endpoint from teknik.byu.edu.
However, running wp rest --http=teknik.byu.edu/wp-json help yields Error: This does not seem to be a WordPress install. Pass --path='path/to/wordpress' or run 'wp core download'.
Looking at the response headers for the two pages:
https://teknik.byu.edu/wp-json only has one link in the response header, which is the correct api.w.org one.
https://teknik.byu.edu has two links in the response header, the first being the api.w.org one, the second being the shortlink.
Looking at your site https://www.alainschlesser.com, and its homepage, it only has the one link, to api.w.org, no shortlink.
Could the shortlink link in the response headers be causing the problem in auto-discovery?
Briefly looking at the code for auto-discovery in the repository at https://github.com/wp-cli/restful/blob/master/inc/Runner.php line 98:
$bits = explode( ';', $response->headers['link'] );
if ( 'rel="https://api.w.org/"' !== trim( $bits[1] ) ) {
return false;
}
It looks like the code is assuming (is that correct?) that there will be only one link in the response headers. Could that be what's throwing the auto-discovery process off?
The problem of the auto-discovery was fixed at #109.
Great! Thanks for getting back to us on this, much appreciated.