[wp-trac] [WordPress Trac] #36666: Enhance `remove_theme_support()` so that it can take additional arguments

WordPress Trac noreply at wordpress.org
Sat Apr 30 14:02:51 UTC 2016


#36666: Enhance `remove_theme_support()` so that it can take additional arguments
------------------------------------+------------------------------
 Reporter:  flixos90                |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Themes                  |     Version:  3.0
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------------

Comment (by jmichaelward):

 Replying to [comment:13 flixos90]:
 > Replying to [comment:12 jmichaelward]:
 > The problem with `get_post_types_by_support()` is that it does not have
 to do with theme support. When you call this function on the
 `after_setup_theme` hook, it will always return an empty array because the
 post types are not registered at this point (since `after_setup_theme`
 executes before `init`). That's why I meant we cannot use this function.
 Sorry, maybe my original post was unclear there.

 I had to set this ticket side for a few days to think about it, as you're
 right that custom post types, when registered correctly, are not retrieved
 by `get_post_types_by_support`. It does not appear, however, that
 `get_post_types_by_support` returns an empty array when called. Instead,
 it returns four: `post`, `page`, `attachment:video`, and
 `attachment:audio` These same four array values are returned whether
 `get_post_types_by_support` is called outside of an action or within one,
 such as `init`.

 Something that threw before is that WooCommerce appears to be registering
 its `product` post type sooner than `init` (which, of course,
 [https://codex.wordpress.org/Function_Reference/register_post_type goes
 against the documentation]), so it was getting returned in my previous
 attempts to resolve this ticket.

 '''My question now is: what if we're chasing the wrong problem? What if
 the issue here is the idea that theme support is sometimes stored as a
 boolean value (when options are not passed), and sometimes stored as an
 array?'''

 Ticket [https://core.trac.wordpress.org/ticket/22080 #22080] perpetuated
 this thinking a bit, as we simply exited if theme support was already set.
 What if, instead, we just never saved `theme_support` as a boolean?

 My latest patch (36666.4.diff) updates `add_theme_support` to set `$args`
 to the value of `get_post_types_by_support( 'thumbnail'` )` if either
 `$args` or `$_wp_theme_features[ 'post-thumbnails' ]` is set to `true`.
 From then on, any post type that registers and adds theme support for post
 thumbnails will have its post type pushed to the array, as before. In
 addition, post thumbnail support can be removed in functions.php, as long
 as the function is called during the same action (or later) in which a
 post type's support was added. So, in the case of WooCommerce, post
 thumbnail support for products can be removed in `after_setup_theme` (but
 not before), and in the case of other custom post types,
 `remove_theme_support` must be called in `init` for it to work. Otherwise,
 it just fails silently.

 Also, since HTML5, Post Formats, and Post Thumbnails would ultimately run
 the same kind of check, I decided to take @flixos90's previous advice and
 put everything back into a single switch, because it's far more
 streamlined.

 Potential issues for consideration:

 1. Currently, when users register a custom post type and indicate that it
 supports a theme feature, such as post thumbnails, that support is
 automatically updated. That would not be the case with this patch, so
 revisions would need to be made to append the post type to the array for
 post thumbnails (and eventually html5 and post formats).

 2. Theme and plugin developers may be running a check to see if a theme
 currently supports a particular feature. Hard (`===`) checks for post
 thumbnails would fail, because the value would no longer be boolean.
 However, populated arrays are truthy in PHP, so this change shouldn't have
 any additional effect.

 All this said, I don't consider this patch "done" by any means, but
 welcome discussion on the potential positives and challenges with
 implementing this approach.

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


More information about the wp-trac mailing list