[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):

 Replying to [comment:4 Denis-de-Bernardy]:
 > Replying to [comment:3 pbiron]:
 > > 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.

 I'll accept that :-)  But since I wasn't around when the decision was made
 I didn't want to put my foot in my mouth not knowing what went into the
 decision.

 BTW, one of the checks my `save_post` action is doing is making sure that
 there is only 1 sticky post in any given category (to avoid some of the
 problems mentioned in #23336, where users "forget" to unstick posts).

 It also accomplishes something similar to the `Featured_Content` class in
 the bundled twentyfourteen theme: allow certain posts to be marked as
 being available to be displayed in a special sidebar, in which case they
 should not be sticky (this is the part that's giving me trouble with
 `stick_post()` being called after my `save_post` function.

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

 Then maybe I misunderstood your first comment...because the above sounds
 like you're agreeing with me that `{un}stick_post()` should be called
 '''before''' `wp_{insert,update}_post()` (and I took your first comment as
 arguing against that).

 And what you said above gave me an idea for a possibly better "fix" than
 that in my original description: we could remove '''all''' the existing
 calls to `{un}stick_post()` and replace them by a function hooked (with
 the lowest possible priority number) to `save_post` in core.  This would
 guaranteed that they are called '''before''' any plugin's `save_post` and
 clear up the "conceptual" problem as well.

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