wp.newPost fatals when a post_date field is included in the data

[dllh]

In _insert_post(), we assume that $post_data['post_date'] and $post_data['post_date_gmt'] are already IXR_Date objects, when they're not. These are converted in the wp_editPost() function but are not converted either in wp_newPost() or in _insert_post(). The result is that if you submit an xmlrpc request that includes post_date or post_date_gmt, you get this fatal error:

Fatal error: Call to a member function getIso() on a non-object in /root/wordpress-develop/src/wp-includes/class-wp-xmlrpc-server.php on line 1200

I'm attaching a patch that fixes it and a couple of unit tests that demonstrate the error. To repro:

1. Apply the unit test patch but not the xmlrpc patch.
2. Run the tests.

You'll see the fatal error as the tests run. Apply the xmlrpc patch and run the tests again, and the error is gone.

I've basically copied the method that was already being used in wp_editPost(), with some checks for existence of the data added, since there's not a certainty that it'll be submitted.

[dllh]

Patches the xml-rpc server code to fix the fatal

[dllh]

Unit tests to demonstrate the issue

[dllh]

Note: I wrote the unit tests to demonstrate the issue and not necessarily to be added to the unit test suite. I'm not sure they're really all that useful as ongoing tests. It was just an easy way to show that the fatal occurred before the patch and went away after.

[SergeyBiryukov]

I wonder if these checks should go into _insert_post() method instead, where most of the validation happens.

[dllh]

Replying to SergeyBiryukov:

I wonder if these checks should go into _insert_post() method instead, where most of the validation happens.

That was actually my first impulse, and the first version of the patch (not attached). I moved it out of that function with these thoughts in mind:

• Maybe somebody had a good reason for putting the validation in wp_editPost(), so following that model was perhaps a good first step.
• It's possible somebody extends the xml-rpc server with custom code that does its own checks. If they're convertng in their function (because we're not) and we reconvert in _insert_post(), we'll introduce another error. Introducing higher in the stack seemed both consistent with past code and safer going forward. Of course, we could add an is_a() check or something to prevent double conversion.

I'd be happy to rework the patch to move the validation into _insert_post() if you think that's better, though. What say you?

[SergeyBiryukov]

I see, thanks for the clarification. Looks good to me.

Related: [19848], [20153].

[SergeyBiryukov]

In 28854:

XML-RPC: Make sure wp.newPost does not produce a fatal error when a post_date field is included in the data.

props dllh.
fixes #28601.

[westi]

While this fix introduces some consistency is also breaks some clients.

Previously this worked fine:

<member><name>post_date_gmt</name><value><dateTime.iso8601>20140630T08:46:25</dateTime.iso8601></value></member>

This gets parsed into an IXR_Date and then we try and treat is as a string :(

I think we need to make new and edit post accept both dateTime.iso8601 in the structs and dates as strings.

The get function will return dateTime.iso8601 which make a strong ease of use argument for supporting it in the other methods.

[westi]

In 29061:

XMLRPC: Improve the test case from [28854] so that it truely tests an invalid date string like the test name implies. See #28601.

[westi]

In 29062:

XMLRPC: Extend the test cases from [28854] so that we also test valid date based strings. See #28601.

[westi]

In 29063:

XMLRPC: Restore support in wp.newPost for dates to be supplied in the structured dateTime.iso8601 format as well as still supporting dates specified as strings.

Fixes #28601.