Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
image system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
1 Jul 2025 at 06:05 UTC
Updated:
5 Sep 2025 at 08:09 UTC
Jump to comment: Most recent
Show commands
changes
Comments
Comment #3
berdirThe problem is that this breaks BC for subclasses, of which there about 3 and I think at least the brandfolder one would be broken: http://codcontrib.hank.vps-private.net/search?text=extends%20ImageFactor...
Comment #4
smustgrave commentedSeemed to break some performance tests.
Anyway to cover with a deprecation. Like if Core version is 11.3 or great trigger a deprecation that toolkitId won't be set?
Comment #5
berdirThis is better than I expected, as it saves not just the config but also the toolkit lookup and on a cache miss discovery on a regular request and it doesn't just postpone it, it should actually move it out completely to the actual image style request.
It's "only" two fast chained apcu cache lookups, but still.
> Anyway to cover with a deprecation. Like if Core version is 11.3 or great trigger a deprecation that toolkitId won't be set?
The problem is that it we still use the property but we switch to lazy initialize. There's still the setter as well, we can't drop that completely (although having the setter at all seems somewhat problematic as the service has then state and it could change. But that's out of scope.
The only idea I have is that we could introduce a new property and deprecate the old. But that's a quite a bit of complexity. I've already created an issue in the brandfolder project: #3533323: BrandfolderImageFactory::get() broken by change in Drupal 11.3.
Comment #6
nicxvan commentedI'd create an issue in the other two add well just for visibility.
This needs significant from someone, I'm not sure who, but it seems like a low risk BC break.
Comment #7
berdirThe other two do not use $this->toolkitId as far as I see, so they don't require a change.
Comment #8
smustgrave commentedAnother dumb question if it's a breaking change should we wait for D12? Or think 11.3 is fine?
Comment #9
nicxvan commentedIt affects one project with an issue and a super easy BC compatible fix, I think we're safe to move forward.
Comment #10
smustgrave commentedIn that case lets do it! Fingers crossed
Comment #11
catchI think this is OK in a minor - if we add a change record and release note for it. The release note can point to the contrib issue.
Comment #12
berdirLike this?
Comment #13
berdirComment #14
berdirComment #15
nicxvan commentedI updated the change record title to be more descriptive of the action.
I also updated the release notes to match the expected formatting here: https://www.drupal.org/about/core/policies/maintainers/release-notes#s-f...
Comment #17
catchI double checked brandfolder and there are only ~5 sites running the Drupal 11 compatible version of the module (and it also supports Drupal 10 so they may still be on Drupal 10 too), so I think we are definitely OK with the change record and issue. The getter has been around for ages and the bc policy excludes protected properties of non-base classes (and especially the values of those properties), can't think of a less intrusive way to make the change.
Side note: this is one of the first issues where it's affecting performance tests (intentionally) and I had essentially zero involvement at all, so I actually got to see test changes without any previous context or knowledge of the issue, it's nice to see how the coverage shows the relative improvements between different scenarios, see the query diff etc. - so much easier to understand the consequences. Also don't think this would have been obvious to find via profiling, it's really the database query that makes it obvious what's saved.
Committed/pushed to 11.x, thanks!