Active
Project:
Drupal core
Version:
main
Component:
image system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Apr 2014 at 14:35 UTC
Updated:
7 Jan 2024 at 05:23 UTC
Jump to comment: Most recent
Problem/Motivation
In #2110615: Do not ship with default UUIDs we removed default configuration entity UUIDs remove all default configuration provided by core (modules, themes and profiles). However, UUIDs are still present in image style configuration as effect IDs. For example, image.style.large.yml contents are:
name: large
label: 'Large (480x480)'
effects:
ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d:
id: image_scale
data:
width: 480
height: 480
upscale: true
weight: 0
uuid: ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d
langcode: en
In some ways this is not a problem because the use of the UUID is totally internal to the image style. It just exists so that there can be multiple effects of the same type - ie. you can added another image_scale transformation to this style. However this shows us that we really have a naming problem here where id: image_scale is not really an identifier but it is an effect type. And we're are just using UUID as a convenient way of generating a unique ID.
Proposed resolution
Depends on what we decide.
Remaining tasks
Decide if we need to change this.
User interface changes
Urls like admin/config/media/image-styles/manage/large/effects/ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d will change
API changes
Probably
Comments
Comment #1
alexpottComment #2
xjmComment #3
jessebeach commentedChange the
idkey toeffect.Comment #4
yched commentedDoes this unique identifier have any purpose besides being able to generate unambiguous admin URIs for "the admin config form for the Nth 'scale' effect of the 'large' style" ?
Coz it seems we could simply use effect ordering and numeric indexes here ?
admin/config/media/image-styles/manage/large/effects/[N] ?
Comment #5
mtiftChanging
idtoeffectmakes sense to me. It also seems likeuuidshould have another name.Comment #6
tim.plunkettIt's called 'id' because it's the plugin ID:
We can change it to effect, the DefaultPluginBag::$pluginKey controls that.
However, unless we add a machine name field to the image effect form (not ideal), I think we're stuck with a UUID.
Comment #7
xjmComment #8
catchI think it's more this?
Comment #9
xjmWell, technically it would be a data model change for image styles. (Earlier in the spring we were making config key changes like these beta blockers, even. This isn't critical, though.) It is a small upgrade path, though.
Comment #10
jhedstromHas a path here been decided on? I'd be happy to help implement.
Comment #11
xjmThis issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.
Comment #14
steven jones commentedI'm copying core's architecture of image styles and effects for a module I'm porting to D8, so have an interest in this.
I'm not sure how much we can/could change things in the Drupal 8 dev cycle but a way forward would be to just mirror what views does:
From a quick glance at the code, it looks like the UUID is used in the URL, but not outside the context of an ImageStyle, so it only needs to be unique within each style.
I'm guessing that the only people who really care about the internal structure of the config changing would be people who are handling and managing uuids, config_devel, config_update types, and they might welcome the change of removing things that aren't really UUIDs from config.
I appreciate that in reality that this change is almost entirely cosmetic however.
Comment #15
dpagini commentedSorry if I'm missing this point in the discussion, but what's the downside of using a YML array and then using a numeric index in the URL?
Comment #19
mlncn commentedI'm one of those configuration-messers-with who would welcome the change of removing things that aren't really UUIDs from configuration!
I like the idea of going to the Views display style of naming, so the 99% of use case where there's not more than one image effect per type gets paths like
admin/config/media/image-styles/manage/large/effects/image_scaleExcept there'd be no ability to edit the effect ID, it would just become image_scale_1 when there's a second one, without renumbering if some get deleted later— it'd be a permanent ID.
Right now the image effect ID/UUID change when exporting identical configuration from identical-in-all-but-site-UUID sites, and that's an annoying inconvenience for some of the goals of #2957423: Proposal: Configuration Management 2.0 initiative
Comment #26
quietone commentedUpdating tag
Comment #28
donquixote commentedOne problem caused by this uuid:
When migrating from Drupal 7, with `d7_image_styles` migration (actually `upgrade_d7_image_styles` with migrate_plus).
Every time I re-run the migration, the image effect uuids are updated, causing noise in git.
@dpagini #15
This seems reasonable to me.
Perhaps there is a reason for the uuids, but I don't see it.
The way I see it, the individual effects don't really need an identifier.