Problem/Motivation
During the 8.8.x development cycle, we deprecated numerous dependencies, libraries, and modules that needed to be removed from Drupal 9. We ran out of time for many things, so we should start this process sooner for Drupal 10.
The below issues cover work in various stages - in some cases we decided to stop using a library over a year ago but still need to decouple from it in practice. In other cases we have open issues to remove/deprecate core functionality but decisions on whether to do so have not been taken yet. In all cases, it would be best to resolve those issues as early as possible in the cycle rather than at the last minute.
Proposed resolution
Begin essential dependency, library, module, and theme deprecations by 9.2.0-beta1 (and sooner in some cases).
Deprecation infrastructure
- Add a (clean) mechanism for deprecating a module (instead of the
hidden: TRUE, warning message, "deprecate everything" mechanism we're currently using). #3135100: [policy and meta] Provide a proper mechanism for deprecating modules - Add a mechanism for deprecating a theme.
- Add a mechanism for deprecating a plugin. #3039240: Create a way to declare a plugin as deprecated
JavaScript Dependencies
- #3052002: [meta] Replace JQuery with vanilla Javascript in core (The more of this we do, the less we have to make compatible with jQuery 4.)
- #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10
- Others TBD based on dependency changes in the next 12-18 months.
PHP dependencies
- Event dispatcher: #2237831: Allow module services to specify hooks
- Symfony container:
- #3054535: Discuss whether to decouple from Symfony Validator
- #3039047: Adopt php-http/guzzle6-adapter 2.x to get PSR-18 support without losing Guzzle's async support
- Other Laminas component issues TBD
Libraries
- #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
- Others TBD based on dependency deprecations, etc.
Modules
Ensure that already-deprecated stub modules cannot be installed for new sites and removed from the codebase in Drupal 10
- None at this time
Deprecate outdated or superceded modules in preparation for removal from Drupal 10
- Field Layout, Block UI (could be deprecated in favor of LB features like Layout Builder Everywhere, etc.)
- Field Layout: #3007167: [META] Remove Field Layout module from core Note: This requires moving some functionality into core, not a straight deprecation.
- Aggregator: #3188549: [PP-1] Deprecate both Aggregator and our dependency on Laminas Feed for removal in Drupal 10
- HAL: #3049856: [policy] Mark HAL module as deprecated in D9 so it can be removed in D10
- Forum: #1898812: [policy] Deprecate forum module for removal in Drupal 10
Policy still under discussion
- RDF: #2152459: [Policy] Deprecate RDF module in favor of Schema.org-focused JSON embedded in the page
- Others? (There are various existing proposals to move other modules out of core, most of which were determined to be too disruptive or too late in the 8.8.x development cycle.)
Themes
- Stable (deprecated in favor of stable9/stable10).
- Stable 9? (TBD. How can we provide a continuous upgrade path for stableN? Is policy sufficient?)
- Classy (deprecate in favor of the Starterkit, if it is stable in time for 9.3.0-beta1)
- Seven (deprecate in favor of Claro)
- Bartik (deprecate in favor of Olivero)
Remaining tasks
- Add additional issues as appropriate.
- Evaluate in early 2021, again after 9.2.0-beta1, and again prior to 9.3.0-alpha1.