#16985 closed defect (bug) (fixed)
XML-RPC endpoint set the datetime when saving a Draft
Reported by: | daniloercoli | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | XML-RPC | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description
When uploading a draft post from one of the WordPress mobile apps the post date is set to the current time/date, even if the datetime field is not specified on the client request.
This could cause issues, because when you change the post status to "publish" it will be published using the date set during the first upload.
On the web dashboard if you do not set the post datetime explicitly, it is not set and hitting publish will then populate the datetime field with the current time.
The same happens if you start a draft on the web and then you publish it using any mobile apps.
details here: http://ios.trac.wordpress.org/ticket/826
Attachments (6)
Change History (36)
#5
@
14 years ago
did you try to upload a post/page setting the date_created_gmt field, and the post_status as "draft"?
I just tried, and seems that the patch doesn't work, the datetime value is completely ignored by the server.
#6
@
14 years ago
No i have not.
In my understanding i do'nt think draft post has an attribute post_date_gmt
When the mw_newpost passes the args to wp_inset_post it will always set
the $post_date_gmt to 0000-00-00 00:00:00
The patch works for the explained scenario where you upload a draft at day1 and publish
it at day 7
It will show the published date as day 7
Correct me if i,m wrong
#7
@
14 years ago
@nprasath002 -- yes, the patch works like you said.
The fact is that on the web dashboard you can set the publishing date even for a draft post.
I think we should replicate the same behaviour on mobile clients.
#8
@
14 years ago
When setting a publishing date to a 'draft' post the post_status is set to 'future' in the webdashboard. But metaWeblog method does'nt support post_status 'future'.
try this patch and when sending a 'draft' post to be published in a future date
set the post_status to 'future' and send it with a publishing date.
Keen to know the results
#9
@
14 years ago
I started a new post on my dashboard. I set the publishing date to 30 April and saved it as draft.
This is the dump from the db:
'114', '2', '2011-04-30 10:39:54', '2011-04-30 10:39:54', 'this is the content', 'Title of a draft post scheduled', , 'draft', 'open', 'open', , , , , '2011-03-30 10:42:20', '2011-03-30 10:42:20', , '0', 'http://localhost/wordpress31rc3/?p=114', '0', 'post', , '0'
The post is marked as draft, and the publishing date is correctly set.
I reopened the draft post and clicked on the schedule btn. the post status is changed to "future" (will be live on the blog in the future).
I think we cannot set the status to "future", for a draft post (post status = draft) that has the publishing date set to a future datetime. This post will be "live" on the blog at the defined datetime. The user has explicity set the post as draft, so we can't change it.
#10
@
14 years ago
I attached a patch that set $post_date_gmt to 0000-00-00 00:00:00 in wp_inset_post when no date_time_gmt is passed within the request.
The patch always returns the parameter date_created_gmt set to '19700101T00:00:00' for draft posts that have the date_created_gmt field set to 0000-00-00 00:00:00. EX: <member><name>date_created_gmt</name><value><dateTime.iso8601>19700101T00:00:00</dateTime.iso8601></value></member>
This should prevent crashes on external clients.
#11
follow-up:
↓ 13
@
14 years ago
I'm very hesitant/careful about making date/time interaction changes to XML-RPC. This is one of the most fragile areas, it is very easy to break clients by changing the behavior here.
I'd like to see some comparisons to how other clients (like Mars Edit and Windows Live Writer) are dealing with this.
#12
@
14 years ago
yes, we should be very careful. I have set the date to January 1 1970, when it is missing into the db, instead to keep it empty in the xml-rpc response to prevents crashes on the client side. I will check with other 3rd-party clients.
#13
in reply to:
↑ 11
@
13 years ago
Replying to josephscott:
I'd like to see some comparisons to how other clients (like Mars Edit and Windows Live Writer) are dealing with this.
Tried MarsEdit with the latest patch and works fine
#14
@
13 years ago
I’ve been seeing a weird workflow between MarsEdit and Wordpress that’s been causing problems when I attempt to schedule future posts. A few days ago, I nailed down the exact workflow and the cause. It looks like it stems from this discussion.
The general workflow is when taking a draft post and publishing it, from MarsEdit, with a future date/time. Here’s the specific workflow that causes problems.
- Create a new post (using the web interface)
- Save Draft, from the web interface (don’t change the date/time at all,
leave it at the default of Publish Immediately)
- Open post (using Mars Edit)
- Change publish date (using Post -> Edit Date)
- Change status to Published
- Send to server
After sending the post to the server, you’ll have a new post that was published immediately, not a new post scheduled for a future date.
If you create the new post using MarsEdit (instead of the Wordpress web interface), you don’t have this problem. If you publish the post using the web interface (instead of MarsEdit), you also don’t have this problem.
I tracked the problem down to wp_update_post in wp-includes/post.php
. That function clears the post_date
and post_date_gmt
fields (from the XML-RPC interface) if all of the following are true:
- the post is a draft
- the
post_date_gmt
is '0000-00-00 00:00:00' - there is no
edit_date
variable defined, in $postarr.
I experimented and determined that when draft posts are created from Wordpress’s web interface, the post_date_gmt
is always set to
'0000-00-00 00:00:00'. Because wp-includes/class-wp-xmlrpc-server.php
never does anything to set edit_date
in $postarr
, it's not possible to change the post date until after the post has been published.
I created a patch to wp-includes/class-wp-xmlrpc-server.php
, to set edit_date when the XML-RPC client sends a post date. I'm not sure if that's the best way to fix this problem, but it works for me.
#19
@
13 years ago
I moved this to 3.4 because it appeared it was likely fixed with the new methods. No longer appears to be the case.
Setting edit_date makes sense as the fix here.
#21
@
13 years ago
- Cc ercoli@… joseph@… n.prasath.002@… jalkut@… removed
- Keywords needs-unit-tests punt added
If someone can write unit tests for this, I would feel better about proceeding come 3.5.
#25
@
12 years ago
Just curious. Is this a issue in the new wp methods? We don't use edit_date there so I can see we maybe also have a issue there.
#27
@
9 years ago
- Milestone changed from Future Release to 4.4
- Owner set to wonderboymusic
- Status changed from new to assigned
If the date time is not specified we do'nt need to set that in mw_newpost
wp_insert_post will take care of it.