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 #3406267: All core shipped image styles should include webp conversion 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
Issue fork drupal-3445950
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
alexpottI've filed this issue against 10.3.x because it occurs due to the 10.2 to 10.3 upgrade but it is also present in 11.x
Comment #4
alexpottComment #5
tim.plunkettI'm not able to run the tests-only job for some reason. But when I do locally, I get
Which sounds like a Prophecy mixup, not an actual working assertion.
@alexpott am I overthinking it? The change looks good
Comment #6
catchI think there are permissions issues on the test only job when the MR was opened by a core committer.
Comment #7
alexpott@tim.plunkett thanks for the review - it's the expected failure because we're doing:
So these are Prophecy classes that implement the respective interface.
Comment #8
tim.plunkett@catch that would explain it!
@alexpott I would have thought the `->reveal()` calls would have helped, but fair enough
Comment #9
longwaveComment nit, otherwise LGTM.
Comment #10
alexpottNice catch @longeave given it was just a nit back to rtbc.
Comment #11
longwaveThis is eligible for backport to 10.2.x under the bugfix policy but given it has only arisen in 10.3.x not sure it's worth it. Feel free to reopen for backport if this is incorrect.
Committed and pushed 926d069c2c to 11.x and 55463c9ef0 to 11.0.x and b7c0549a3c to 10.4.x and ef095f9bd2 to 10.3.x. Thanks!
Comment #16
longwave