Editing a draft post with wp.editPost causes its published date to be set

[redsweater]

This bug exhibits the exact same behavior as #16985 did for the MetaWeblog-based API before wp.editPost came along. When wp.editPost was implemented, evidently a regression occurred causing the buggy behavior to rear its head again.

The practical effect of this bug is that a draft post submitted by an API client, and then edited by an API client, will have its publish date "locked in time" to the original submission time. So for example if you start a draft post on May 1, and edit it for two weeks before publishing on May 15, the published post will have a publish date of May 1.

To reproduce using the WordPress XMLRPC API:

1. Create a new draft status post using wp.newPost, omitting dates from the submitted post. This results in a post that has a post_date_gmt that is zeroed out, reflecting the fact it should receive the current time when the post is changed from Draft to Publish.

2. Edit that draft post using wp.editPost, again omitting any dates.

Expected result: the draft post should still have zeroed out publish date (post_date_gmt).

Actual result: the post now has a post_date_gmt value matching the original post_date value that was created when the draft was submitted.

The bug appears to be rooted in the wp.editPost implementation in class-wp-xmlrpc-server.php. Because this method uses the existing post struct from the database as a baseline of all submitted content, the post_date value ends up being set on the struct that is passed to _insert_post. But _insert_post makes assumptions about client intent based on the presence of or absence of values on that struct. So in this case the post_date value on the struct is interpreted as being a client-asserted publish date for the post.

I'm attaching a patch with a possible fix, which is to make a point of unsetting the post_date value on the struct whenever the post_date value is missing from the content_struct provided by the API client.

[redsweater]

Patch to fix the described the bug

[redsweater]

I am going to work on unit tests to attach along with the code patch.

[redsweater]

Tests confirming the fix included in the other attachment

[redsweater]

Tests confirming the fix included in the other attachment

[redsweater]

I accidentally added the fix patch twice and don't know how to delete. I added a patch with unit tests. Let me know if there's anything else I can do to encourage incorporating this fix. Thanks!

[pento]

Patch needs review and testing.

[audrasjb]

As per today's bug scrub, we are going to punt this one to the next release since beta 3 and RC are approaching.

[redsweater]

Thanks! I would still love to see this fix taken at some point. I think it's low risk and it will have an immediate benefit for users of apps that publish via the API.

[Otto42]

This seems like a fairly simple fix that should land early in 5.3, for soak.

[redsweater]

Thanks, @Otto42 !

[SergeyBiryukov]

Hi @redsweater, thanks for the great issue description and the patch! I'm sorry a review took so long due to shorter 5.1 and 5.2 release cycles.

The patch and the unit test work as expected.

[SergeyBiryukov]

In 45906:

XML-RPC: Make sure editing a draft post with wp.editPost does not unintentionally cause its published date to be set.

Props redsweater.
Fixes #45322.

[SergeyBiryukov]

In 45907:

Coding Standards: Fix WPCS issue in [45906].

See #45322.

[redsweater]

Hooray, thanks @SergeyBiryukov !