wp-app.php handles "updated" element incorrectly on PUT

[tvachon]

wp-app.php handles "published" element incorrectly on PUT

Looks like a typo. Patch attached.

[tvachon]

Patch to fix what looks like a typo preventing <published> handling on PUT

[tvachon]

This bug is preventing atompub clients from being able to update timestamps on already published entries.

[westi]

(In [6635]) Ensure APP clients can update timestamps on publish. Fixes #5680 props tvachon.

[rubys]

With this change in place, ​APE now ​reports an error:

! In entry with title 'Entry Mini-4', app:edited values out of order, d Fri Jan 18 13:15:36 UTC 2008 ld Fri Jan 18 13:15:27 UTC 2008.
! Entries feed out of order after update of multi-post.

Investigating...

[tvachon]

From rfc 4289:

The "atom:published" element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry.

vs.

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant.

which, IMHO), corresponds better to "changing the timestamp" of an entry.

It looks like [6635] allows for this well, with line 335 changing from

$pubtimes = $this->get_publish_time($parsed->published);

to

$pubtimes = $this->get_publish_time($parsed->updated);

I haven't tested out APE with this change in place, but I'll give it a shot when I get a chance.

[rubys]

Allow AtomPub to update the updated/modified date for entries

[rubys]

I've attached a patch that I'm comfortable with. It reverts the above change for the reason that "tvachon" gives above... published is meant to be early in the publishing cycle, so is not the way to signal a change. It then adds the ability to change what Atom calls the updated time (internally, Wordpress tracks this as post_modified and post_modified_gmt).

With this patch, Ape tests pass again.

[ryan]

Looks like wp_update_post() always sets the modified times to the current time when updating.

	if ( $update ) {
		$post_modified     = current_time( 'mysql' );
		$post_modified_gmt = current_time( 'mysql', 1 );
	}

Seems that passing post_modified and post_modified_gmt to wp_update_post() wouldn't actually do anything.

[rubys]

Replying to ryan:

Seems that passing post_modified and post_modified_gmt to wp_update_post() wouldn't actually do anything.

I have yet to figure out why that code is not working, but if you look ​here and scroll down a bit you will see a number of entries with 1999-11-30T00:00:00Z timestamps. I don't know where that date is coming from. With this patch, post_modified and post_modified_gmt get passed to wp_update_post() and are stored properly.

The last I heard, the next release of WordPress was scheduled for the end of January. I don't know if that has moved, but I would like to request that either this patch be included or the previous patch be backed out before the release is made.

I'm also changing the summary.

[DD32]

Replying to rubys:

The last I heard, the next release of WordPress was scheduled for the end of January.

2.4 will be skipped, 2.5 is the next release.

​http://wordpress.org/about/roadmap/

[lloydbudd]

Replying to rubys:

I don't know if that has moved, but I would like to request that either this patch be included or the previous patch be backed out before the release is made.

rubys, I think you are correct, that is a good first step, if there are lingering concerns with your patch. Ryan or Westi can you commit:

svn merge -r6635:6634 ​http://svn.automattic.com/wordpress/trunk

Replying to DD32:

2.4 will be skipped, 2.5 is the next release.

​http://wordpress.org/about/roadmap/

Hmm, that still lists 2.4 . I've sent a note reminding Matt. ​http://trac.wordpress.org/roadmap has been updated for some time, but of course 2.5 date is written in sand.

[westi]

(In [6645]) Fix the updated times when publishing/editing with APP. See #5680 props rubys.

[bentrem]

Replying to rubys:

With this change in place, APE now ​reports an error:
"In entry with title 'Entry Mini-4', app:edited values out of order, d Fri Jan 18 13:15:36 UTC 2008"

I'm looking at that report on interwingly. "app:edited values out of order" does not exist. And the report presented there is Sat, 02 Feb 2008 21:07:25.

No indication on that page of what fault was identified.

[rubys]

Replying to bentrem:

Replying to rubys:

With this change in place, APE now ​reports an error:
"In entry with title 'Entry Mini-4', app:edited values out of order, d Fri Jan 18 13:15:36 UTC 2008"

I'm looking at that report on interwingly. "app:edited values out of order" does not exist. And the report presented there is Sat, 02 Feb 2008 21:07:25.

I provided a patch on 21 Jan 2008 which corrected that particular problem, and seemed to also address the issue described by this ticket. This patch was applied on 23 Jan 2008. The URI I provided is captured output from runs that I make every hour that there happens to be a commit to the WP SVN.

Ryan noted that on 22 Jan 2008 that the patch I supplied shouldn't work, and in fact I can't explain why it appears to.