Web links in console output

[schlessera]

If we want to bridge the gap between the console (where the "product" is being used) and the web (where the "product" is being documented and worked on), we need to define in what form hyperlinks can or should be used in console output.

Also, as raised in wp-cli/db-command#25 (review) , not every link might be useful as strictly user-facing content.

[danielbachhuber]

Here's a neat example of including links in error messages: https://twitter.com/zeithq/status/909491222175199233

[schlessera]

They are using a tiny URL forwarding server to make the error links shorter.

I'm not sure we need that, though, as we have `https://wp-cli.org, which is already pretty short.

I like the idea of having one central location for storing the error messages, though. It provides a layer of abstraction between the error links and the actual documentation. This means that we change and restructure the documentation without needing changes in the source code, we just need to adapt the links in these centralized error messages.

How about creating a repository wp-cli/error with entry point error message documentation?
So, if you're argument XYZ was invalid, you'd get a detailed error message link to https://wp-cli.org/error/invalid-xyz, which would open the wp-cli/error/invalid-xyz.md document on GitHub (or within one of our real sites).

The markdown document can then contain a short explanation of what the issue is, some standard ways of getting rid of the error, and links to the extensive reference documentation.

[danielbachhuber]

I'm not sure we need that, though, as we have `https://wp-cli.org, which is already pretty short.

Good point.

How about creating a repository wp-cli/error with entry point error message documentation?

I like the idea of putting these in a repository. My preference would be to continue to use wp-cli/handbook though. These could live in a subdirectory.

[danielbachhuber]

Closing in favor of wp-cli/ideas#71