[wp-trac] [WordPress Trac] #31165: Custom post types that do not support content should not have an excerpt mode option

[WordPress Trac]

#31165: Custom post types that do not support content should not have an excerpt
mode option
-------------------------------+------------------------------
 Reporter:  m0r7if3r           |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  4.1
 Severity:  normal             |  Resolution:
 Keywords:  close              |     Focuses:
-------------------------------+------------------------------

Comment (by m0r7if3r):

 Replying to [comment:5 DrewAPicture]:
 >
 > I think what both @helen and @knutsp touched on, however, is that those
 fields can still have values despite the post type not "supporting" those
 features. And I agree. People remove post type supports for all kinds of
 reasons, but a very common one is to prevent core from displaying the
 default UIs for managing those supports. I don't think it would be a good
 idea to disable list modes automagically.
 >
 > I believe there's a filter being suggested so the list modes can be
 modified on a per-screen basis. That discussion is happening over in
 #30325.
 >
 > Suggest wontfix.

 While adding a filter for this would work, I don't think that's
 necessarily the best solution.  This discussion might best be included in
 that thread, but I'll put it here and move it if it's deemed relevant.

 It seems to me that the issue is that people want to use a particular
 aspect of a post without supporting it so that it doesn't display in the
 UI.  This use makes sense but, to me, feels like an abuse of supports,
 since you do, in fact, support it, just not for user interaction.  I think
 a better way to accomplish the same thing would be to declare what you
 support and what is desired in the UI separately.  This could be done
 within the `supports` array (eg: 0 for does not support, 1 for supports, 2
 for support and show in UI) or through another arg when registering the
 CPT (perhaps by making `show_ui` an array or maybe an array called
 `ui_elements` that accepts all the `supports` parameters).

 To me, the filter would make sense in addition to this so that if the
 excerpt display needs to be forced on/off, it can, but there's some level
 of automagic to displaying the switcher, as it's likely that if the
 developer doesn't want the user INTERACTING with a field, in most cases
 they won't want them to see what is in it.

 That said, it's likely people are using this in ways that I have never
 considered.  I may be way off base.

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