Allow disabling a route for a bundle and adding additional routes for view modes other than 'full'

Updating the issue to split out the multiple displays aspect.

@larowlan I tried this out but can't see how to actually opt out? I see the page display checkbox on the view modes, but the page display setting seen here:

Is not available for me with entity_display_route enabled:

Further to my previous comment / confusion: I think that because this was originally built for the multi display use case, it's fairly complicated for the no display use case. I'm not sure how to resolve this.

Part of the confusion comes from the fact that you have to enable the full page display in order to disable the page route. And the complexity around having this setting per view mode is from the multi requirement.

Basically the ideal UX for the "disable page display" feature is to have a single setting on the content type for whether there is a page display for this content type. I am not sure whether this would then conflict with the multi display later?

We can do that and store it in the same spot for any future functionality

Kept it at node-type until ✨ Support adding additional routes for view modes other than 'full' Active

Awesome! This works:

Quick testing highlights a few of things we need to consider:

1. In this initial screen, it's weird to have 'Display author and date information' enabled since there's nowhere for this to appear without a page display. So this should maybe be unchecked and disabled if there is no page display?
2. By default the node type is still enabled in the main menu in the next tab, which is also weird
3. The standard node creation flow redirects you to view the node you just created, which is a 404
4. The content view links the title to the page display, which is a 404

Feels like we should address these as part of this issue? There are other things like the nodes coming up in the menu UI (separate from the menu settings in the node), and I'm sure other things, that I think could go in a follow up.

In this initial screen, it's weird to have 'Display author and date information' enabled since there's nowhere for this to appear without a page display. So this should maybe be unchecked and disabled if there is no page display?

This is in node.html.twig in the node module, so it is used even in teaser view mode

  {% if display_submitted %}
    <footer>
      {{ author_picture }}
      <div{{ author_attributes }}>
        {% trans %}Submitted by {{ author_name }} on {{ date }}{% endtrans %}
        {{ metadata }}
      </div>
    </footer>
  {% endif %}

I think we can fix items 2-4 if we:
* Instead of handling it in the controller, handle it in routing access
* Return a access denied in the routing access which fixes item 2 and 4
* Add a custom exception subscriber that turns the 403 into a 404 in this case _or_ redirects the user to the edit form if they can edit - fixing item 3

Thoughts?

Ah right re: teaser, I should have checked that!

I actually thought of redirecting to edit for #4 already, in which case it also makes sense for #2, even if the flow is a bit unexpected. It is also unexpected to have one listing where in some cases the title links to the view display and some to the form, but it seems like the best option. Though it may need further discussion/thought.

#2 is actually about the menu settings for the node itself, since it's enabled by default, the menu settings option appears in the node edit form. So the routing access change would fix it appearing in the search, but not the menu settings on the form aspect.

... and I just also realised that the URL alias also makes no sense on the form.

The display submitted stuff will eventually be fixed by ✨ [META] Expose Title and other base fields in Manage Display Active , hopefully as part of the XB work although I don't think it's been looked at yet. It should not be on this form at all.

