WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 11 months ago

Last modified 11 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 11 months ago.
Patch to fix logic broken by inline documentation
XMLRPCLogicFix2.patch (1.0 KB) - added by redsweater 11 months ago.
Revision 2 eliminates the superfluous documentation on the back-compatibility checks.

Download all attachments as: .zip

Change History (11)

@redsweater11 months ago

Patch to fix logic broken by inline documentation

comment:1 @redsweater11 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 @redsweater11 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

@redsweater11 months ago

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

comment:3 @redsweater11 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 @dd3211 months ago

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

comment:5 @SergeyBiryukov11 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 @ocean9011 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 @redsweater11 months ago

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

comment:8 @redsweater11 months ago

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

comment:9 @SergeyBiryukov11 months ago

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