>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615080. --> Reported by: [alex ua](https://www.drupal.org/user/110386) Related to !18 >>> <h3>Problem/Motivation</h3> <p>Exported asset IDs are built from the field name and delta alone, in both export paths:</p> <ul> <li><code>ContentPackageMediaHandler::buildAssetId()</code> &mdash; media reference fields</li> <li><code>ContentPackageFieldHandler::buildAssetId()</code> &mdash; file/image fields</li> </ul> <pre>private function buildAssetId(string $fieldName, int $delta): string {<br>&nbsp; return $delta === 0 ? $fieldName : $fieldName . '_' . $delta;<br>}</pre><p>A package export shares one <code>$assets</code> array (passed by reference) across the host entity and every embedded component (<code>ContentPackageComponentHandler::exportEmbeddedComponent()</code>). When two components in the same package reference <em>different</em> files through the same field name at the same delta &mdash; e.g. two <code>promotional_item</code> paragraphs, each with a <code>field_logo</code> media reference &mdash; both resolve to the same asset ID, <code>field_logo</code>:</p> <ul> <li><code>ContentPackageAssetManager::exportFile()</code> writes <code>assets/field_logo.png</code> for the first component, then silently overwrites it for the second (the copy runs whenever the target is missing <em>or its hash differs</em>).</li> <li>The manifest entry <code>$assets['field_logo']</code> is replaced the same way, taking the second file's <code>sha256</code>/<code>alt</code>/<code>title</code>.</li> <li>Both components' exported field values reference <code>asset: field_logo</code>.</li> </ul> <p>The export completes with no warning or error. The last component processed wins; every other file that mapped to the same ID is dropped from the package, and on import every colliding component receives the surviving file.</p> <p>The resulting package is internally consistent &mdash; manifest, files, and field values all agree &mdash; so nothing downstream (validate, import, diff) can detect that a different file was intended. Import even verifies hashes (<code>importAsset()</code> throws on mismatch), which makes the silent lossy export the one unchecked leg of the pipeline.</p> <p>Field reuse across bundles is the normal Drupal pattern, so two components sharing a field name inside one exported entity is ordinary content, not an edge case. Host-entity fields can collide with component fields the same way.</p> <p><strong>Observed on a production export (2026-08-05, 1.0.2):</strong> a node holding two <code>promotional_item</code> paragraphs with different logos exported a single <code>assets/field_logo.png</code>:</p> <pre>surviving: sha256 956c36fb2e0d7b118f723170d37ea0d020a0d8ce41acf5404b8d15724666cca1 (alt "Probo.ci")<br>lost:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sha256 e09b9396c73489a2e77016a7eb3f21637b05d7dd7c591ae684da74c6930ea9db (ApplyCycle logo)</pre><p>Both paragraphs' exported values referenced <code>asset: field_logo</code>. Confirmed unchanged on the 1.1.x branch: <code>buildAssetId()</code> is identical in 1.1.0.</p> <h3>Steps to reproduce</h3> <ol> <li>Create an exportable entity containing two components of the same type (two paragraphs is the simplest case), each referencing a <em>different</em> image through the same media reference field at delta 0. Plain file/image fields reproduce it identically.</li> <li>Export the entity with <code>drush content-packages:export</code>.</li> <li>Inspect the package: <code>assets/</code> holds one file for that field name, the manifest holds one asset entry, and both components reference the same <code>asset</code> ID. One of the two source files is not in the package.</li> <li>Import into a clean site: both components render the same file.</li> </ol> <h3>Proposed resolution</h3> <p>Namespace asset IDs by owning component so they are unique package-wide &mdash; e.g. prefix with the owning component's UUID (host-entity fields can stay bare, or take the host prefix for uniformity): <code>field_logo</code> &rarr; <code>{component_uuid}-field_logo</code></p> <ul> <li><code>ContentPackageAssetManager::assertValidAssetId()</code> (<code>/^[A-Za-z0-9][A-Za-z0-9_-]*$/</code>) already accepts UUID prefixes.</li> <li>Backward compatible: <code>importAsset()</code> treats asset IDs as opaque manifest keys, so packages exported by 1.0.x/1.1.0 import unchanged; only new exports get namespaced IDs. The diff paths resolve existing assets by URI/hash before generating IDs, so diffs against existing packages keep working.</li> <li>The duplicated <code>buildAssetId()</code> implementations (media handler + field handler) must change together &mdash; worth consolidating into one helper.</li> <li>Defense in depth regardless of scheme: when registering <code>$assets[$asset_id]</code>, throw if the ID already exists with a different <code>sha256</code>. An asset ID collision should be a hard export failure, never silent.</li> </ul> <h3>Remaining tasks</h3> <ul> <li>Settle the ID scheme (component-UUID prefix vs. content-hash-derived IDs).</li> <li>MR with kernel test coverage: export an entity with two same-type components whose shared field references different files; assert both files land in <code>assets/</code> under distinct IDs with matching manifest hashes.</li> <li>Release note: re-exported packages will carry new asset IDs (package-internal; nothing to do on import).</li> </ul> <h3>User interface changes</h3> <p>None.</p> <h3>API changes</h3> <p>Newly exported packages carry component-namespaced asset IDs. IDs remain opaque strings on import; no PHP API changes.</p> <h3>Data model changes</h3> <p>None &mdash; asset IDs change value format only; the package schema is unchanged.</p>