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
Comments
Comment #2
tstoecklerDon'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...
Comment #3
catchNo 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.
Comment #4
catchOrganised these into topic groupings.
Comment #5
pameeela commentedComment #6
catchComment #7
catchComment #8
quietone commentedUpdated IS with priorities from a discussion at Barcelona2024
Comment #9
quietone commentedComment #10
quietone commentedRely on the issue title to explain the issue.
Comment #11
plachWhile #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 :)
Comment #12
catchSo #11 is true but I do think OOP hooks gets us closer to a unified situation:
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 ;)
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.
Comment #13
catchSwitching an issue.
Comment #14
catchComment #15
catchComment #16
catchComment #17
quietone commentedAdd 'Admin theme' to the IS, #3530852: [META] Admin theme modernisation
Comment #18
quietone commentedComment #19
quietone commented