Custom post types that do not support content should not have an excerpt mode option

[m0r7if3r]

Setup

Register a post type that doesn't support anything but titles with show_ui set to true, then view the listing of all posts of that post type in the backend.

Expected Behavior

There should not be an option to show the excerpt overview, since no excerpts can exists, as content is not supported.

Actual Behavior

Excerpt mode is available. Enabling it does not do anything, potentially creating confusion for the end user.

[m0r7if3r]

Shows excerpt view activated but non-functional

[helen]

What if that post type's content is input elsewhere or otherwise generated?

[m0r7if3r]

In my mind, the registration args for the CPT should have support for content in that case, even if the expected input is not through the TinyMCE editor.

[knutsp]

I have a lot of custom post types defines without content, using excerpt as the primary content container. Excerpt is separate column in the posts table, and core sets up a text/html editor for it. Perfect for my use.

Does this proposal make these more difficult to set up and use?

[m0r7if3r]

Replying to knutsp:

I have a lot of custom post types defines without content, using excerpt as the primary content container. Excerpt is separate column in the posts table, and core sets up a text/html editor for it. Perfect for my use.

Does this proposal make these more difficult to set up and use?

I would say that if the post type does not support content OR excerpt, then the option to switch to excerpt view should not show up. If the post type does not support either of these, then it stands to reason that switching between views would not change anything, thus creating confusion.

[DrewAPicture]

Replying to m0r7if3r:

I would say that if the post type does not support content OR excerpt, then the option to switch to excerpt view should not show up. If the post type does not support either of these, then it stands to reason that switching between views would not change anything, thus creating confusion.

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.

[m0r7if3r]

Replying to 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.

[knutsp]

Agree with @DrewAPicture. Closing.