Problem/Motivation

Now that Views is a core module, there are several reasons to convert at least some of core's existing listings to Views:

  • Site builders will be able to customize their sites more quickly.
  • New users will more easily discover Drupal's capabilities and how Views works.
  • There will be less custom listing code to maintain.
  • Having more listings using Views will help focus effort on improving Views going forward.

However, there are also disadvantages to using Views for listings. Views is a complex module with a lot of code weight and a nontrivial amount of technical debt. While efforts to improve Views' UX, DX, performance, and so on are ongoing, we do not want Views to be a required module. A site without Views enabled should still be functional.

Proposed solution

  1. Don't make Views required = TRUE.

  2. But: Make Views required for all (entity) listings. Public and administrative.

    Consequence: Any listing produced by modules will be based on views.module. If views.module is not enabled, then there are no listings.

  3. For administrative listings, figure out how to resolve the architectural challenges. @see you in #1823608: Admin views in core ;)

  4. Enable Views[.module] for all sites in the upgrade path to D8, because at a minimum, node.module is a required module in D7 and produces a public listing at /node. The minority of site administrators who then want to disable Views after upgrading can do so.

In other words:

  • User-facing listings should be Views only, with no alternate versions.
  • Admin-facing listings we can address case by case, but only convert if we can do so in a non-hacky way.
  • We don't cater to the minority of people who are trying to do something serious with Drupal without Views, because they're not using the tool in a supported way to begin with.
  • People with a legitimate use case for custom-coding a listing have no more work to do than they do today. Nothing really changes for them at all.

Proposed resolution (longer, older version)

TLDR: Convert every listing to a View, and install those listings when Views is enabled. Decide when to remove old code and when to use it as a fallback.

In general:

  • Views will not be a required module in Drupal 8.
  • Views will not be added as a dependency for basic site building modules like Node, Field, Taxonomy, etc.
  • Views will be enabled in the Standard profile.
  • Views will not be enabled in the Minimal profile.

Listings in core range from supplementary features (like the taxonomy term pages or the promoted node listing) to listings that are central to their modules' functionality (like listings from the dblog and tracker modules) to listings that are required for basic site administration (like the admin/people user administrative page. The approach we take in each case will differ.

  1. For listings that are supplementary features (like the promoted node listing and the taxonomy term pages):
    • These listings will be entirely converted to Views.
    • The custom code that provides these listings in Drupal 7 will be removed.
    • The listings will become available when both Views and the owner module are enabled.
    • Since the Standard profile includes Views, listings belonging to other Standard modules (like Node and Taxonomy) will be enabled when Standard is installed.
  2. For listings that are required for basic site administration (like admin/people):
    • Optional admin Views will be provided to override the listings when Views is enabled.
    • The existing listing code will not be removed.
    • We plan to factor the legacy, non-View listings into their own module(s).
  3. For listings that are central functionality for an optional module (like the main tracker listing):
    • We will either provide an optional listing that replaces the existing listing when Views is enabled (as in #2), or replace the listing with a View and add Views as a dependency.
    • We may factor the legacy, non-View listings into their own module(s), depending on the particular listing.

Remaining tasks

Related issues

Conversions of normal listings
Conversions of administrative listings

Comments

This plan is wise, and it's a good thing to keep core module not being dependent on Views. I'm happy with 1) and 2) points.

Regarding 3) for other optional modules for which Views could be useful only for admin (e.g. Tracker is not a good example here, so I'm speaking about a subset of 3) I think we could/should separate UI module and functionnal module, pretty much like the separation between Views and Views UI; it's a win-win situation where Views can help building strong admin listing, quickly and easily, and where the modules still can be used on Views-less sites once admin UI is disabled.

How can the node listing or a taxonomy term listing page be supplementary features?

I don't get that. You cannot do anything with your site without those.

That's also in direct conflict with the other statement that Views should not be a required module for D8, because it factually means that it would be required for pretty much every site one can build. Although that statement possibly referred to the technical 'required' .info file flag, it does not change the logical requirement aspect.

In turn, I also don't understand why this proposal suggests to not add it to the Minimal profile. Logically, the proposal would either have to suggest to add it to Minimal, or the logical opposite direction, to remove Node from Minimal.

Personally, I only see two directions that would make logical sense:

  1. Views is turned into a base building block that is required for any kind of listing.

    This means that all modules that need listings need to add a dependency on Views. That essentially means almost all core modules, including Node, Comment, Taxonomy, but also Dblog & Co modules. All of their listing pages are replaced with views-based listings.

  2. Views is an optional building block.

    This essentially means that almost nothing changes compared to now. The only difference is that all modules are supplying default views definitions for their listing pages, which can be enabled, but don't have to be enabled. The views-based listings only take effect when Views module is enabled. Otherwise they do not.

Both directions make sense from a technical and logical perspective. Whether they are feasible to accomplish within the remaining time-frame is a different question.

How can the node listing or a taxonomy term listing page be supplementary features?

I think, but I might have understood, that it was about the frontend/public taxonomy listing page listing (eg. /taxonomy/term/%). IMHO this page is definitely useless on most sites I usually work on because:
1) it is unflexible
2) taxonomy is oftenly used to achieve business stuff
3) using taxonomy accordingly to point 2 doesn't mean listings are needed

So no, I don't agree with all other of your statements since they are based upon this fact. With only node and menu modules, you can build a fully featured site without any kind of listing in the end.

