Remove non-formatter plugins out of the file field formatter directory

Created on 27 January 2025, 3 months ago

Problem/Motivation

See 📌 [meta] Lots of non-plugin PHP classes in plugin directories Active for background.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

file.module

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @catch
  • 🇬🇧United Kingdom catch

    MR is green, but we need to figure out what the bc layer looks like here.

    Either:

    1. Leave subclasses of the moved classes, issue a deprecation in the constructor(?)

    2. class_alias somewhere.

    I also wondered if we could create an extra classloader that handles deprecating a class, taking a list of classes and replacements from the container, and having DrupalKernel add it somewhere.

    The classloader could decorate the composer classloader, when it's passed a deprecated class, it compares against the array of deprecated classes, if it's in there, triggers a deprecation message and then passes the replacement classname to the composer classloader, otherwise just fall through.

    This would be nearly as light as a class_alias when we want to move a class, but would allow us to eventually remove items from the list in major releases instead of keeping class_alias around permanently.

    For this issue of plugin discovery, it would also mean we can immediately stop scanning these classes during discovery.

Production build 0.71.5 2024