WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #12702, comment 58


Ignore:
Timestamp:
10/18/2014 06:02:26 PM (5 years ago)
Author:
boonebgorges
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12702, comment 58

    initial v1  
    1 IMO implementing the filter proposed in [attachment:wp_admin_meta-boxes.2.diff] is a non-started because of the workflow issues raised in nacin's comment here: https://core.trac.wordpress.org/ticket/12702#comment:28. A filter is an invitation to developers to add sticky post types. But simply making CPTs sticky is pretty lousy UX out of the box, because "sticky" is ambiguous between (a) stuck to the top of CPT archives, (b) stuck to the top of the home page when the CPT is included in the home page query, (c) stuck to the top of the home page no matter what. I'd wager that a fair number of users would expect any of these to be the behavior of the checkbox, which suggests that a checkbox is not a great UI for it.
     1IMO implementing the filter proposed in [attachment:wp_admin_meta-boxes.2.diff] is a non-starter because of the workflow issues raised in nacin's comment here: https://core.trac.wordpress.org/ticket/12702#comment:28. A filter is an invitation for developers to add sticky post types. But simply making CPTs sticky is pretty lousy UX out of the box, because "sticky" is ambiguous between (a) stuck to the top of CPT archives, (b) stuck to the top of the home page when the CPT is included in the home page query, (c) stuck to the top of the home page no matter what. I'd wager that a fair number of users would expect any of these to be the behavior of the checkbox, which suggests that a checkbox is not a great UI for it.
    22
    3 #23336 reenforces the decision, as it demonstrates that sticky support - even for posts - is not on solid ground. Encouraging devs to enable sticky CPTs will encourage a greater number of stickies, which will exacerbate these latent performance issues.
     3#23336 reenforces the decision, as it demonstrates that sticky support - even for posts - is not on solid technical ground. Encouraging devs to enable sticky CPTs will encourage a greater number of stickies, which will exacerbate these latent performance issues.
    44
    5 Making sticky logic work for CPTs is going to be a larger project. As [https://core.trac.wordpress.org/ticket/12702#comment:45 mbijon suggests], this is a great opportunity to a feature plugin to show a better way to implement stickies, both in the UI and the underlying architecture. However, I disagree with this quote:
     5Making sticky logic work for CPTs is going to be a larger project. As [https://core.trac.wordpress.org/ticket/12702#comment:45 mbijon suggests], this is a great opportunity for a feature plugin to show a better way to implement stickies, both in the UI and the underlying architecture. However, I disagree with this quote:
    66
    77> The reason we think it's a core issue is b/c stickies aren't currently filterable. We can't build a plugin that affects them directly. (a plugin that adds a "stickies" taxonomy, sure, but it wouldn't be any different from adding a tax' in your theme)