Title:[META] Convert core listings to Views[meta] Convert core listings to Views
Priority:Normal» Major
Issue tags:+Needs architectural review

This is a pretty fundamental decision we need to make, and the direction we choose will have a significant impact on Drupal. Tagging accordingly.

Personally, I only see two directions that would make logical sense:

  1. Views is turned into a base building block that is required for any kind of listing.
  2. Views is an optional building block.

Considering current drupal 7 usage stats:
Drupal: 545,146
Views: 345,492

I think that makes it pretty clear that not everyone needs to use views.

I guess for people that want to avoid using views for their listings can have it enabled and just not use it, and I guess they could override the admin listing views if they needed to, but I'm not huge of having modules enabled that I really don't want to have on my site (although it would be extremely rare for me personally to not use views at all on a site).

Although unless there is a good reason to go with option 1 (like it makes something much better than if we went with 2), I would vote for option 2 as it seems to be win win.

How can the node listing or a taxonomy term listing page be supplementary features?

I don't get that. You cannot do anything with your site without those.

I don't think that's true at all, and I don't see how they're not supplementary features. I have many, many sites that make heavy use of Node and Taxonomy without using either of these features. I've used the promoted node listing maybe once, in 6.5 years. I use the taxonomy/term/% pages maybe half the time, and when I do, I almost always redirect them or override them with Views. (If I don't, it's because I didn't get around to it, and I inevitably think of it as a dangling loose end I never tied up.)

The usecase for Standard is that it does useful stuff when you install it. The proposal here is to keep the promoted node frontpage and the taxonomy term pages in Standard, but as useful Views instead of oft-replaced, inflexible one-off implementations.

Also, I think #2 presents a false dichotomy. We don't have to do all A or all B. Not all listings in core have the same role and importance within their respective modules, which is the case the OP tries to make.

Views is turned into a base building block that is required for any kind of listing.

I think this might be something we consider in D9--i.e., adding Views (but not Views UI) to Minimal and making it required for all listings (edit) that ship with core. In that scenario, you could still choose to disable Views, but it'd be up to you to implement a different solution for your administration panels and such.

However, I don't think Views is ready for that yet. If you prefer, you can think of the OP proposal (along with everything else VDC wants to do in this release cycle) as putting us in a good position to go that direction in a later release, when Views (or some part of it) is ready.

Although unless there is a good reason to go with option 1 (like it makes something much better than if we went with 2), I would vote for option 2 as it seems to be win win.

I think option 2 is a gross oversimplification, and we lose a lot of the advantages described in the summary if don't replace and override some listings.

I think option 2 is a gross oversimplification, and we lose a lot of the advantages described in the summary if don't replace and override listings.

If option 1 has lots of advantages then I'm all for it, however from the summary:

* Site builders will be able to customize their sites more quickly.

No benefit. They can still enable views and do the same.

* New users will more easily discover Drupal's capabilities and how Views works.

Kind of. They can also just enable it with option 2. Still easier than downloading it separately.

* There will be less custom listing code to maintain.

Definite benefit.

* Having more listings using Views will help focus effort on improving Views going forward.

Kind of benefit. Default listings will still be there. Plus we will still see an increase in views usage even including it disabled. There is still nothing stopping contrib modules from requiring it.

However, there are also disadvantages to using Views for listings. Views is a complex module with a lot of code weight and a nontrivial amount of technical debt. While efforts to improve Views' UX, DX, performance, and so on are ongoing, we do not want Views to be a required module. A site without Views enabled should still be functional.

I suppose most people will be using views seeing as so many commonly used contrib modules now rely on it, but it depends whether the huge site performance focused types can be ignored.
I guess they can still get around using views though even if it is required, but the situation wouldn't be ideal for them.

  • Views will not be a required module in Drupal 8.
  • Views will not be added as a dependency for basic site building modules like Node, Field, Taxonomy, etc.
  • Views will be enabled in the Standard profile.
  • Views will not be enabled in the Minimal profile.

Option 1 doesn't support this.

For the record I'm certainly not opposed to option 1 if it provides more benefits.

I think the term and node listings are definitely optional. Sites switch them off via hook_menu_alter() all the time (or sometimes they don't and we take amusing screenshots of 'welcome to your Drupal website' when they don't have any nodes promoted to the front page). You're free to provide listing with EntityFieldQuery and multiple entity views too either in custom modules or contrib, so we shouldn't make views a requirement to use node or taxonomy regardless of whether they ship their own non-views listings or not.

Wouldn't particularly mind views being required for administrative listings as long as there's a way to disable it, how that could be organised not really sure though.

I think the option 2 sun proposed is super-simple, as it is to propose a default EntityListController, which get overwritten when Views is enabled to propose UI-based flexibility.

We move the existing listing custom code into this specific controller.

I think Views is not ready for option 1. Too much technical debt as xjm mentionned but also a Form-based API which is completely unusable right now.

Can we leave aside "option 1 and option 2"? We have more nuanced choices than that. There are dozens of lists in core, and there are many different ways to provide Views for them, rather than this all-or-nothing thing. Please see the issue summary, which is the result of the VDC teams's discussions on the topic. I laid out all these very specific details about how each listing can be treated separately, and people are just ignoring them. :)

Note that I'd personally prefer option 1) of #2.

