XMLRPC interface misinterprets mt_allow_comments value

[redsweater]

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.

[josephscott]

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

[westi]

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

[desrosj]

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.

[SergeyBiryukov]

[51442] was meant for #53667.