Logo-Wasserzeichen fehlt: eigener Decorator wrappt die Logo-Medien-URL rekursiv (Folgebug zu #32) #35

New issue

Closed

opened 2026-08-09 16:53:45 +00:00 by csaeum · 0 comments

csaeum commented

2026-08-09 16:53:45 +00:00

Owner

Symptom

Nach dem v1.7.1-Fix (Logo per Medien-Picker statt Freitext-URL) zeigt der Storefront weiterhin nur den Text (label()), aber kein Wasserzeichen-Logo — obwohl das Logo im Medien-Picker korrekt ausgewählt und gespeichert ist. Live-URL zeigte nur filters:label(...), kein watermark(...).

Root Cause

ImagorUrlBuilder::resolveLogoUrl() lädt das Logo-Medium über media.repository und liest $media->getUrl(). Diese URL wird aber beim Laden durch unseren eigenen Decorator ImagorMediaUrlGenerator (dekoriert AbstractMediaUrlGenerator) geleitet — der wrappt jede Medien-URL in eine imagor-URL ({baseUrl}/unsafe/0x0/{sourceUrl}), auch die des Logos selbst, unabhängig von dessen ai_type.

resolveLogoUrl() bekommt dadurch keine rohe Original-URL zurück, sondern bereits eine imagor-URL. Die landet dann als verschachtelter Pfad im watermark()-Filter-Argument — exakt dasselbe Strukturmuster wie der ursprüngliche Issue-#32-Bug (dort mit https://-Schema, hier ohne, aber mit /unsafe/0x0/... als eingebettetem Pfad), und wird vermutlich von derselben Stelle stillschweigend verworfen.

Fix

ImagorMediaUrlGenerator::generate() muss die konfigurierte Logo-Medien-ID von der eigenen Wrapping-Logik ausnehmen, damit getUrl() für das Logo die rohe Original-URL liefert.

## Symptom Nach dem v1.7.1-Fix (Logo per Medien-Picker statt Freitext-URL) zeigt der Storefront weiterhin nur den Text (`label()`), aber kein Wasserzeichen-Logo — obwohl das Logo im Medien-Picker korrekt ausgewählt und gespeichert ist. Live-URL zeigte nur `filters:label(...)`, kein `watermark(...)`. ## Root Cause `ImagorUrlBuilder::resolveLogoUrl()` lädt das Logo-Medium über `media.repository` und liest `$media->getUrl()`. Diese URL wird aber beim Laden durch unseren eigenen Decorator `ImagorMediaUrlGenerator` (dekoriert `AbstractMediaUrlGenerator`) geleitet — der wrappt **jede** Medien-URL in eine imagor-URL (`{baseUrl}/unsafe/0x0/{sourceUrl}`), auch die des Logos selbst, unabhängig von dessen `ai_type`. `resolveLogoUrl()` bekommt dadurch keine rohe Original-URL zurück, sondern bereits eine imagor-URL. Die landet dann als verschachtelter Pfad im `watermark()`-Filter-Argument — exakt dasselbe Strukturmuster wie der ursprüngliche Issue-#32-Bug (dort mit `https://`-Schema, hier ohne, aber mit `/unsafe/0x0/...` als eingebettetem Pfad), und wird vermutlich von derselben Stelle stillschweigend verworfen. ## Fix `ImagorMediaUrlGenerator::generate()` muss die konfigurierte Logo-Medien-ID von der eigenen Wrapping-Logik ausnehmen, damit `getUrl()` für das Logo die rohe Original-URL liefert.

csaeum referenced this issue from a commit

2026-08-09 16:57:31 +00:00

fix(imagor): exclude logo media from own imagor URL wrapping (closes #35)

csaeum referenced this issue from a pull request that will close it,

2026-08-09 16:57:41 +00:00

fix(imagor): exclude logo media from own imagor URL wrapping #36

csaeum closed this issue

2026-08-09 16:58:06 +00:00