uuid: ab0d2010-dc70-57f1-a4a8-590cc1463e7c
langcode: da
status: true
dependencies:
theme:
- claro
_core:
default_config_hash: fNwDdW063tk_ktzSWzZVeQS9wzvLooVO280BQ9WrsIs
id: claro_page_title
theme: claro
region: header
weight: -30
provider: null
plugin: page_title_block
settings:
id: page_title_block
label: Sidetitel
label_display: '0'
provider: core
visibility: { }
uuid: 72dd84d9-8f9c-4377-9256-2fb214905976
langcode: da
status: true
dependencies:
theme:
- claro
_core:
default_config_hash: fNwDdW063tk_ktzSWzZVeQS9wzvLooVO280BQ9WrsIs
id: claro_page_title
theme: claro
region: header
weight: -30
provider: null
plugin: page_title_block
settings:
id: page_title_block
label: Sidetitel
label_display: '0'
provider: core
visibility: { }
Second, config entities reference each other through dependency tracking. When a view depends on a block, or an image style references an image effect, UUID changes can cascade through those references.
Three reasons.
Third, nested plugin configurations make it worse. Image style effects, view display handlers, filter format filters — these use UUIDs as both the YAML mapping key and the identity value inside the mapping. A single image style with two effects has three UUIDs: one for the root config entity and one for each effect. All random. All different on every install.
First, the UUID is embedded in every config entity YAML file. It is always line 1. Every sync directory comparison sees it.
Multiply this by 850+ config files in a migration project and you get a diff that is functionally useless.
The result: your diff is flooded with UUID noise. The actual migration changes are buried somewhere in the middle, indistinguishable from the UUID churn around them.
Here is a real config file from a migration project. A block placement for the Claro admin theme, exported after a clean install:
Someone will ask: “Config entities are keyed by machine name, not UUID. Why does the UUID matter?”