However, there are many many things that need to be figured out to make that happen. The discussion in #1823608: Admin views in core holds some of the most important details on the problem space - while it focuses on administrative views, the actual underlying problem of non-dynamic, non-modular, declarative config repeats itself for any kind of views-based listing.

I'd think that it is doable, but of course, it will very potentially have a big impact on the release cycle/date.

In my mind, a half-baked conversion does not make any sense, because it would only leave the overall system/application in a very weird state - on top, for absolutely no good reason. That's why I only see the two directions of either 1) full viewsification, or 2) all-optional views.

In my mind, a half-baked conversion does not make any sense, because it would only leave the overall system/application in a very weird state - on top, for absolutely no good reason. That's why I only see the two directions of either 1) full viewsification, or 2) all-optional views.

There's nothing "half-baked" about providing Views by default for things that people always use Views for, and providing optional, configurable listings for things that are more critical to site functionality that users might like to customize. It's not one meal we're baking. You have an entree, and then there are several pies for dessert. You don't need to eat all the pies!

Er, sleep-deprived ramblings about pies aside. The direction I would like to take is to file an issue for each core listing once folks have had a chance to consider the problem space here, and then we decide the best course of action on a per-listing basis. Each individual listing conversion should be fully baked before it goes in. Ideally each listing should have a view. The questions we need to ask ourselves in each case are when those Views replace the existing lists, and whether the legacy code is retained as a fallback.

What do we have against converting *every* listing to a view again? Is it because of then having to have Views enabled by default and locked as required-by-core? ...and that in turn is bad because of performance or what?. Do we have a list of pros/cons of making Views a required core module? I think we should start with that because if it is not a performance hit, then IMHO we should go with view-ifing everything that can be view-ified. Views in now part of core and core should use core where possible. Less custom code and special-casing is good.

If we had views on by default and hidden away (hidden = TRUE in views.info), we could start referring to views_ui.module simply as "Views" and list only that in the modules page. So, it'd be one thing less that new users would have to learn. Core and module developers as well as other advanced Drupal users would know that there is a Views Core/Base/API (views.module) hidden underneath that they can take advantage of. Does this simplification make sense?

What do we have against converting *every* listing to a view again?

The summary to this issue proposes converting every listing to a View, and installing those Views when Views is enabled.

Is it because of then having to have Views enabled by default and locked as required-by-core? ...and that in turn is bad because of performance or what?

Not even Node is required anymore, and it took a lot of work (mostly by @sun) to get to that point. (The test suite still has thousands of dependencies on it.) That's leaving aside the code weight, the technical debt, the performance and memory issues that still need to be resolved, etc. Making Views required would be a step backward, and I don't think it should be under consideration.

The point is that we don't have to make Views required for modules to provide optional integrations with it . The point that several have raised here (and that we discussed extensively before posting this issue) is how "optional" optional integrations are, which is why we propose decoupling the old code for listings like admin/people, but not removing it.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

As stupid as it might sound, we can convert pretty much everything (except admin screens) to default views yet leaving modules with no dependencies to views.

Let's say, for example, the good old 'node' frontpage could be a default view in the node module, it doesn't require a views' module dependency in the node module, it's just a config file and some hook implementations that will remain silent if views is not enabled.

EDIT: The only limit to this is (when I say admin screens): keep the site usable without views. From my perspective, keeping the site usable is just keeping admin untouched, and keeping the 'admin/content' page, and that's pretty much it.

As stupid as it might sound, we can convert pretty much everything (except admin screens) to default views yet leaving modules with no dependencies to views.

Let's say, for example, the good old 'node' frontpage could be a default view in the node module, it doesn't require a views' module dependency in the node module, it's just a config file and some hook implementations that will remain silent if views is not enabled.

Yes! That is the point exactly. Thank you. Also the edit.

You're welcome, as much as I hate views, I can understand why you want to reduce code and use a standard API for this. So I yield in front of that, as long as I can continue to develop views-less sites :) I'm all for compromise and this one sounds good: If I don't want views, I don't enable it and my site remains usable, people that want views, they enable it and get fancy default UI, win-win.

Re #18:

Isn't that essentially what sun's option 2 was?
At least that's what I thought when I put my vote for it earlier.

I could have easily misunderstood due to tiredness :)

I would like to add that this decoupling can be done via an EntityListController @see #1740492: Implement an entity views data controller.

All the old code can be moved to this controller, and then replaced/overwritten by Views when the Views module is enabled.

The difference between #2.2 and the OP is the proposed removal of non-views listing code for "supplementary features" like the node listing page.

I.e., certain listings that exist today would be entirely removed and only be available if Views is enabled.

The argument for doing so is (or seems to be, don't want to put any words into the mouth of others) that the existing listings are very basic and are usually customized on any site that is larger than a small site/personal site. They also involve custom code.

The counter-argument is that removing those listings removes a good chunk of useful functionality and inherently makes those core modules no longer useful for most basic site use-cases. The use-cases for which they'd still work are probably in the 1-2% range; all others (>80%) would have to install Views.

In turn, that would essentially mean that there's barely a use-case that can be done without Views. Thus, if Views is needed anyway, then we can as well replace all listings with views-based listings. (Developers who don't want or don't like Views can write custom code and/or collaborate on the antiviews module in contrib; developers are not the target audience anyway, because developers can do whatever they want, by design, and developers neither use the existing default listings, nor views-based listings, because developers don't configure, developers write code.)

That's my understanding of the disagreement, and also, the train of thought that leads me to the two logical directions in #2.

