[meta] Lots of non-plugin PHP classes in plugin directories

Created on 28 November 2024, 20 days ago

Problem/Motivation

Plugin discovery requires file directory scanning, loading classes into memory, then reflection to check for attributes.

We have to load the class into memory before we can check for plugin attributes, and this memory then can't be freed again.

Core has more than 100 classes that are in plugin directories, but are not plugins, or are different plugins.

For example

Convert.php
CreateNew.php
Crop.php
Desaturate.php
GDImageToolkitOperationBase.php
Resize.php
Rotate.php
ScaleAndCrop.php
Scale.php

These are ImageToolkitOperation operation plugins, which are in core/modules/system/src/Plugin/ImageToolkit/Operation/gd

But because they're in core/modules/system/src/Plugin/ImageToolkit they get parsed in case they're ImageToolKit plugins, this loads all the classes into memory and requires FileCache to store 'null' entries (which include mtime etc. in reality) in APCu.

If we move the GD toolkit operations into a parallel instead of nested directory, then we wouldn't be parsing them twice (or at all, when we only get the toolkits and not the operations).

There are various other cases, some base classes which will be annoying but probably worthwhile to move, some helper classes in Views it looks like.

Plugin discovery has explicit logic for when it discovers non-plugins so we can add an Exception there to start building a list.

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

base system

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
  • Performance

    It affects performance. It is often combined with the Needs profiling tag.

Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024