Left a comment on the MR: [#3155569] already handles this at the routing level, would need an alter to set it.

I left that comment before I saw the discussion here about links going to 404s etc. and not sure what the implications of all that are. Seems like a 404 listener that checks if we're on a canonical entity route, checks this config, then redirects to the edit form or throws a 403 might be compatible with using the existing router support?

@catch's suggestion to make use of https://www.drupal.org/node/3155569 → fixed 3 and 4 in a real nice manner

1 I think we have to leave as is because its used in teaser view mode etc
2 I think we should discuss in a follow up, technically its nice because you _could_ create all the content for a node type and then turn on the display to launch that content type.

I'll work through any remaining test fails. I addressed all the fails locally from the last pipeline except nightwatch, which look random

Yeah this is great! So to confirm:

• On node creation, it redirects you to the admin/content page and displays a success message
• In the view, the title is not linked

This makes way more sense to me than redirecting to the edit page. And agree the other things can be follow ups.

2 I think we should discuss in a follow up, technically its nice because you _could_ create all the content for a node type and then turn on the display to launch that content type.

Which 2 is this referring to? I'm not really sure about this scenario because you'd be creating all of the content without ever being able to see it? Why would you not just use bulk publishing or workspaces for this?

One detail to note, the description for the Display settings vertical tab only represents the already existing checkbox, so i suppose the description in the vertical tab would have to be adjusted to cover both checkboxes?

@rkoller it looks OK in #12, are you seeing something different?

oh i havent looked at the microcopy of the vertical tab in your screenshot in #12. then yeah for me it looks different, it looks like that:

but after seeing your screenshot i've rechecked the other content types. turns out the content type i'Ve created and you are seeing the screenshot for is showing that old description. but the article and basic page content type have updated that description in line to your screenshot in #12 and i've created another content type now which is also showing the description shown in #12.... NO idea how that could have happened to the content type i'Ve first looked at and tested. sorry :/

Ha, all good, I am glad it's working!

Maybe I'm missing something here, but isn't this what you would use content blocks for?

Nodes are already hard to define - are they a page, an article, a post, who knows? - are we just making them even more ambiguous?

@aaronmchale this requirement came from Drupal CMS/Product managers who don't want people to have to choose upfront. @lauriii and @pameeela would be the best people to discuss it with

I think the IS summarises the use case well. I can't say that I have ever considered using blocks for microcontent, for a number of reasons, but they and other existing solutions don't offer the flexibility of converting to a normal page in the future.

So I do understand where the motivation for this is coming from, but to elaborate further on what concerns me:

Let's imagine for a moment you're delivering a Drupal training session to people who have never used Drupal before but are maybe familiar with other CMS's, you start by trying to explain to them what nodes are. You explain that content types are like pages and posts in WordPress. You then explain that content blocks are reusable pieces of content that can be embedded in other parts of your site, whether that be on a page, in the header, footers, sidebar, etc. There's a pretty clear distinction there, but with this change I worry that we're making it harder for new users to understand what they should be using nodes and blocks for. Because now, with this change, you explain blocks, but then you also explain that nodes can do the same thing, and so someone asks what's the difference between nodes and blocks, and now you probably don't have as good of an answer.

We already have a difficult time describing to new users what nodes are, are they pages, posts, articles, all three... In the Drupalisms working group how we name and describe nodes is a problem that we're very much aware of. I worry that this change would only make it harder to define what nodes are.

A while back, at a usability group meeting we were presented with an issue which would have added a "View" tab to blocks, and after a long discussion our recommendation was not to do that, and at most to add a "Preview" option, so you can still see what the rendered content block looks like, but it's still clear that content blocks are not meant to be pages. Our worry then was the same, that we would be blurring the lines between nodes and blocks.

Drupal by design has a huge amount of flexibility in how you can structure entity types and fields, and as a result of that it may be confusing at first for new users as to what the purpose of all these different types are - blocks, nodes, media, taxonomies, etc - and what makes each different and when to use them. With that in mind, I do feel that Core needs to do its best to make it clear what the purpose of each of these different types are.

An alternative solution to this problem could be to look at the Storage module → , it's a module I've personally used, it provides an entity types where the entities can be used for storing arbitrary data, can be embedded in other entities, or can be viewed on their own.

Again, I do understand the motivation here, I'm just not sure that the solution is to blur the lines between nodes and blocks and by doing so make it harder to clearly communicate the differences.

I join @aaronmchale here. I think the solution to content standardization is to provide a "universal" entity type: Storage is the best solution for this IMO.

I am struggling to understand your objections @aaronmchale. Firstly, I don't see this affecting the use of blocks, or how to explain them. I really just don't see the link at all to blocks, they are not a solution to this problem in my experience. I agree that it can be hard to define what they are to new users but I don't think this feature adds to that.

Storage or Microcontent → are viable alternatives, but as noted in the IS, the intention is to provide flexibility to leverage the display in the future. I have had this happen several times on client sites where we started out with a stub-like content type but later used the full page; or vice versa, we initially had a page but turned it into a stub.

The existence of Rabbit Hole with >60k installs is pretty good evidence that this is a feature people want. Most importantly this doesn't prevent you from using Storage or blocks if you prefer that?

To me (and the others on the Drupal CMS team) the ideal situation would be to make nodes flexible enough that we don't need alternative entity types provide by Storage or Microcontent for this use case. Then all of your content is managed in one place, which to me seems much easier to explain? (Note though I am not suggesting we should replace blocks with nodes, only the node-like content.)

Explaining Nodes as pages is already a simplification of the reality because they are not just pages. This is why we are already not calling them Pages, but Content in the product. I believe that for a non-technical user the easiest way to explain Nodes is by the purpose that a Content Type has in the specific site; e.g. product, product collection, event, blog, press release, etc. They may generate a page but often they are used for more than that. For example, a product could generate a page, but it could be also used for "micro-content" because you may want to create a list of products or embed a product as part of a blog post.

When you have a page that is not modeled (i.e. Basic Page), it is just a page because it provides only limited re-use. XB plans to separate this from the re-usable modeled content: 🌱 [Research] Landing page integration Active . Based on user interviews we conducted this spring, this maps well with the mental model that users have. Here's an anecdote from one of the interviews:

Interviewer:

You have this content type called page. What is that?

Participant:

That's actually the content type that I use the most. Whenever we have something that's got more like set structure, that's when we use a content type that is more kind of identified and clear. But whenever we have something that needs to be a little bit more flexible, we use the page. Page is much more bare bones than the more specific content types.

Many products like Webflow, Framer, Wix explain Nodes as CMS collections. I think this is a smart way of explaining modeled content to the site builder. It's communicating that unlike pages, modeled content is something that allows you to create lists besides being able to have a page. While their content modeling capabilities are more limited than what Drupal has, I believe that they do a better job at explaining their content modeling capabilities in relation to unmodeled content. I don't think we can adopt this quite as is because in Drupal you can create lists that combine multiple content types.

How does Block Content fit this thought process? Unlike Nodes, Block Content is for content that you would never want to display as a page or list for the end-user. It could be used for example for a hero that you want to display on multiple pages or a cookie banner. It would be rare for someone to create a page for a hero block or a list of hero blocks for other than administrative purposes.

This allows us to explain why for example Location should be a content type, and not a type of Block Content; because it's something that you may want to be able to list for the end-user, it's something that you may want to expose as a page. This helps explain why we need this change; to allow site builders to create modeled content without forcing them to have a canonical page for it.

Thank you @pameeela and @lauriii for providing more insight and motivations behind this, much appreciated.

This allows us to explain why for example Location should be a content type, and not a type of Block Content; because it's something that you may want to be able to list for the end-user,

When I read this, I think it started to make a lot more sense to me. Initially I was approaching this from the perspective of reusable pieces of content that you might add into a page via layout builder, or embed in a sidebar. Which I think we can all agree is probably what you would use blocks for. But if we consider the example of a Location content type and Location content, which would be structured content and used in a specific way; As you say, you want to display that content not as pages, but instead embedded in a View or elsewhere, that's where I can now see the potential in this.

I was trying to think of other types of content which would be suited to this, and I think a really good example of where this might be used is with a Person/Staff Profile content type. Let's say initially your a small team, and you create a staff profile content type, you only want these to be displayed in a list and you use Views to do that, you don't want people going directly to each individual profile. Over time, the team size grows, so you have more profiles, the fields also start to grow, maybe initially you only had a few basic fields, but gradually more rich fields are needed, like a photo, a biography, links to social media. Eventually you realise you need these profiles to be their own pages, but you still want a list of all of them. That graduate evolution of the content as the needs of the business evolve will defintiely be a lot easier to deal with if you don't have to do any kind of migration or rebuilding of that content!

I think Profiles are actually a really good example of where this feature could be used, it's a good example of a content type that might grow organically over time, I think this is the kind of thing you were getting at @pameeela ?

This then brought me to another though, I was thinking about the example of Locations, and how at The University of Edinburgh, our new course/programme content types are supported by a number of taxonomies, we have a location taxonomy for our various campuses, a taxonomy of awards, a subjects taxonomy, taxonomies of our schools and colleges, and more. We actually don't want people directly navigating to any of these term pages, there's nothing of value on them! These vocabularies all exist to facilitate a common set of terms, being able to filter on those in the backend using Views exposed filters, and to facilitate facet filtering using Search API. This all got me thinking that this option would be even more useful on taxonomy vocabularies. So if this hasn't already been considered, I would strongly support adding this option to vocabularies/terms, in addition to nodes.

Where this leaves content blocks, I agree with what @lauriii said:

Unlike Nodes, Block Content is for content that you would never want to display as a page or list for the end-user. It could be used for example for a hero that you want to display on multiple pages or a cookie banner. It would be rare for someone to create a page for a hero block or a list of hero blocks for other than administrative purposes.

Looking more at what Experience Builder is doing, I do wonder if the role of content blocks will be significantly reduced. Right now, a lot individual content in a Layout Builder page is a content block, but Experience Builder won't be taking the same approach, and reusable content could be something different.

So in summary, I now have a much clearer view on how this feature could be used, I no longer think it conflicts with the role that content blocks have, and so I'm very much in support of adding this and even expanding it to taxonomy terms (where it may see even more usage than on than it would on nodes).

So if this hasn't already been considered, I would strongly support adding this option to vocabularies/terms, in addition to nodes.

The current MR almost supports this, the main (only?) thing missing is the route provider logic which is node-specific. For taxonomy terms that might be further complicated because the taxonomy/term/n page is usually overridden by Views, so maybe a bit extra to make it work for taxonomy terms but otherwise all the bits are there. I think we should have a follow-up for applying this to taxonomy terms, the use-case makes sense.

Could also be good to replace media's standalone_url: false setting with this too? But probably also in its own issue because that would involve bc/deprecation for the existing setting.

+1 for expanding this outside of Node in targeted follow-ups.

Thank you @lauriii for a very helpful explanation of the use case and overall context for this! This description of nodes vs blocks is super helpful.

Totally agree re: taxonomy (and media) follow up as well.

Working on this to some extent, alongside ✨ Support adding additional routes for view modes other than 'full' Active , as they share a common base.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Tagging for release highlights and a change record. Would be great if we could summarize the discussion above in the CR since I think it will help people understand the new feature.

dpi → changed the visibility of the branch 3483304-add-support-for to hidden.

dpi → changed the visibility of the branch 3483304-add-support-for to active.

dpi → changed the visibility of the branch dpi-path-variants--view-modes to hidden.

"Standalone node URL" really does not sound right

What about 'Dedicated content URL'? It's not great but we can change that later.

Did not get into 11.1.

@catch I stubbed follow-up issues for what you mentioned in comment #13.

✨ Expand support for disabling a route to all entities Active
✨ Replace media's standalone_url: false setting with support for disabling a route Active

Those issues need more specific details, which I don't know, but at least the issues exist. Anyone who knows more, please edit those issues.

@larowlan Thanks for making the change record drafts!