I don't think there is really disagreement in here, I think there is more a misunderstandin. xjm's point is quite clear and doesn't imply anything new for most people, Views users will continue to use it as they always did, others will continue to NOT use core listings anyway and write custom instead. There are really a few listings in core (/node, /taxonomy/term/*, I don't have any other examples in my mind right now) and most people don't use them anyway.

I just want to point out that at the begining, people explicitely said that Views will be an optional piece and now we are talking about making it a required module. Seems sneaky to me.

@pounard: Well, it's fine if you disagree, but please don't say that there wouldn't be a disagreement. ;) You're listing two audiences, 1) Views users and 2) Developers, but you're dismissing audience 3) Non-Views-users and non-developers; i.e., the most basic use-cases I alluded to in #22.

(That said, tests will be affected by this change, too - i.e., we'll no longer be able to assert basic functional listing expectations without Views or custom helper code in testing modules.)

@#24 Views would remain optional with xjm's proposition and that's all I care about personnally.

I think (but not sure) there's a little misunderstanding here. No one is proposing to actually make Views required i.e. required = TRUE in views.info. What sun is speaking of (at least I think that is the case) is that from the end-user perspective views would be de-facto required in order to do anything useful. I.e. if you turn off Views module, there is no user-facing content listing, which
for a content-management system is pretty worthless for an end-user. But as a developer, that doesn't like Views for whichever reason, you just EntityQuery and entity_view_multiple your nodes and your done with it. You don't really care about not having /node by default.

@#27 Indeed, fully agree.

I just want to point out that at the begining, people explicitely said that Views will be an optional piece and now we are talking about making it a required module. Seems sneaky to me.

Who is "people"? Read the summary, please:

Views will not be a required module in Drupal 8.

The fact that people who are not working on VDC have asked in this issue if Views should be required is not a conspiracy. It's a conversation. I am the only member of the initiative team who has commented on this issue to date.

I want to use this comment to just say LOL @ #24.

Okay, now I'm not anymore. ;) But, please, I'd like feedback on the proposal that is in the summary. It's the result of conversations between the initiative team and some discussion with core committers.

Why is #2 and #22 not interpreted as concrete feedback on the proposal?

This issue proposes a possible direction, so it is the direction that is up to debate. Can we disagree with the proposed direction, or are all concerns on the proposed direction straight-out ignored? ;)

So sun's question is whether end-users should be able to have a functional site (let's say a Drupal developer personal blog of which there are many that currently don't have views installed in Drupal 7 since they just use the front page + tag listings) without running Views.

For me that use-case only matters if Views' default markup or performance is radically different from core's - i.e. that it'd be a (further) performance regression from Drupal 7 for some of those common/basic pages. Currently this is very likely the case. Views has entity render and query caching going for it which ameliorates this a bit, but really entity_view_multiple() should have entity render caching going for it and it just needs someone to work on it...

If we think this is valid, then it's a case of providing 'legacy'/minimal content listings with EntityQuery and entity_view_multiple() as well as providing default views, which is applying #3 to #1 more or less.

If we do that then we're not ripping out a lot of code, although we could do things like completely remove options like the number of items on the front page (since you can customize that via views) so it'd still allow those 'custom' listings to be stripped down slightly and we might be able to factor it all out into a generic entity_listing module that just does per-bundle and per-entity listings and that's all you get.

I don't feel too strongly either way about these.

If anything I'd be further on board with completely removing the non-views admin listings since those aren't in the critical site-visitor path in the slightest. Just having views enabled at all isn't a massive deal unless you absolutely hate it (in which case roll your own), it's only adding overhead when it's powering blocks or frequently visited pages.

@sun, my apologies; while it's of course your perogative to suggest a different direction, everyone on the issue was responding to your potentially polarizing proposals (alliteration!) instead of the OP, which already represents a compromise between sites that don't need or want Views and the 70% usecase. (And of course that 70% will go up with Views in Standard.)

For me that use-case only matters if Views' default markup or performance is radically different from core's - i.e. that it'd be a (further) performance regression from Drupal 7 for some of those common/basic pages. Currently this is very likely the case. Views has entity render and query caching going for it which ameliorates this a bit, but really entity_view_multiple() should have entity render caching going for it and it just needs someone to work on it...

I tink it's probably important for us to do benchmarking on each view we want to convert. In terms of the frontend weight, is it just the rendering that's a concern, or the simple load time for the rendered markup as well? We might have an opportunity in #1843738: [meta] Convert views module to Twig to make Views' rendered output cleaner. We could also consider switching some of the defaults so that (e.g.) you opt in for a billionty classes and divs rather than opting out.

Another thing we've discussed in a few channels is a contrib project to provide non-Views listings of stuff, potentially just the ones that are ripped out of core, or potentially more modern stuff like is suggested in #21. Edit: To clarify, I'm not interested in creating or maintaining such a project, and I'm pretty sure the other Views maintainers aren't either, but the opportunity is there. :)

My personal preference is to keep the fallbacks for things like admin/content and admin/people in core (as a separate core module or whatever), because I think that's the least disruptive choice for this release cycle. I'm less interested in the existing code for featurey stuff like the node frontpage or the recent comments block that's just essentially a hardcoded, crippled View, and I think it'd be good to let contrib innovate on modern non-Views solutions rather than keeping around crufty code that's been around since Drupal 5 or 4.5 or whichever.

