\Drupal\Core\Plugin\DefaultLazyPluginCollection::setInstanceConfiguration() assumes that $configuration results in the same plugin instance

Created on 8 May 2024, 2 months ago
Updated 24 May 2024, about 2 months ago

Problem/Motivation

Thunder installation fails on Drupal 10.3 because it has an override of image.style.thumbnail that is not properly applied. This occurs because πŸ“Œ All core install profile image styles should include webp conversion Active has added an extra image effect. This results in the plugin collection being instantiated when the profile configuration is applied during the profile module install. This uncovers the fact that \Drupal\Core\Plugin\DefaultLazyPluginCollection::setInstanceConfiguration() assumes that the existing instance and the incoming $configuration are for the same plugin. But this is not necessarily the case. Core's configuration is:

  1cfec298-8620-4749-b100-ccb6c4500779:
    uuid: 1cfec298-8620-4749-b100-ccb6c4500779
    id: image_scale
    weight: 0
    data:
      width: 100
      height: 100
      upscale: false
  c4eb9942-2c9e-4a81-949f-6161a44b6559:
    uuid: c4eb9942-2c9e-4a81-949f-6161a44b6559
    id: image_convert
    weight: 2
    data:
      extension: webp

while Thunder's is:

  1cfec298-8620-4749-b100-ccb6c4500779:
    uuid: 1cfec298-8620-4749-b100-ccb6c4500779
    id: focal_point_scale_and_crop
    weight: 0
    data:
      width: 100
      height: 100
      crop_type: focal_point

When core only has a single effect (ie. 10.2.x) Thunder's overrides were successfully applied because the effect plugin instances are not create when you change the entity. But no there is more that one they are because we need to sort them. This result in applying the configuration to the wrong plugin type - and everything breaks.

Steps to reproduce

Try to run a thunder test on Drupal 10.3.x

Proposed resolution

The simple solution is to change \Drupal\Core\Plugin\DefaultLazyPluginCollection::setInstanceConfiguration() to unset the plugin instance prior to getting it. But that would go against the docs:

   * If there is no plugin instance yet, a new will be instantiated. Otherwise,
   * the existing instance is updated with the new configuration.

Maybe we can detect somehow that the configuration is for a different plugin type and then unset.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Fixed

Version

10.3 ✨

Component
Configuration entityΒ  β†’

Last updated 2 days ago

Created by

πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

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

Merge Requests

Comments & Activities

Production build 0.69.0 2024