Problem/Motivation

Drupal has a lot of areas where we have added a new feature/API etc. which is capable of replacing something else, but that replacement has never happened, leading to two or more, often confusing, ways to do things, or a general level of unevenness across core where legacy and new ways to do things conflict or don't combine well. This goes across site builder features, PHP, theming, JavaScript, docs.

Opening this issue to collect some of the issues trying to address this. While the individual issues don't necessarily have much in common, at lot of them have common themes at a higher level. Also because I'm in the middle of drafting a blog post about this and need an issue to link to.

This doesn't have to be strictly about when there are two ways of doing things in core, it can also cover when finishing a core feature properly would allow it to replace a contributed modules (entity API for example).

Steps to reproduce

Proposed resolution

Remaining tasks

Issues with a ** are priorities per #3476431: [discussion] Prioritized issues for Drupal Modernization

Site building features/usability

** #111317: Allow users to login using either their username OR their e-mail address There are child issue to work on for this.
** #1537198: Add a Production/Development toggle
#2353867: [META] Expose Title and other base fields in Manage Display
#3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points
#3063877: Add access control to /filter/tips
#1823450: [Meta] Convert core listings to Views
#3372932: [Meta] High-performance images (nearly) out of the box
#2954834: Add poster image to HTML5 media videos

Done
** #3347343: Add Views EntityReference filter to support better UX for exposed filters

Admin theme

#3530852: [META] Admin theme modernisation

HTML/CSS

#2880237: [meta] Refactor system/base library
#2158943: Add a native dialog element to deprecate the jQuery UI dialog
#3404214: META: Reduce / eliminate “jank” (layout shifts) within Drupal’s admin UI
#1804614: [meta] Consolidate similar twig templates and properly use theme suggestions in core
#3458587: Deprecate preprocess variable cruft in core
#3252084: [meta] Remove support for Internet Explorer
#3426579: Update parts of Umami that are falling behind
#3254529: [PLAN] Drupal CSS Modernization Initiative

PHP APIs

#2025629: [PP-1] [meta] Ensure that all #theme/#theme_wrappers hooks provided by core are associated with a sensible, re-usable element #type
#2346347: Finalize API for creating, overriding, and altering code-defined bundle fields
#2875151: [META] Implement Batch API as a service
#1803948: [META] Adopt the symfony mailer component
#3100110: Convert update_calculate_project_update_status() into a class
#2544110: XSS attribute filtering is inconsistent and strips valid attributes
#2350509: Implement auto-route generation for all core entities and convert all of the core entities.
#2808481: Introduce generic entity template with standard preprocess and theme suggestions

Done
** #3442009: OOP hooks using attributes and event dispatcher
** #3396165: [meta] Convert all core plugin types to attribute discovery

JavaScript

#3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint
#3398525: Add an API for importmaps
#3028968: Create Javascript library for searching/filtering rendered lists on the client.
#3076171: Provide a new library to replace jQuery UI autocomplete
#2158943: Add a native dialog element to deprecate the jQuery UI dialog

Done
#3203920: Replace Contextual Links BackboneJS usage with VanillaJS equivalent

Docs and tooling

** #3463660: [policy, no patch] Document high-level API concepts in an easier format

Done
#3398293: Consolidate local development environment documentation to recommend DDEV
#3439331: [policy] Decide on format of commit message
#3486271: Change format for git commit message for the Drupal Core project.
#3543076: Simplify agreed commit format and comply with Conventional commits spec

User interface changes

API changes

Data model changes

Release notes snippet

Comments

catch created an issue. See original summary.

tstoeckler’s picture

Don't want to directly add it to the issue summary, but I immediately thought of #2350509: Implement auto-route generation for all core entities and convert all of the core entities. when reading this...

catch’s picture

Issue summary: View changes

No that's a great example! Added.

Current idea is to try to pick a handful of issues in different areas to concentrate on, and see if we can pick them off bugsmash style.

catch’s picture

Issue summary: View changes

Organised these into topic groupings.

pameeela’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
quietone’s picture

Updated IS with priorities from a discussion at Barcelona2024

quietone’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes

Rely on the issue title to explain the issue.

plach’s picture

While #3442009: OOP hooks using attributes and event dispatcher is a huge improvement (and one I'm deeply grateful for :), I think it's undeniable that having both Symfony Events and Drupal Hooks at the same time means having two competing implementations of the observer pattern. In most cases there is not a clear reason to pick one or the other, if not a matter of "taste". In an ideal world we'd have a single system covering all use cases and core would promote consistency in contrib by only using that. In an ideal world both Symfony and Drupal would use that same system :)

catch’s picture

So #11 is true but I do think OOP hooks gets us closer to a unified situation:

In most cases there is not a clear reason to pick one or the other, if not a matter of "taste".

While that's true now, people kept wanting to use events so they could have OOP implementations, and now that's not necessary. So apart from a handful of use cases like ::stopPropagation() it should be easier to default to hooks ;)

In an ideal world both Symfony and Drupal would use that same system :)

We're using event dispatcher under the hood for OOP hooks, see ModuleHandler::getHookListeners()

The [#Hook] attribute is to a large extent a bc-compatible implementation of [#AsEventListener] https://symfony.com/doc/current/event_dispatcher.html#defining-event-lis...

Hook invoking still needs to go via the module handler, but that should be a much thinner layer when we're able to remove the bc layers for procedural hooks (in Drupal 13).

So what we have in 11.1.x is mostly a thin-ish layer on top of events, which is heavily opinionated to a particular style of Symfony events and listeners (no Event class, ::getSubscribedEvents() etc. - and one that is doing a lot of bc heavy lifting for procedural hooks.

There's a lot still to do though, issues like #3481903: Support hooks (Hook attribute) in any registered service for example.

catch’s picture

Issue summary: View changes

Switching an issue.

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes

Add 'Admin theme' to the IS, #3530852: [META] Admin theme modernisation

quietone’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.