Thanks for clearing up my misunderstandings.

I like the proposed idea, ie. optional views, keep important legacy listings & dump the supplementary listings.

Performance is a concern so benchmarking as per #34 would be a great idea.

It does though leave out the non-views-non-developer users, as sun mentioned before.

That group could be further split for the reason that they don't use views (I may be missing some):

  1. They don't need it.
  2. They don't know it exists, or what it provides, or how to use it.
  3. They don't want it for performance reasons.

For the first two groups, they now need views and can learn to use it. They don't have to learn to use it as there will be default views, so they just have to be able to enable a module. If there isn't a notable performance hit then there is no reason for these people to be upset about it.

For the third group, again, if there isn't a notable performance hit then there is no reason for these people to be upset about it. Unless they do care about a minor performance hit, in which case they could potentially use a contrib module that replicates the old listings (assuming one ends up existing), as per xjm in #35, or they could pay someone to develop something custom (I don't think it is crazy for people to have to pay to get a pro to do performance enhancements for their drupal sites).

I am assuming some things but I would say non-developer users who are hardcore into performance and have sites small/simple enough to not use views or any module that requires views (remembering also that they have no custom modules, or else they are a developer or don't mind paying a developer) would be a very small percentage of users.

This all assumes the performance differences with & without views are minor for the pages in question.

Very valid remark by catch: on admin screens, performance should be a lesser issue than good usability and workflow.
So the performance discussion is revolving around front-facing listings?
Or does the activation of views even impact performance when no view is rendered?

When thinking of annoying and inflexible listings, mostly admin pages come to my mind. In replacing those with views I would see the biggest win. So maybe the discussion should clearly distinguish between frontend and backend views?

Also it might be asked who would want to replace core listings with views (novice, advanced user). If it were mostly advanced users this might shed a completely different light as those could be expected to know much more what they are doing and at what cost it might come.

Also it might be asked who would want to replace core listings with views (novice, advanced user)..

That wouldn't be completely fair, since there are users that might indeed want to replace them if they only knew the gains. So you have users that do not know that the default listings can be replaced with more flexible/extensible/configurable versions, but do wish this/that feature was available in the default listing and file feature requests for it. To satisfy this user group, we'd simply need to provide some "recipes" of how to add features to their views-powered admin listings and list those to the documentation section.

I honestly can't help but dream that we actually converted the modules page to a view. Imagine the possibilities!

#538904: D8UX: Redesign Modules Page
#396478: Searchable modules page
#1848064: Allow to filter modules by arbitrary search strings on the Modules page
#857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell.
etc...

As always, I'm opposed to any half-backed conversion, and I fear that we are going in this direction again here.

Here is what I suggest:

  1. Convert all listings (administrative and front-end) to Views
  2. When it makes sense, split each module into up to three sub-modules: data-model modules (ie. the Node entity), front-end UI (ie. the Node front-page), back-end UI

And really, really, kill all those stupid legacy listings.

This would make Views being required, which is actually against the goal of this issue, which is to keep it optional. This is not half-backed, most current admin screens are not complex listings. There is only two of them for which views would make sense: content and user listings. I don't see the use of making views required only for those two.

Aside of that, separating modules in 3 sounds a good idea actually.

Its not really an half-backed solution, ListControllers would degrade nicely to a legacy listing when Views not enabled.

It is true they are stupid, they are defaults. I am not sure of the benefits killing them completely, during my Drupal learning time, I found them a very nice example of the form API, along with EFQ and session filter system. I learned from this "stupid legacy code". Replacing it with configuration (e.g. a View) will not teach developers how to use form API for instance. That was from a developer point.

From a user point of view, I will enable Views to customize these listings. The legacy code, baked in a LegacyListController, will never ever be loaded again, since this will be the new and shining ViewListController which will control these screens.

I am glad that xjm found this idea "modern" in #35, but I think he is wrong thinking this would be a complicated project: I think its easily feasible and would be a good deal, also letting developers the freedom to provide their own fancy EntityListControllers. I think this would open possibilities.

<?php
/**
* @file
* Definition of Drupal\Core\Entity\EntityListControllerInterface.
*/
namespace Drupal\Core\Entity;
/**
* Defines an interface for entity list controllers.
*/
interface EntityListControllerInterface {
}
?>

Re #40: Nope, see #27.

#42 Indeed. Nevertheless providing core without any listing is like making views required without flagging it required: today we can *use* Drupal without views, and without custom code either, doing that would make it unusable without either one of views or custom code.

Please note that we're counting 5+ administrative views as of today (dblog is missing), and that list only includes content entities, no config entities yet.

Also, as there's a good chance to be overlooked in comments here, administrative views involve a range of architectural challenges, which Views is not able to deliver currently, mainly revolving around modular extensibility vs. declarative config. We're discussing potential ways to resolve them in #1823608: Admin views in core.

I'm strongly saying that Views should be required for both the default front-end UI and the default admin UI for all core modules. I don't see any good reason in keeping stupid legacy listing code around.

Yes, they are some challenges to overcome. We should have the objective of overcoming them :)

I already know the arguments against it, but I'm not convinced. So, #45 +1 from me too.

What #45 says covers me completely as well.
+1

I'm strongly saying that good programming practices are: Loose Coupling / High Cohesion - this is universaly accepted as long term design/architecture viable solutions. Keep it in mind Damian when saying such things.

