Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XMLRPC - Editing a draft post with wp.editPost causes its published date to be set #419

Merged
merged 3 commits into from Jun 18, 2019

Conversation

@bahiirwa
Copy link
Contributor

commented May 27, 2019

Description

Dates being set wrong in posts to WordPress. The issue in summary is that if you have a draft post on WordPress, changing its status to “Published” doesn’t update the publish date from the time the draft was originally saved.

The post has a published date corresponding to the time I first starting writing the post, and when we finally go to publish the podcast, the date remains the same.

Motivation and context

https://core.trac.wordpress.org/ticket/45322

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • Breaking change (fix or feature that would cause existing functionality to change)

@bahiirwa bahiirwa changed the title Editing a draft post with wp.editPost causes its published date to be… XMLRPC - Editing a draft post with wp.editPost causes its published date to be set May 27, 2019

@nylen

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

Thanks for the PR @bahiirwa.

Is this a problem you're experiencing on a live site? What software are you using that communicates with the site using XML-RPC?

@bahiirwa

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2019

Thanks for the review. This was a backport from the core trac issue.

This is not a personal problem to me but there are reports. For context please read this.

For a long time, I heard reports from my customers that dates were being set wrong in posts to WordPress. The issue in summary is that if you have a draft post on WordPress, changing its status to “Published” doesn’t update the publish date from the time the draft was originally saved.

I didn’t really get a handle on this problem until it started affecting me. Sometimes I write the show notes for my podcast, Core Intuition, ahead of the time the podcast actually goes public. In these situations, the blog post has a published date corresponding to the time I first starting writing the post, and when we finally go to publish the podcast, the date remains the same.

Cite: https://bitsplitting.org/2019/05/24/unloved-patches/

Software it applies: https://red-sweater.com/marsedit/

@nylen nylen added this to the Future: v1.0.2 or v1.1.0 milestone Jun 17, 2019

@nylen

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

OK, got it.

Generally when evaluating bugfix PRs I look for these things (ideally all of them)

  • The change impacts existing ClassicPress users. (Otherwise, there are literally thousands of things we could look at, but we need to prioritize our development time.)
  • The change is not going to break any other use cases.
  • The change has automated tests.
  • I understand the change very well, or I can ask questions of someone who understands it very well.

I think this PR meets all criteria except the first one. I understand this part of the code better than I'd like, because I wrote the workarounds for this issue in the WP REST API.

We also discussed it a bit in Slack and decided to accept this one: https://classicpress.slack.com/archives/CCCF22HG8/p1560534419056600

@nylen

nylen approved these changes Jun 18, 2019

@nylen nylen merged commit 41d7d20 into ClassicPress:develop Jun 18, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bahiirwa

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2019

Generally when evaluating bugfix PRs I look for these things (ideally all of them)

  • The change impacts existing ClassicPress users. (Otherwise, there are literally thousands of things we could look at, but we need to prioritize our development time.)
  • The change is not going to break any other use cases.
  • The change has automated tests.
  • I understand the change very well, or I can ask questions of someone who understands it very well.

Could we adopt this in the contributions section of the read me? It might iron out some issues for PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.