Approachable tasks for Drupal 8 Beta 1

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
xjm's picture

If you couldn't make the (nearly) back-to-back sprints on beta-blocking issues at Drupal DevDays Szeged and NYC Camp, don't worry! We still have some leftover sprint tasks that will help with the first Drupal 8 beta release. Many of the 28 remaining beta blockers require deep knowledge of the problem space; however, the tasks listed here (while not necessarily quick or easy) are more approachable and self-contained. Some of these issues are beta-blocking in their own right; others are "beta target" issues that would ideally be done for a beta release even if they aren't critical enough to block it.

If you're new to core contribution or Drupal 8, check out the Core Contribution Mentoring program instead.

Sprinters at the beta sprint, wearing bunny ears.

Documenting Critical Drupal 8 APIs

#2244777: Document in WSCCI change notice or handbook all the menu changes (tasks, actions, contextual links, menu links) from 7 to 8

In order for contrib developers to make good use of our first beta release, we need good documentation of the new Drupal 8 routing and menu systems. The first step is to thoroughly document exactly how a Drupal 7 module's hook_menu() is upgraded to Drupal 8, and the exisitng change record is only partially complete. Join the discussion on this issue and help us complete this critical documentation.

#2046367: Document the internals of the router

While not explicitly beta-blocking at this point, more complete API documentation for the routing system overall will be very valuable to contributed module developers using the first beta release. Help improve the routing documentation both in the Drupal.org handbook and in the Drupal 8 codebase.

#2235363: Document how plugin definitions should declare config dependencies

This is a documentation followup for one small API change that supports the new configuration dependency system. It sits at the intersection of two new (and complicated) Drupal 8 APIs: plugin derivatives and the configuration entity system. Most of the confusing work for this issue is done, and it has resulted in a new handbook page on configuration entity dependencies. The remaining task is to add documentation of the config_dependencies key in plugin derivative definitions to the API documentation in the codebase. (See under "Calculating dependencies in plugins and their derivatives" on the handbook page.) The handbook page, which is about configuration dependencies generally, also needs further work, but that is not blocking for this issue.

Configuration system

#2140511: Configuration file name collisions silently ignored for default configuration

This critical configuration system bug isn't a hard blocker for the beta release, but it can cause significant problems. An in-progress patch on the issue needs test failures resolved, updates for the latest changes in the configuration system, and other improvements.

Entity Field API

#2016679: [Meta] Expand Entity Type interfaces to provide methods

Drupal 8 core provides numerous entity types, but the full API for each type is not easily documented or discoverable, since the entity's properties are accessed through magic getters. To improve the developer experience, each entity type interface is being expanded with relevant methods for the specific entity. (For example, NodeInterface now has methods like isPromoted(), isPublished(), getTitle(), and setTitle().) All the methods for content entity types have been added, but only 1/4 of the configuration entity type interfaces are complete. Most issues have a submitted patch, and what is most needed is architectural review of the proposed interface methods. (For example, see comment #19 on the FieldConfig issue.) If you have experience with one of the subsystems that still has an open child issue, or if you have a sound grasp on OO design generally, we could use your help to thoroughly review these patches so that the completed APIs are available for contributed module developers in a beta release.

#2190313: Add $EntityType::load() and loadMultiple() to simplify loading entities

In a similar vein of improving the entity system's developer experience by making the API more discoverable and removing exposure to internal concepts, this issue adds static methods for loading the entities of each type. The patch needs architectural review.

#2010930: [META] Apply formatters and widgets to rendered entity base fields

Entities in Drupal 7 and 8 have two kinds of field data: base fields (or properties in Drupal 7), like the node author field or the taxonomy term description, and configurable field instances, which can be attached to a given fieldable entity type's bundles through the user interface. Previously, it was not possible to use widgets or formatters for base fields, so they typically use custom form elements and rendering code that are not compatible with Drupal 8's in-place editing functionality. Since December, however, it is possible to use widgets and formatters on base fields. We now need to convert base fields other than the node title to also use widgets and formatters rather than custom code. This isn't considered beta-blocking, but it will change how contributed module developers interact with these entity types (plus make it so that in-place editing behaves in a more expected fashion). The several child issues of this meta (one per entity type) need either further work on the patch or code review. If you're somewhat familiar with entities and fields in Drupal 8, this is a good place to help.

Views conversions

#1823450: [Meta] Convert core listings to Views

One of the major benefits of having Views in core is that legacy one-off listings in core can be replaced with user-configurable views. Views is used in numerous places in core already, for example, the user and content administration screens, the promoted node frontpage and RSS feed, and numerous blocks like the "Recent content" and "Who's online" blocks. A handful of more complicated legacy core listings still need to be converted to views. These conversions don't block a beta release, but are targeted for the beta since adding them involves removing legacy API functions. In particular, it would be valuable to complete the conversions of the comment admin page and the taxonomy term pages to views for a beta release. Additionally, replacing the content revision table with a view is blocked on a major views bug related to content revisions. Finally, there's also an issue to convert the main forum listings to views.