We will adding a level of hard dependency, while people worked hard to de-couple Drupal Core. That is just insanity, and I prefere having stupid code that is decoupled (at least you can override/overwrite it) than a low-cohesive blob code that is tightly coupled. :/

#48 +1

Re #48: Please read #27, you've got this totally wrong.

@#50 I think he's right, he was arguing #45. The problem here is that Damien is suggesting that Views should be required.

Aside of that, I don't consider the word "required" as the equivalent of "required = true" in the .info file. As soon as you convert the full UI using Views, even if you don't make it required as in a .info-file-required, it is required as in the word "required" anyway because there is no Drupal without UI. I think the .info "required = true" is a useless affirmation, and doesn't take into account that code itself can bring dependencies.

Well, having a standardized, flexible and customizable API for listings, both front-end and back-end and actually using it, while still having the ability to use a different API (e.g. a betterviews in contrib) sounds to me like the opposite of a

low-cohesive blob code that is tightly coupled

, but anyway, let's please stick to the actual technical/practical impacts of this.

Indeed. Just as a final note about this, the reason why I don't want Views to be the "univeral API for listing stuff" is because I still consider, even considering the huge effort the Views team did and still do for the latest month, that Views is a huge mess. A universal API is probably a good thing, but even considering this (out of views scope) there will still be people that want to write stuff by hand. The 80/20 rule still applies, with or without Views, and 20% will always need customization (of Views, or without Views). So, let's not just use it for everything yet. It's becomming better than it was, I guess, but it's still not as flexible as it claims to be IMHO.

I would add that I still agree with myself in #1, #5 has a good point, #6 speaks right, #8 does add a very good point too, #12 does bring some humour in all that, and still is true, #33 brings a really good point about performances, and finally that posts such as #45 are definitly off-topic.

To get things right:

1. Nobody here is suggesting that views.module should be required (as in required = true). Right?

2. It was suggested that views.module should be enabled by default for the standard profile, but not for the minimal. Main reason being ~70% of Drupal sites using it + all the same reasons for why it went into core. That's still valid. Right?

3. We are still debating whether we should go on and replace all current core listings with views-powered ones (this is not a final decision or anything - just a suggestion). Those against this idea are saying that this action would render the minimal profile useless. So a good compromise that was suggested was to move the old-style listings to a module of their own. This module could either be moved to contrib for D8 or left there at least till D9 (by then we will most likely have enough stats available to help us decide: #1273344: Establish heuristics for core feature evaluation). If it is kept in D8 core, we'll have that module enabled instead of views.module for the minimal profile.

4. Now we have this great chance to use the Views API to convert core listings to something that:

- has consistency and re-uses code.
- is special-casing as little as possible.
- enables users that are familiar with views (again, almost 70%) to easily customize their admin listings to their licking.
- automatically brings any future core improvement related to views.module to all these listings.
- automatically allows enhancing these listings by any contrib module that enhances/extends views.module
- many more (less important perhaps) reasons that don't come to mind right now...

...and we are not doing this is again, because??...

...Views is a huge mess... ...it's still not as flexible as it claims to be...

That may or may not be true (again respect to the Views in Core team), but it definitely is far less mess than what we have now for listings. As far as flexibility goes, I'd really like to hear arguments that support that current core listings are flexible (I haven't had a good laugh in days now).

So, to sum up:

1. views.module will not be required.
2. views.module will be enabled by default for the standard profile.
3a. core listings will be converted to views-powered ones.
3b. old-style listings will be moved to a module of their own (lets call it "listings.module")
3c. listings.module will only be enabled in the minimal installation profile so not to lose any current functionality
4. #1823608: Admin views in core!!!

Sounds like a good plan?

Most of those listing are already in their respective modules today, and work gracefully in D8, since they have been ported all along with D8 evolution. I don't see any reason to (re)move them except maybe in their respective *_ui modules (taxonomy and taxonomy_ui, node and node_ui for example).

Starting from right there, Views is indeed bringing users (and I'm saying users, not developers) flexibility, but is not mandatory since we still have those listings working nicely (and some got some very nice polishing along the way). Keeping them is OK.

Providing default views for those when people decide to enable the views module is OK too.

Moving all of them in a listing.module is not OK: it would then being dependent on all core! Which sounds really bad since enabling it would mean enabling everything (far worse than writing required = true in views.info).

I'd modify your plan as:
1. Move all admin UI in respective *_ui modules, but keeping them as they exist (minimal effort)
2. Create the default views in those respective modules (now that views is in core) and make them iso-functionnal at least
3. Enable views per default in standard profile, all others would gracefully use current listings

It's basically exactly the same as you are proposing without aggregating all listings in an aggregate module (eg. listing.module), by providing default (optional) views, Admin Views is de facto in core, no need to say it. This solution also brings one good stuff: if there is not enough time to solve all problems and port all listings to views, no big deal! Listings would still be there for those which cannot be ported.

xjm asked for my input here, the poor dear. :-) Reading through the thread, it looks like the root issue is, once again, not agreeing on what Drupal "is". Different perspectives on what Drupal "is" lead to different perspectives on this question.

The following is my perspective, which should explain my recommendation. It's 2:30 am right now, so I'm going to err on the side of blunt rather than nuanced in the hopes that results in better clarity. :-) I apologize for any rough edges.

