WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#27746 closed defect (bug) (invalid)

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

Reported by: redsweater Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: XML-RPC Keywords: close
Focuses: Cc:

Description

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.

Attachments (2)

XMLRPCLogicFix.patch (631 bytes) - added by redsweater 13 months ago.
Patch to fix logic broken by inline documentation
XMLRPCLogicFix2.patch (1.0 KB) - added by redsweater 13 months ago.
Revision 2 eliminates the superfluous documentation on the back-compatibility checks.

Download all attachments as: .zip

Change History (11)

@redsweater13 months ago

Patch to fix logic broken by inline documentation

comment:1 @redsweater13 months ago

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 ;)

comment:2 @redsweater13 months ago

  • Summary changed from 3.8.2 Regression: XML-RPC fails with erroneous disabled status to Trunk Regression: XML-RPC fails with erroneous disabled status

@redsweater13 months ago

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

comment:3 @redsweater13 months ago

  • Summary changed from Trunk Regression: XML-RPC fails with erroneous disabled status to Trunk Regression: XML-RPC could fail with erroneous disabled status

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

comment:4 @dd3213 months ago

  • Keywords has-patch commit added
  • Milestone changed from Awaiting Review to 3.9

comment:5 @SergeyBiryukov13 months ago

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.

comment:6 @ocean9013 months ago

  • Keywords close added; has-patch commit removed

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

comment:7 @redsweater13 months ago

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

comment:8 @redsweater13 months ago

  • Resolution set to invalid
  • Status changed from new to closed

comment:9 @SergeyBiryukov13 months ago

  • Milestone 3.9 deleted
Note: See TracTickets for help on using tickets.