XMLRPC failure string should convey disabled status for GET requests, too

[redsweater]

Currently if you issues a plain GET request (e.g. by trying to load an xmlrpc.php URL in a browser), you get the error string provided by wp-includes/class-IXR.php:

XML-RPC server accepts POST requests only.

This is not indicative of any configuration problem when XMLRPC has not been enabled for the blog. Compare to wp-app.php which, in a comparable situation, at least indicates the configuration problem:

AtomPub services are disabled on this blog. An admin user can enable them at ​http://192.168.1.20/wptrunk/wp-admin/options-writing.php

The attached patch changes xmlrpc.php so that it will provide the same type of verbose message as wp-app.php does, allowing clients to see immediately upon trying to access the xmlrpc endpoint URL, that service is disabled:

XML-RPC services are disabled on this blog. An admin user can enable them at ​http://192.168.1.20/wptrunk/wp-admin/options-writing.php

I think this will have a positive impact on providing support e.g. to users of applications that depend on the API. It's a shortcut when debugging functionality to type in the xmlrpc URL into the browser to make sure it's configured correctly, and not spewing any errors.

While I was at it I factored the generation of the string for disabled XMLRPC into a new method errorStringForDisabledXMLRPC().

[westi]

Interesting idea.

I wonder if we should always override GET and uses it as a way to point to documentation as well as giving feedback on enablement status.

[markoheijnen]

It's a interesting idea but I would say close this as wont-fix. The reason is that "POST requests only" is a message for developers. A user never should see that where the disable XML-RPC message is for users.

[markoheijnen]

This isn't really a problem anymore since the XML-RPC is enabled by default (3.5). Also my previous reason still apply