Fixed
Project:
Drupal core
Version:
11.x-dev
Component:
image system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Jan 2026 at 04:32 UTC
Updated:
8 Apr 2026 at 11:16 UTC
Jump to comment: Most recent
Image.module has two remaining functions and a constant.
Let's deprecate them so we can remove the file in 13.x
Open file
Create service for image_path_flush and image_style_options
Add TOKEN constant to class. This cannot be an enum since it is used in an array.
Review
N/A
N/A
New ImageDerivativeUtilities service
N/A
N/A
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
nicxvan commentedComment #4
nicxvan commentedComment #5
nicxvan commentedI think this is ready.
I went back and forth on whether it should be one service or several, but it's pretty small.
I can update the name if someone comes up with a better one.
I think plugin constructors don't need anything special for BC: https://www.drupal.org/about/core/policies/core-change-policies/bc-polic...
Comment #6
nicxvan commentedComment #7
nicxvan commentedComment #8
dcam commentedI think
IMAGE_DERIVATIVE_TOKENmight be better moved tocore/modules/image/src/Entity/ImageStyle.php. I consideredImageStyleDownloadController. ButImageStyleis where the token is used to build style URLs. That seems like the most appropriate place to me.I'm still analyzing what you said in #5.
Comment #9
nicxvan commentedIt feels wrong in either place for the constant, since both are pretty heavy classes.
If someone else wanted to use that constant I don't think we would want to require them to include ImageStyle or ImageStyleDownloadController?
Comment #10
nicxvan commentedComment #11
dcam commentedSetting to Needs Work for a rebase.
That's fair. The only other suggestion I might have would be a single-case backed enum like the one proposed for the
_noneoption. But I really don't care that much. Part of me just feels weird including the constant in a service class that doesn't use it. But there's no way I'm dying on this hill. It isn't worth arguing over. I guess you could say I'm just brainstorming.For the record, the backed enum idea has no precedent in core. I searched for other uses of
query->get\(. Nearly all query parameter names inget()are written out there. There's one parameter name stored in a constant,MainContentViewSubscriber::WRAPPER_FORMAT. That isn't to say we couldn't do it. It just means no one else ever has. And there are also no single-case enums in core right now. I checked for that too. I don't know how much support that idea would get. And you'd have to get the case's value everywhere, unlike with a constant. So I admit it isn't necessarily a good idea.Anyway, if you want to leave it as-is, then say so and I'll RTBC it after the rebase.
Comment #12
nicxvan commentedHonestly I don't feel super strongly about this myself, now that I think about it, we can put it on the ImageStyleInterface, that is already included in the controller.
A single case enum felt wrong too, I think I'll move it to the interface and see how that looks after rebasing.
Comment #13
nicxvan commentedHow does this look?
Comment #14
dcam commentedYeah, I like it. I never think about adding constants to interfaces. Let's go with this.
I found a typo on my final review. Also, the constant wasn't removed from the service. Then we'll be finished with it.
Comment #15
nicxvan commentedI applied both suggestions thank you!
I also created this follow up #3575042: [pp-1] Fix antipattern of injecting image_style storage directly
Comment #16
nicxvan commentedComment #17
dcam commentedLooks good to me. Thank you for considering my feedback.
Comment #19
claudiu.cristeaStraight reroll ^
Comment #20
godotislateSome comments on the MR.
Comment #21
godotislateAlmost forgot to mention that the CR could use a little editing for grammar in the last two lines.
Comment #22
nicxvan commentedI edited the CR and resolved all comments except for one that I'd like to do in a follow up. I'll create that once you confirm.
I'll keep an eye on tests.
Comment #23
nicxvan commentedAh I missed @godotislate's response on the mr ticket is here #3580702: [pp-1] update dependency injection for image widget
This is ready again.
Comment #24
dcam commentedI read through the recent comments since my last review, both here and in the MR. All feedback has been addressed. I did an additional code review of the changes and didn't find anything else to comment on. The change record was updated, but my personal preference is to show calling the service when introducing one, so I updated the code examples to show that. I hope you don't mind.
Comment #27
amateescu commentedFound a few minor points that I fixed myself with code suggestions, otherwise this looks great.
Committed 54c6c2e and pushed to main. Thanks!
Needs a 11.x backport MR though...
Comment #29
claudiu.cristeaCreated a new MR. Let's see the bot
Comment #31
claudiu.cristeaComment #32
claudiu.cristeaMoved the removal to 13.0.0 also for the functions
Comment #33
amateescu commentedEverything looks great now, let's wait for the pipelines to finish :)
Comment #36
amateescu commentedCommitted c6a71ff and pushed the followup MR to main, and 28426e3 to 11.x. Thanks!
Comment #41
claudiu.cristeaPublished the CR https://www.drupal.org/node/3567619