[wp-trac] [WordPress Trac] #23336: Sticky Posts lack sanity bounding. If used too much, can severely degrade performance.

[WordPress Trac]

#23336: Sticky Posts lack sanity bounding. If used too much, can severely degrade
performance.
-----------------------------------------+------------------
 Reporter:  markjaquith                  |       Owner:
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  3.6
Component:  Query                        |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |
-----------------------------------------+------------------
Changes (by mbijon):

 * keywords:  has-patch => has-patch reporter-feedback


Comment:

 Came across this after researching stickies as part of #12702 (it's
 related)

 Short version of what I posted there:
 //Stickies are ridiculous as-is, they need a refactor.//

 ----

 In #12702 I suggested stickies should be refactored to be a taxonomy or
 similar. The patch here reinforces that for me:

 I really don't like the idea of hard-limiting stickies to 100 in core. The
 possibility that this will break user expectations (and existing sites) is
 really high (not many of them, but definitely someone's).

 We definitely should have stickies follow the same conventions as every
 other content & option-type in the DB. I see two options to get there:
 (a) deprecating existing stickies & telling the community to use a
 taxonomy
 (b) upgrading stickies to a built-in taxonomy & then adding code to the
 upgrade process that can detect & parse the existing sticky array into the
 new taxonomy

 Any preferences? I like option (b) -- if there's any support for it then I
 can probably grab @sphoid from ticket #12702 & work on that code (Shy
 about working that deep unless there's support)

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