Voting starts in March for the Drupal Association Board election.
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.
Don't make Views
required = TRUE.
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.
For administrative listings, figure out how to resolve the architectural challenges. @see you in;)
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.
- 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.
- 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.
- For listings that are required for basic site administration (like
- 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).
- 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.