[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 Denis-de-Bernardy):

 Replying to [comment:3 pbiron]:
 > I'm not sure, in this context, what you mean by "side effect"...since
 conceptually sticky is a property of a post.

 I meant it at a conceptual level from a database design viewpoint:
 worrying about whether we set some kind of sticky property somewhere is
 the kind of thing that ought to be done during or immediately after
 updating the row were things to run within a transaction. This, to avoid
 the use of deferrable constraints or triggers to enforce integrity.

 > 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.

 Nope. I'll spell it out loud for you: it was an utterly absurd design
 decision. WP is paying dearly for it, too — e.g. #23336.

 > 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.

 On paper, doing things correctly would mean that the save_post hook acts
 like a "done updating, whoever wants to do more can do so now" event.
 Nothing should be occurring after wp_update_post() — but nor should
 anything be done before it, for that matter. Hence the remark I made in my
 previous comment: if anything, saving the sticky status should be done
 immediately before or *on* the save_post hook: after the row is inserted
 or updated, and before or while save_post gets called.

 In practice, there's stuff over in `wp_insert_post()`, in
 `wp_update_post()`, in `edit_post()`, etc, etc. and, as you point out, not
 in a very consistent manner.

 > 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.

 Hooking directly into options or transients during reads or writes is
 fairly common in my own experience, due to the occasional lack of sensible
 hooks. There's also e.g. `pre_update_option_sticky_posts` in
 `update_option()` and a few more in `add_option()` and `delete_option()`
 which may come in handy.

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