[wp-trac] [WordPress Trac] #28172: edit_post() should call {un}stick_post() before calling wp_update_post()

[WordPress Trac]

#28172: edit_post() should call {un}stick_post() before calling wp_update_post()
-------------------------------+------------------------------
 Reporter:  pbiron             |       Owner:
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by pbiron):

 I'm not sure, in this context, what you mean by "side effect"...since
 conceptually sticky is a property of a post.  The fact that sticky is
 implemented as an option (rather than as a column in the wp_posts table)
 has always seemed odd to me and have figured that it was done that way for
 some obscure technical reason.

 Also, the [http://codex.wordpress.org/Plugin_API/Action_Reference
 documentation] on the `save_post` action says "Runs after the data is
 saved to the database." and in this case, I think a good argument can be
 made that the `sticky_posts` option should be considered part of the
 "data" that "is saved to the database" before `save_post` is fired.

 Given that the `wp_xmlrpc_server` class has 2 functions that call
 `{un}stick_post()` before calling `wp_{insert,update}_post()` and 1 that
 calls them in the same order as `edit_post()` at least points out that
 there is inconsistency on this matter in core.

 But, yes, as a stopgap measure I guess I could implement my plugin using
 the `option_sticky_posts` filter but that seems like a '''very''' obscure
 workaround.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28172#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform