[wp-trac] [WordPress Trac] #21397: Expose post revisions on the XML-RPC Endpoint

[WordPress Trac]

#21397: Expose post revisions on the XML-RPC Endpoint
------------------------------+------------------
 Reporter:  daniloercoli      |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  3.5
Component:  XML-RPC           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  mobile has-patch  |
------------------------------+------------------

Comment (by nacin):

 [attachment:21397.5.diff] looks like a good base. It does need some
 changes. Here is a code review.

 Stylistically:

  * The changes to wp_create_post_autosave() can now be reverted.

  * Some indentation looks off, sporadically throughout the diff. Appears
 to be a tabs versus spaces thing.

 Code-wise, for wp.restoreRevision:

  * wp.restoreRevision's cap checks need to be refined. It should use
 wp_get_post_revision() rather than get_post(), and current_user_can()
 against the revision's parent, not against itself. (Even though
 map_meta_cap() accounts for this kind of mistake.)

  * It should also probably check WP_POST_REVISIONS,
 post_type_supports($post->post_type, 'revisions'), and
 wp_is_post_autosave(). Normally, if either of the first two are false,
 then restoring this revision is only allowed if the revision is an
 autosave — but in practice thee should be blocked from XML-RPC.

  * See the 'restore' branch at the top of wp-admin/revision.php for all of
 this in action.

 For wp.getRevisions:

  * wp.getRevisions's cap checks are off. They are based on the 'post' post
 type. But they should instead be based on the post type of the post ID
 passed. And it should be an edit_post + ID check rather than a generic
 edit_posts check.

  * As above, WP_POST_REVISIONS, post type support, and autosave should be
 checked. If wp_is_post_autosave(), then it should be filtered out. (See
 wp_list_post_revisions() as well as where it is called.)

  * Inside the foreach loop, you can just call current_user_can(
 'edit_post', $post['ID'] ). map_meta_cap() automatically translates
 'edit_post' into the appropriate post type meta cap.

 For only_if_no_new_revision:

  * I am not sure how this works. It looks like getTimestamp() is called on
 the incoming value, but I don't see it converted to an IXR_Date anywhere.

  * Should we do date-to-date comparisons, or check revisions directly? The
 date-to-date comparison (using post_modified_gmt) seems like the best
 option. In that case, it should probably be called only_if_modified_since,
 or something along those lines.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21397#comment:39>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software