Statement 1: The idea that "Drupal" is "useful out of the box without customization" is perhaps the single most dangerous and harmful statement we can be making. Really. Please stop it. Drupal core is not Wordpress, it hasn't been Wordpress in a long time, it's not going to be Wordpress.

Statement 2: The standard profile, however, *should* be at least moderately useful out of the box, or at least useful enough to show people how cool Drupal is. However, I have no expectation that anything more than a half-arsed blog attached to a couple of static pages will be possible with standard profile without customization.

Statement 3: Putting Views in core and then *not* replacing at least some large percentage of core's assorted listings means that the entire VDC initiative has been a waste of effort, because Views being in core offers no architectural advantage to Views. It's only useful if we actually use it in core to eliminate hard coded listings that date back to the stone age. As I really hate wasting effort, particularly as much effort as has gone into VDC so far, I don't consider "keep Views 100% optional for everyone" to be a position even worth considering.

Statement 4: If you're using Drupal for anything serious and not using Views, then to be quite frank you shouldn't be using Drupal. There, I said it. In the current market, if you're using Drupal but avoiding Views you should be using Wordpress or Symfony instead. The statistics quoted above that 1/3 of Drupal sites aren't using Views I do not consider reliable, for the simple fact that it only shows 500k Drupal sites. We know there are a few more zeros on that number of Drupal sites in the wild.

So Drupal "core" should not require Views. required = TRUE is not on the table, because *any* module that uses required = TRUE is a bug on its face; adding that to Views would therefore be introducing a new bug, vis adding a regression. No one is suggesting we do that.

What I think people mean by "you're making Views required" is "you're making Views required in order to do something useful with Drupal", not "in order to run Drupal". Newsflash: That ship sailed 4 years ago. If it weren't already the case, there would be no reason to put Views in core. :-) Drupal is a Content Management System (or perhaps Content Management Framework). A CMS needs a content assembly system in order to be useful. Views is the Drupal content assembly tool.

Making standard.profile require Views for user-facing listings harms exactly no one:

* For people who use Views, it makes it easier to customize.
* For people who try to do something useful in Drupal without Views even though they really ought to just be using Symfony directly at that point, turning off Views and writing your own node listing page is no harder than menu_alter-ing out a hard-coded listing and writing your own node listing page. It's probably slightly easier, actually.
* For people who just want something passable out of the box... they don't know what Views is, don't care, and it really doesn't matter to them either way.

As for minimal install... I have no expectation that minimal is a useful system out of the gate, and neither should you. It's by definition "just the minimal you need to actually boot Drupal". That such an install profile has any modules in it at all is a bug.

So for me, for user-facing Views (/node, /taxonomy/term/X, etc.), there is no compelling argument whatsoever to even bother with a non-Views version. The tiny percentage of people who have a legitimate reason to not use Views for those pages will be writing custom code no matter what, so it's irrelevant which default they're turning off. (And by "legitimate" I mean something other than a generic Views allergy.) I don't think the performance question is significant here. For the pages we're talking about, I would be very surprised if Views is not very close to the existing performance. And even then, anyone who's actually using the default version of those pages had better have page caching on anyway (because the only reason to not have page caching on is if you're doing something particularly esoteric, which those pages are not), and then it's a non-issue.

For admin views, I can in some cases see a valid argument for loose coupling. While I don't expect Drupal sans-Views to be useful, it should at least be minimally functional. It probably makes sense to make dblog's display out of Views, but that does have the net effect of dblog not being useful without Views even if Views is not a hard dependency. It becomes a soft-dependency for many modules. I'm personally fine with that, but I can see the architectural argument for it not being a good idea.

More to the point, as sun noted above some admin listings we have now are actually quite difficult to do with Views in its current form. To me, that is a good reason we *should* convert them to Views as it forces architectural improvements in Views to make those pages possible without fugly, but I can see where that takes resources we don't have.

So, executive summary with that background:

- User-facing listings should be Views only, with no alternate versions.
- Admin-facing listings we can address case by case, but only convert if we can do so in a non-hacky way.
- We don't cater to the minority of people who are trying to do something serious with Drupal without Views, because they're not using the tool in a supported way to begin with.
- People with a legitimate use case for custom-coding a listing have no more work to do than they do today. Nothing really changes for them at all.

... That such an install profile has any modules in it at all is a bug.

Well, now I would go that far, but I agree 100% on everything else.

Status:Active» Needs review

I'm not sure whether I'm in-line or off-the-line with the following, but:

A follow-up patch to #1848998: Problems with update_module_enable() actually committed an update for System module that enables Views module (if the front page was configured to the path 'node'). That doesn't make much sense (especially since our Update Batch API is not as robust as it should be; it doesn't support to enable new modules in between + execute their updates as well), so we're trying to figure out what to do over there.

Anyway... my recommendation is this:

  1. Don't make Views required = TRUE.
  2. But make Views required for pretty much all (entity) listings. Public and administrative.
  3. For administrative listings, figure out how to resolve the architectural challenges. @see you in #1823608: Admin views in core ;)
  4. For anything else, shoot for no less than getting rid of views.module. Instead, Drupal\Core\Views. There's very little procedural code left to begin with. The entire thing consists of plugins. If we need a /includes/views.inc, so be it. Not the end of the world.
  5. Enable Views[.module] for all sites in the upgrade path to D8.
  6. Once it's a service, then there's nothing to enable. If it's a service, haters can swap it out. In any case, Views should supply "derivative" implementations of EntityListController in the first place, so entity-type-specific and/or global swapping should be possible at that level already.

