XMLRPC: wp_editPage doesn't work if username or password contains special characters

[redsweater]

If a user's password contains a special character that would be escaped by the XMLRPC class's escape() method, then it ends up being doubly-escaped and thus prevents authentication from succeeding when calling through to mw_editPost().

Although far less likely, a similar problem will cause an escaped character in either the page ID parameter or the username parameter to also end up being doubly-escaped, causing either authentication error or a page lookup failure.

A canonical example of this bug would be to create a user 'admin' with password 'abc"123'. Efforts to edit a page via wp_editPage will result in the password being first escaped in wp_editPage to 'abc\"123' and then escaped a second time in mw_editPost to 'abc
\"123', at which time it will fail to authenticate the user.

wp_editPage is the only method among the WP page methods that calls through to an underlying method in a problematic way. Other methods either pass through the $args directly to an underlying method, or else handle the database lookup independently of other methods that would escape the parameters on their own.

The attached patch addresses the problem by escaping parameters for the purposes of wp_editPage's own authentication/validation, but passing through the original parameters unescaped so that they may be escaped in mw_editPost to obtain the expected value.

I realize it is preferable to switch clients to the post-based wp API methods, but since this fix is limited in scope to the wp_editPage method, and is a clear improvement, I hope you will accept it as a fix for clients who have not yet updated or may never update to the newer API methods.

[redsweater]

Patch to correct behavior of wp_editPage and avoid double-escaping arguments

[dd32]

In 32993:

XML-RPC: Only escape what we need to in wp.editPage, this allows for passwords with the special characters "' to work in a request.
Props redsweater for initial Patch.
Fixes #32703

[dd32]

Switched it up a little bit, as there was no need to escape the page ID since it's forced to an integer.