Trunk Regression: XML-RPC could fail with erroneous disabled status

[redsweater]

Some users are noticing that the use of 3rd party apps such as the official WordPress app, MarsEdit, etc., are failing because the server is reporting that XML-RPC services are disabled:

​https://wordpress.org/support/topic/xml-rpc-services-disabled?replies=10

It traced the problem to documentation changes made here:

https://core.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=27730%40trunk%2Fsrc%2Fwp-includes%2Fclass-wp-xmlrpc-server.php&old=27554%40trunk%2Fsrc%2Fwp-includes%2Fclass-wp-xmlrpc-server.php&sfp_email=&sfph_mail=

The changes starting at line 194 add multiple lines to what was previously a 1 line statement following an unbracketed if statement. The result is the line following the comment is now executed unconditionally:

$enabled = apply_filters( 'option_enable_xmlrpc', true );

I suspect the case being encountered by users in the forum thread is one where "option_enable"xmlrpc" is filtering to false but the filter should not even be reached by the intended logic.

Adding braces around the (now commented) single line seems to address the issue.

[redsweater]

Patch to fix logic broken by inline documentation

[redsweater]

Update: thanks to dd32 in IRC for pointing out the affected revisions are not in the 3.8 branch. I jumped to the wrong conclusion, but as it happens this might cause trouble down the road instead if not patched ;)

[redsweater]

Revision 2 eliminates the superfluous documentation on the back-compatibility checks.

[redsweater]

Changed the title to further reflect the probably less serious nature of this bug.

[SergeyBiryukov]

The changes starting at line 194 add multiple lines to what was previously a 1 line statement following an unbracketed if statement. The result is the line following the comment is now executed unconditionally:
$enabled = apply_filters( 'option_enable_xmlrpc', true );

From my reading, that's not the case. It's still a single-line statement, the comment block doesn't affect the logic.

As ​noted in IRC, the issue appears to be caused by Wordfence Security plugin update.

Looks like 27506.5.diff:ticket:27506​ on #27506 is the way to go here.

[ocean90]

Sounds like invalid and as Sergey has mentioned, #27506 is the way to go.

[redsweater]

Agreed - my misunderstanding of how the brace-free block was being evaluated. Thanks and sorry for the noise!