WordPress.org

Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 3 weeks ago

#5366 closed defect (bug) (fixed)

XMLRPC interface misinterprets mt_allow_comments value

Reported by: redsweater Owned by: josephscott
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.3.1
Component: XML-RPC Keywords:
Focuses: Cc:

Description

WordPress's XMLRPC interface makes an understandable mistake when interpreting the mt_allow_comments field.

The field as described and used by MovableType and others is actually a ternary value with integer values meaning:

0 - None - No comments allowed
1 - Open - Comments can be read and write
2 - Closed - Comments can be read but not written

WordPress doesn't have a notion of "read-only comments" but it needs to do something accurate when the "2" (closed) value is passed to the XMLRPC interface.

Right now what it does is fail to recognize 2 as a valid input, and defaults to the system default comment status.

I believe it should map "2" -> "closed" so that the expected behavior of halting further comments is obtained by the user. The typical scenario now is that the blog defaults to "open" comments, so when a user of a client application specifies "closed" for the comment status, the server defaults it back to "open" ... exactly the opposite of the user's desire.

Attachments (1)

xmlrpc.php.diff (511 bytes) - added by josephscott 14 years ago.

Download all attachments as: .zip

Change History (6)

#1 @josephscott
14 years ago

Added patch makes zero and two do the same thing for mt_allow_comments.

#2 @westi
14 years ago

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

(In [6347]) Correct support for mt_allow_comments to cover all possible values. Fixes #5366 props redsweater/josephscott

#3 @lloydbudd
14 years ago

  • Milestone changed from 2.5 to 2.4

#4 @desrosj
3 weeks ago

In 51442:

Media: Document edge cases with the new image_editor_output_format filter.

More testing has revealed that the image_editor_output_format filter has some interesting edge cases that developers should be aware of when electing to use this filter (see #53667 and #53668).

Because this is a new filter that was intended to be used for experimenting with different ways to handle generating image sizes and has not yet been adopted in the wild, expanding the inline documentation is an acceptable temporary solution while these edge cases are explored further and addressed.

Props mikeschroder, antpb, desrosj, adamsilverstein, ianmjones.
See #5366, #53668, #35725.

Note: See TracTickets for help on using tickets.