Let’s Make Drupal Core Less Complicated

Let’s not kid ourselves, Drupal core is complicated! Some of the complexity is to be expected in a system that is as flexible, powerful, and extendable as Drupal. But of course this complexity has many costs.

The Drupal core issue queue can easily become backlogged because many patches involve various parts of Drupal in combination limiting even the number of Drupal core committers that can review certain issues. For example an issue for Layout Builder may involve the interaction of Layout Builder override revisions with Content Translation, Configuration Translation, and Content Moderation.

This session will review ideas for reducing complexity in Drupal core such as:

• Removing the ability to have remote backends besides drupal.org in the Update and Local modules

• Deprecating the REST module and removing it in Drupal 10 now that JSON API is in Drupal core

• Determining which core modules have limited usage, such as Forum and Book, and removing them from core

• Removing the ability for Entity storage to have different storage backends

• Strictly enforcing Drupal core’s current API policy so that @internal classes are free to change at any time

• Adding more exceptions for backward compatibility breaks in experimental modules so that they don’t have to keep legacy code

• Using Final and Private in more classes to avoid having to support non-core modules extending core classes

Of course many of these ideas might be controversial and there will be some sites that are using the flexibility to be removed. How can we evaluate which of these ideas and others are worth implementing even if they take away flexibility from a small number of sites? Come to this session to start the discussion so that we can avoid adding unneeded complexity in Drupal 9 and look at ways of removing complexity in Drupal 10.