[wp-trac] [WordPress Trac] #22289: Filter to override WP_POST_REVISIONS (or define it later)

[WordPress Trac]

#22289: Filter to override WP_POST_REVISIONS (or define it later)
---------------------------------------------------+--------------------
 Reporter:  batmoo                                 |       Owner:
     Type:  enhancement                            |      Status:  new
 Priority:  normal                                 |   Milestone:  3.6
Component:  Revisions                              |     Version:  3.4.2
 Severity:  normal                                 |  Resolution:
 Keywords:  westi-likes needs-refresh needs-patch  |
---------------------------------------------------+--------------------
Changes (by westi):

 * keywords:  westi-likes has-patch => westi-likes needs-refresh needs-patch


Comment:

 Replying to [comment:9 ethitter]:
 > As [http://core.trac.wordpress.org/attachment/ticket/22289/22289.patch
 22289.patch] demonstrates, there are a variety of places where
 `WP_POST_REVISIONS` is used, and the data that is available and useful in
 each situation varies. As such, I opted to use `compact()` to ensure that
 a single filter is available, context about the filter calls is provided,
 and whatever data is available in each context is passed as well.
 >
 > From call to call, the `wp_post_revisions` filter will always provide a
 `context` array key in the additional data it passes, and a full post
 object is generally available. Beyond that, consistency is lost. In XMLRPC
 calls, it might be useful to know the username or blog ID of the request,
 whereas uses in `revisions.php` can call for the post, the current
 revision, or the two revisions being compared.
 >
 > For what it's worth, I also prepared a patch that uses a different
 filter in each of the three files impacted by this patch, but that seemed
 like more of a pain for users.

 I'm not a big fan of the current patch it feels a bit too "clever" and
 also a bit too "complex" I think abstracting the current code into two
 functions as I suggested in #comment:1 might make the changes simpler and
 more understandable.

 I think it is worth passing the post type into the filter in all cases and
 re-working the code to make the post_type available in the case where it
 currently isn't.

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