So let me put this rather provocative proposal for review and final sign-off. In case we approach this direction, we have a lot of work to do. :) But at least, we have a clear + concrete vision.

Alright, I agree with 1, 2, 3, and 5 (given that node is required in D7, and the /node path is being converted to a view, and that the 20% of sites that don't need Views after the upgrade can disable it). I think 4 and 6 are beyond the reach of this release cycle.

Edit: I additionally think we should still provide some way to render admin/user without Views enabled, for D8, with the goal of eliminating that fallback in D9 when Views is more mature and integrated with new D8 core subsystems.

If done properly, the module vs. core distinction becomes less and less relevant so I don't think sun's point 4 is really worth pursuing at this point. Otherwise, it sounds like sun is broadly agreeing with my executive summary in #56, give or take how hard we push for admin listings to use Views. That, IMO, comes down to resourcing between now and drop-dead date.

"Componentizing" Views module sounds like total yak-shaving to me, and in any case is completely off-topic to the discussion at hand.

I don't think it is less relevant or off-topic at all. I come from the use-case of #1043198: Convert view modes to ConfigEntity, where an entity type is provided by the entity system itself, i.e. in Drupal/Core. If we want to use Views as an EntityListController there, views or at least the views base, cannot be a module because that would introduce a dependency of Drupal/Core on views.module. If everything is nicely decoupled this shouldn't be so much a technical problem as a conceptual, as in theory

$ mv ./core/modules/views/lib/Drupal/views/* ./core/lib/Drupal/Core/Views/

should be more or less sufficient. So moving Views to a core component vs. a module should be the ultimate goal for D8 definitely, IMO.

If we want to use Views as an EntityListController there

That's a pretty big "if".

Feature deep freeze is in less than a month. We haven't completed any conversions yet because of upgrade path blockers. We have a whole host of problems to sort out before we can consider admin views. I'm not saying I'm not open to discussion, but I'd much rather make sure the initiative's primary goals are being met first.

Re #63: Totally agree. I just think it should be in the back of our heads that this is where we want to end up. If we don't make it for D8 in the end, we don't make it.

So does anyone *not* agree with the broad strokes outlined at the end of #56, which is largely the same as sun's list minus points 4/6?

Or, you know, the OP.

Issue summary:View changes

Updated issue summary.

Erm. The consensus we've reached diverges from the original proposed solution in the OP, to a pretty big extent...?

We're no longer talking about keeping anything legacy around, or doing any case-by-case decisions (except for admin views, but only in case we don't find a solution).

That's what #45, #56, and #58 have been talking about.

To clarify that, I've added the proposed solution to the issue summary. To decrease possible confusion, since some recent comments referred to bullet point numbers of #58, I retained the exact numbers (thus, slightly distorted numbering ;)).

If this is still the agreement, then I suggest to RTBC this + also assign it to @Dries, since this is a pretty significant product decision.

Issue summary:View changes

Clarified proposed solution.

Issue summary:View changes

Incorporated @Crell's take as another clarification.

I updated the issue summary's proposed solution #5 to clarify why. I don't know if I captured everything that was intended there, so please refine it further if needed.

Note that there is discussion in #1848998: Problems with update_module_enable() of doing the opposite of #5, and telling users to turn Views on themselves and configure their Views as they desire after they complete their upgrade. Both @berdir and @catch have suggested this.

@sun, I really don't see any substantive difference between any of the recent comments and my original post, other than that you are using the FUD trigger word "required". The OP never proposed preserving non-admin legacy listings.

Assigned:Unassigned» Dries
Status:Needs review» Reviewed & tested by the community

Well, I think that intentionally avoiding the word "required", when the actual, logical consequence of the change means that it is factually required (in order to do anything useful with core by default), would only attempt to obscure and hide an important detail and impact, which in turn means that it produces FUD, instead of preventing it.

When we agree and decide about questions like this, clarity about consequences is key. Thus, the more concise and clear we can formulate them, the better.

In any case, it sounds like we have an agreement. :) Therefore, marking RTBC and assigning to @Dries.

Issue summary:View changes

Provided reason for proposed solution #5.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

Following IRC discussion (and lots of fiddling trying to make the font smaller), I removed the aforementioned #4 and #6 from the summary, because all four VDC initiative team members and the core maintainers present unanimously agreed this should not be in the scope of D8, and that it was probably not technically possible at this point anyway. Let's focus on what there is consensus for, which is more or less what we are already doing. :)

And I'm not going to argue semantics anymore.

Assigned:Dries» Unassigned

I think we should convert existing (hardcoded) views to Views, so to speak. That should be a major task, but not a critical task, meaning I'd ship 8.x. without all views converted to Views.

When do we convert (hardcoded) views to Views, it is ok for these views to disappear when the Views module is disabled/uninstalled.

Status:Reviewed & tested by the community» Active

Moving back to active so this can just be a normal meta issue now. Or do we want to close this discussion as fixed and re-make a "clean" meta issue w/out 73 comments to track progress?

New meta issue, please. If there isn't one already... #1823450: [Meta] Convert core listings to Views

Title:[meta] Convert core listings to Views[meta] Figure out how to integrate Views into core
Status:Active» Fixed

Talked to xjm, she agreed with closing this one in favour of that one.

Re-titling and marking fixed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Closed (duplicate)

...actually.

Issue summary:View changes

Updated issue summary.