[wp-trac] [WordPress Trac] #12702: Enable sticky post checkbox for custom post type Publish metabox

[WordPress Trac]

#12702: Enable sticky post checkbox for custom post type Publish metabox
-----------------------------+------------------------------
 Reporter:  phlux0r          |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Post Types       |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  dev-feedback     |
-----------------------------+------------------------------

Comment (by mbijon):

 I've been looking deeper at some of the problems with extending sticky
 posts to new CPTs. I think this addresses most of @nacin's concerns,
 although it means some refactoring of stickies to bring them up to
 //basic// conventions the rest of WordPress' content follows:

 === Currently ===
 The current sticky implementation is, first, based on a convention from
 forums, and secondly, may have performance problems on site with 100,000's
 of posts (I work on a site nearly that big, and wouldn't be surprised if
 frequently-updated sites like TechCrunch aren't well beyond that).

 === Big Content: UX & Performance Conventions ===
 Sticky posts are currently treated like a permanent fixture that needs to
 be manually set & unset. This is based on old forum conventions where any
 sticky post would show at the top of the forum until a mod "unstuck" it.

 Our "vision" of sticky posts is based on the idea of limited windows-of-
 content. Everything else we build in WP now is based on easily-paginated
 post queries. With big sites able to "flood" the screen with content --
 main feeds, comments, tags & even categories are limited to the top X of
 any content type. This is more or less required to prevent both unreadable
 sidebars and performance issues from huge query results.

 This "window" or LIMIT idea is the same idea we (myself & @sphoid at
 least) have for sticky posts. No more manual on/off for stickies, just
 show the most-recent X of them and let site owners write instead of
 unsticking things
 (And really ... with @sphoid's filter implementation plenty of older
 themes could keep using stickies just like they always have)

 === Current Sticky Limitations ===
 Letting stickies build up & filtering the most-recent seems pretty
 straightforward. We use a database for that, right? "All" content and
 options in WordPress are stored in really flexible database row-formats
 that we can query & LIMIT ... or not. //Stickies are stored in a single
 option row as a serialized array//

 **What!?!**

 Allowing stickies to **not** be managed by admins/editors would mean an
 ever-expanding single field in the database, and ever-expanding query
 result (even if we try to limit it), and eventual performance issues. Even
 links, which are solidly down the deprecation path, weren't stored like
 this.

 Risking a ticket-change or diversion... //Stickies need a refactor// --
 Even if they're not filtered like in @sphoid's patch, I think we need to
 pull the current serialized format out into DB rows.

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