Voting starts in March for the Drupal Association Board election.
The Views module is installed on 70% of all Drupal sites, and will be essential to the success of Drupal 8. The Views in Drupal Core Initiative has already ported Views to Drupal 8 and done significant cleanup and refactoring.
The next step is to add Views to core. Adding Views to core will have numerous advantages:
- Consistency: Many disparate, legacy solutions are currently used for data listings in core modules. Converting these listings to Views will both improve the Drupal developer experience and make it easier for site builders to customize their sites.
- Learnability: First-time users of Drupal often don't realize what is possible with contributed modules. Having Views in core will mean that new site builders can more quickly understand Drupal's capabilities out-of-the-box.
- Release cycle: The stability of Views has in the past been an indicator of when the community considers a release of Drupal "ready". Drupal 7 usage did not start to increase until a development version of Views was available for D7, and it did not pass Drupal 6 usage until Views was stable.
- Contributor experience: Hundreds of contributed modules rely on the Views API, so these modules are blocked on Views for each release.
- Stability: If Views is in core, changes that cause Views regressions will be core release blockers, and Views bugs will be treated as core bugs.
Update, Oct. 22: Views has been merged into core!
Note that this issue is not the end goal of the VDC initiative. It is only an important milestone. Since less than two months remain until feature freeze, it is important to distinguish what we must do to add Views as a core feature from what we should do to integrate and improve Views. (See the VDC roadmap for full details for what tasks are targeted in each phase of the Drupal 8 release cycle.)
Add the 8.x-3.x branch of the Views module to Drupal core. Done
views_ui.moduleoptional core modules. Done
Move Views' module-specific integrations into their respective core modules. Done (#3)
Merge the VDC sandbox into D8 core. Done
(blocked on )
(somewhat blocked by .)
(Note: This issue is not for discussion about whether Views should be added to core; see Dries' blog post on Views in core for that decision.)
- Documentation and test coverage preliminary audit.
According to Drupal core policy, core features must meet a set of minimum requirements that are defined by the Drupal core gates. We need to test Views in terms of each of these gates.
Views already includes an automated test suite, but the coverage is not complete.
Before feature freeze we will ensure that Views has basic test coverage for CRUD operations, storage, all plugins and handlers types, all default views, and basic view creation through the UI. We will also manually test Views in the VDC sandbox once the proposed resolution is complete there.
Later, we will expand the Views test coverage to more thoroughly test complex Views, all UI features, etc.
Documentation and coding standards
The API documentation was rewritten for Views 3 at DrupalCon Denver.
Before feature freeze we will ensure that there is at least minimal documentation for all hooks, plugins, and handlers. The documentation gate will be applied to all new or updated code in Views patches.
Later, we will ensure that all files, classes, functions, and methods have documentation that meets core standards, and we will apply all core coding standards (including camelCase method names) to the Views codebase.
As a contributed module, Views has not yet been thoroughly tested for its accessibility compliance.
Before feature freeze we will test the core module for each point of the core accessibility gate and identify any critical issues discovered during testing:
Later, we will plan full accessibility testing and address non-critical accessibility issues. Meta issue:
Views 8.x-3.x has the same user interface as Views 7.x-3.x, which has already undergone a usability review and been improved based on user testing. However, we know serious issues remain, especially in the more advanced full editing interface. (Few problems were found with the wizard views setup).
Before feature freeze we will provide screenshots of all parts of the Views UI and attempt to identify critical usability issues through testing.
Later, we will seek a full usability review and resolve critical usability issues.
Views includes more sophisticated caching and cache invalidation functionality than most core listings provide, so it can actually improve the performance of some listings. However, a poorly designed or optimized View can cause severe performance issues. Our goals are to ensure that core's default listings are performant, and to provide guidance for the creation of custom Views.
Before feature freeze we will do full performance testing on our first core View implementation (the main
/nodelisting) and compare its performance with the current node listing to ensure there are not severe regressions. Issue:
Later, we will evaluate the frontend performance of the administrative UI, test the performance of each new core view listing as it's added, and explore ways to inform the user when a view is badly optimized.
User interface changes
- Add screenshots of each part of the Views UI. (See ).
views_ui.modulewill be added as optional core modules.
- The standard profile will include both these modules.
The following issues and tasks should be addressed after feature freeze.
Before code freeze (Apr. 1 2013)
- Clean up the base test class.
- Convert method names to core standards.
- Convert remaining core listings to Views.
- Finish converting the query plugin to load entities after queries are executed.
- Use core API and UI for modal dialogs if/when it is available. ( , ).
- Explore further integrations with other new core features (e.g., the Field and Entity APIs, Blocks and Layouts, other core query builders, etc.), potentially including:
- Ensure Views properly implements core multilingual functionality. (Dependent on the Multilingual Initiative.)
- Integrate Views' display architecture with new Drupal 8 blocks and layouts functionality. (Dependent on the Blocks and Layouts Initiative.)
- Test the deployment workflow for Views using the configuration system. (Dependent on the Configuration Management Initiative.)
- Additional cleanup and refactoring.
Before the first Drupal 8 release candidate
- Provide complete upgrade path from Views 7.x-3.x to core Views.
- Provide full functional and unit test coverage.
- Provide full API documentation.
- Move the old advanced help documentation onto Drupal.org and update it for the new architecture.
- Resolve any non-critical accessibility issues.
- Consider mobile-friendly administration for Views (evaluate both the configurable listing controller UI and the main Views administrative UI). (Dependent on the Mobile initiative.)
- Identify and address any performance concerns.
- Explore ways to provide user feedback on specific views that are not well-optimized.
|#51||Screen Shot 2012-10-22 at 2.28.24 PM.png||152.3 KB||tim.plunkett|
PASSED: [[SimpleTest]]: [MySQL] 46,004 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 46,153 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 45,427 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 45,594 pass(es). View