[wp-trac] [WordPress Trac] #37114: Allow short-circuiting `get_post_class` for performance

[WordPress Trac]

#37114: Allow short-circuiting `get_post_class` for performance
-------------------------------+------------------------------------
 Reporter:  bordoni            |       Owner:  davidbaumwald
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:  6.1
Component:  Posts, Post Types  |     Version:  4.2
 Severity:  normal             |  Resolution:
 Keywords:  has-patch commit   |     Focuses:  template, performance
-------------------------------+------------------------------------
Changes (by SergeyBiryukov):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 It looks like the `wp_` prefix was [https://github.com/WordPress
 /wordpress-develop/pull/3092#discussion_r946203161 added for better
 namespacing]:
 {{{
 -       $taxonomies = apply_filters( 'post_class_taxonomies', $taxonomies,
 $classes, $class, $post->ID );
 +       $taxonomies = apply_filters( 'wp_post_class_taxonomies',
 $taxonomies, $classes, $class, $post->ID );
 }}}
 > namespace all the things: Core hasn't been great at this but it's nice
 to do for new items.

 I see the point and I would agree in most cases, especially for filters in
 newer functions:
 * `wp_post_revision_title_expanded`
 or when the function already has a `wp_` prefix:
 * `wp_link_pages_args`
 * `wp_list_pages_excludes`
 * `wp_page_menu_args`
 * `wp_get_attachment_link`

 However, I think it is also important to take into consideration
 consistency with the existing filters:
 * `post_class`
 * `body_class`
 * `comment_class`

 It has been a long-time practice in core for hook names to start with the
 function name. There might be occasional exceptions to this, e.g. when the
 `get_` prefix is removed, which is what we see here, but that still
 matches the functions that are just wrappers of the respective `get_*()`
 versions:
 * `post_class()` ← `get_post_class()`
 * `body_class()` ← `get_body_class()`
 * `comment_class()` ← `get_comment_class()`

 If we start deviating from this, I believe it would add more
 inconsistencies to core, and make it harder to remember which hooks have
 the `wp_` prefix and which don't without looking each time in the
 developer reference. Since we are bound by the backward compatibility
 promise, it's not always feasible or worth deprecating the older hooks
 just for better namespacing, and I think having a mix of `wp_*` and
 non-`wp_*` hooks without a predictable pattern is not ideal.

 So I would suggest using the `post_class_taxonomies` name to match
 `post_class`. Curious to see what others think.

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