Disable core's default entity listing pages when Views is installed

I don't think this needs a setting. It feels like a pretty niche requirement -- if a site needs this level of customisation, it can remove the routes in core.

I think this is an ordinary feature request for Drupal Core rather than an ideas queue issue.

I don't think this needs a setting. It feels like a pretty niche requirement -- if a site needs this level of customisation, it can remove the routes in core.

I tried to leave out the back and forth thoughts on this in the OT here which has been made on Slack with @catch and @longwave when I was trying to describe the UX tests and confusion by users. But here I wanted to focus on the scenario. But it actually was a result of thinking about the behavior confusion users experience when they do not know that there is a entity list in core actually just overriden by Views. ANd this is not only when they want to remove them but also when they want to put them on other paths. That's exactly what this issue is after. And this is not a niche.

I think this is an ordinary feature request for Drupal Core rather than an ideas queue issue.

Agree. Wasn't sure about it at the first glance after the Slack conversation, but yeah. It actually is a tiny enhancement in the settings. That's why I like it. Because it changes a lot. And at first it stops the confusion of one list exchanging the other without knowing from where it comes. :-)

if a site needs this level of customisation, it can remove the routes in core.

I think this does not stand in a good relation. To simply turn off the entity list pages (and maybe turn on later again) and that therefor somebody should change core (not in UI) is far more than a simple checkbox. I think this is a useful feature unless the efforts for this settings are to big and it breaks other things.

As suggested in Slack I think we should only enable the fallback listings if Views module is disabled. I don't see the need for a separate checkbox, especially one that will be configured exactly once when first setting up a site. If you have Views then you can customise or even delete the admin listings if you want, if you don't have Views then you get hardcoded listings.

As suggested in Slack I think we should only enable the fallback listings if Views module is disabled.

Yeah this would be another option to solve this and I gave my thumbs up on this in Slack. This issue here was the result of finding a compromise between

we could consider relying on views for these admin pages and removing the custom controllers

at one hand and

someone somewhere probably has an edge case site where they do not use views at all

I don't see the need for a separate checkbox...

The link on listing pages to a setting with a checkbox would solve multiple issues in one strike. At very first it would make clear that this is not the Views view but the core entity listing at this moment. And I can see so many circumstances where people would like to arrange the admin/content place different. Other tabs order etc. And it all is tight connected to how you set the admin paths in the Views. So you are forced to change such paths to get another admin/content experience. Especially when many admin views come into play. And it will always be interrupted by system routes coming into mix and turning back on the common paths.

...especially one that will be configured exactly once when first setting up a site.

I don't see only use cases where it will be setup once. I see many scenarios where it will turned on and off for testing purposes.

The reason why I ended up on this compromise is that at one hand I stand for the importance of fixed core routes and its advantages not only for system logic and common use/sense in handling a known system and also for performance reasons. But I think it is a huge performance win to be able to turn parts of it simply off. Not only to override it with Views but to NOT run that route in the moment - it is simply turned off. But again, maybe I am mistaken and disabling such routes in core is simple enough to leave it as it is.

Changing title to the better task.

All in all I think this would be the fastest way to remove the underlying issue I initially have addressed and which has lead me to the idea/compromise to advocate for a on/off setting solution after some brainstorming. All the back and forth lead me to the settings idea. But I see why an on/off settings is very opinionated and it actually wasn't my initial thought. My initial thought was: why we do still have entity listings in core when we provide them with Views in standard profile in a much more flexible way? So, yes, disabling them when Views is installed should be the proper issue task I think.

You can hide these with permissions
Feels like won't fix to me, if your need something more we have APIs for alerting routes
I don't think this setting belongs in core

You can hide these with permissions

Hiding is not the intention here. And brings maybe other problems to the table with the replacement listings on that path. And hiding with permission is an unnecessary new request for the purpose actually wanting to disable them. Which is far better from performance perspective.

Thanks for chiming in here @larowlan. Why does it feel like a "won't fix"? Can you elaborate on this?

And I am confused about ...

I don't think this setting belongs in core

(maybe language, not my native tongue)
... or do you mean this should be solved in contrib, with that statement?

Yes this could live in contrib as a new project, but even then it feels too niche and should probably be in a custom module.

Marking on that basis.