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.
Depends on what we decide.
Decide if we need to change this.
Urls like admin/config/media/image-styles/manage/large/effects/ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d will change
Probably
Active
9.5
It affects the ability to upgrade Drupal sites to a new major version. Preferred over version-specific tags such as D7 upgrade path.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
One 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
using a numeric index in the URL
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.