KI-Bildkennzeichnung 6/6: Shop-Infra — c2patool im Worker + remote_thumbnails aktivieren (separates Repo: Docker-Stacks/projekt-sw6) #9

New issue

Open

opened 2026-08-02 06:52:51 +00:00 by csaeum · 1 comment

csaeum commented

2026-08-02 06:52:51 +00:00

Owner

Teil 6 von 6 der Serie "KI-Bildkennzeichnung" (Art. 50 Abs. 4 KI-VO). Betrifft ein anderes Repo — dieses Issue dient hier nur der Nachvollziehbarkeit der Gesamt-Serie; die eigentliche Umsetzung/das PR gehört in Docker-Stacks/projekt-sw6.

Teil A: c2patool im Worker-Container (für #5)

Der worker-Service in projekt-sw6/docker-compose.yml nutzt aktuell ghcr.io/shopware/docker-base:8.4-fpm ohne den Custom-Build-Schritt (den hat nur der app-Service). Für den asynchronen C2PA-Scan (#5) muss c2patool im Worker-Container verfügbar sein → worker braucht einen eigenen build:-Block analog zu app, der das Binary installiert.

Teil B: Remote Thumbnails aktivieren (für #6, #7)

shopware.media.remote_thumbnails.enable: true (+ pattern) ist eine Projekt-Ebene-Config (config/packages/shopware.yaml im Shop-Root), keine SystemConfigService-Einstellung — das Plugin kann/soll das nicht selbst aktivieren, da es global die lokale Thumbnail-Generierung für alle Medien abschaltet, nicht nur für KI-markierte.

shopware:
  media:
    remote_thumbnails:
      enable: true
      pattern: '{mediaUrl}/{mediaPath}?width={width}&ts={mediaUpdatedAt}'
      fallback_sizes:
        - { width: 320, height: 320 }
        - { width: 640, height: 640 }

Akzeptanzkriterien

c2patool --version funktioniert im laufenden Worker-Container
shopware.media.remote_thumbnails.enable = true in Produktion gesetzt, lokale Thumbnail-Generierung bestätigt deaktiviert
Nach Deploy: Storefront-Bilder laufen sichtbar über die imagor-Domain (#5)

Teil 6 von 6 der Serie "KI-Bildkennzeichnung" (Art. 50 Abs. 4 KI-VO). **Betrifft ein anderes Repo** — dieses Issue dient hier nur der Nachvollziehbarkeit der Gesamt-Serie; die eigentliche Umsetzung/das PR gehört in `Docker-Stacks/projekt-sw6`. ## Teil A: c2patool im Worker-Container (für #5) Der `worker`-Service in `projekt-sw6/docker-compose.yml` nutzt aktuell `ghcr.io/shopware/docker-base:8.4-fpm` **ohne** den Custom-Build-Schritt (den hat nur der `app`-Service). Für den asynchronen C2PA-Scan (#5) muss `c2patool` im Worker-Container verfügbar sein → `worker` braucht einen eigenen `build:`-Block analog zu `app`, der das Binary installiert. ## Teil B: Remote Thumbnails aktivieren (für #6, #7) `shopware.media.remote_thumbnails.enable: true` (+ `pattern`) ist eine **Projekt-Ebene**-Config (`config/packages/shopware.yaml` im Shop-Root), keine `SystemConfigService`-Einstellung — das Plugin kann/soll das nicht selbst aktivieren, da es *global* die lokale Thumbnail-Generierung für **alle** Medien abschaltet, nicht nur für KI-markierte. ```yaml shopware: media: remote_thumbnails: enable: true pattern: '{mediaUrl}/{mediaPath}?width={width}&ts={mediaUpdatedAt}' fallback_sizes: - { width: 320, height: 320 } - { width: 640, height: 640 } ``` ## Akzeptanzkriterien - [ ] `c2patool --version` funktioniert im laufenden Worker-Container - [ ] `shopware.media.remote_thumbnails.enable = true` in Produktion gesetzt, lokale Thumbnail-Generierung bestätigt deaktiviert - [ ] Nach Deploy: Storefront-Bilder laufen sichtbar über die imagor-Domain (#5)

csaeum referenced this issue from a commit

2026-08-02 07:54:43 +00:00

feat(media): add async C2PA upload scan for AI image labeling (#5)

csaeum referenced this issue

2026-08-02 07:55:04 +00:00

feat(media): AI image labeling for Art. 50(4) AI Act compliance #10

csaeum commented

2026-08-02 10:04:11 +00:00

Author

Owner

Recherche abgeschlossen — auf Wunsch wird Docker-Stacks/projekt-sw6 hier nicht direkt geändert. Vorgehen zum manuellen Nachziehen:

Teil A — c2patool im `worker`-Container

worker nutzt aktuell ghcr.io/shopware/docker-base:8.4-fpm ohne eigenen Build (nur app hat einen build:-Block). Braucht analog dazu einen eigenen Build-Schritt.

Basis-Image ist Alpine (bestätigt durch apk add in apps Dockerfile). c2patool (contentauth/c2pa-rs, aktuell Tag c2patool-v0.27.3) gibt es nur als glibc-Build (c2patool-v0.27.3-x86_64-unknown-linux-gnu.tar.gz, verifiziert per GitHub-API + Tarball-Inhalt — Binary liegt unter c2patool/c2patool im Archiv). Alpine braucht dafür zusätzlich gcompat (glibc-Kompatibilitätsschicht), sonst startet das Binary nicht.

Vorschlag für den worker-Dockerfile-Snippet:

FROM ghcr.io/shopware/docker-base:8.4-fpm
USER root
RUN apk add --no-cache curl gcompat && \
    curl -fsSL -o /tmp/c2patool.tar.gz \
      "https://github.com/contentauth/c2pa-rs/releases/download/c2patool-v0.27.3/c2patool-v0.27.3-x86_64-unknown-linux-gnu.tar.gz" && \
    tar -xzf /tmp/c2patool.tar.gz -C /tmp && \
    install -m 0755 /tmp/c2patool/c2patool /usr/local/bin/c2patool && \
    rm -rf /tmp/c2patool*
USER www-data

Vor Übernahme die Versionsnummer gegen die aktuell neueste c2patool-v*-Release prüfen (contentauth/c2pa-rs Releases) — nicht blind 0.27.3 übernehmen, falls seitdem Zeit vergangen ist.

Teil B — `remote_thumbnails` aktivieren (mit Sicherheits-Hinweis)

Fund: configs/shopware/z-shopware.yaml in projekt-sw6 ist laut dessen eigener README (Abschnitt 3) kein live gemounteter Container-Mount, sondern eine Referenzkopie, die manuell in den laufenden Shop-Code unter volumes/html/config/packages/z-shopware.yaml deployed werden muss. Jede Änderung braucht also sowieso einen manuellen Deploy-Schritt.

Ergänzung unter dem bereits vorhandenen shopware.media:-Block:

shopware:
  media:
    enable_url_upload_feature: true
    enable_url_validation: true
    remote_thumbnails:
      enable: false   # ACHTUNG: erst auf true, wenn imagor läuft — siehe unten
      pattern: '{mediaUrl}/{mediaPath}?width={width}&ts={mediaUpdatedAt}'

Kritisch: enable: false lassen, bis der docker-imagor-media-Stack (#8, bereits umgesetzt) tatsächlich deployed, per Traefik erreichbar UND imagorBaseUrl im Plugin (WSC_SWPlugin_AiSeoTools) auf die echte imagor-Domain gesetzt ist. Wird enable: true vorher gesetzt, schaltet Shopware sofort die lokale Thumbnail-Generierung für alle Medien ab — ohne funktionierendes imagor-Backend gehen dann Produktbilder im Storefront kaputt.

Nach dem Deploy der Datei: bin/console cache:clear.

Recherche abgeschlossen — auf Wunsch wird `Docker-Stacks/projekt-sw6` hier **nicht** direkt geändert. Vorgehen zum manuellen Nachziehen: ## Teil A — c2patool im `worker`-Container `worker` nutzt aktuell `ghcr.io/shopware/docker-base:8.4-fpm` ohne eigenen Build (nur `app` hat einen `build:`-Block). Braucht analog dazu einen eigenen Build-Schritt. Basis-Image ist **Alpine** (bestätigt durch `apk add` in `app`s Dockerfile). `c2patool` (`contentauth/c2pa-rs`, aktuell Tag `c2patool-v0.27.3`) gibt es nur als **glibc**-Build (`c2patool-v0.27.3-x86_64-unknown-linux-gnu.tar.gz`, verifiziert per GitHub-API + Tarball-Inhalt — Binary liegt unter `c2patool/c2patool` im Archiv). Alpine braucht dafür zusätzlich `gcompat` (glibc-Kompatibilitätsschicht), sonst startet das Binary nicht. Vorschlag für den `worker`-Dockerfile-Snippet: ```dockerfile FROM ghcr.io/shopware/docker-base:8.4-fpm USER root RUN apk add --no-cache curl gcompat && \ curl -fsSL -o /tmp/c2patool.tar.gz \ "https://github.com/contentauth/c2pa-rs/releases/download/c2patool-v0.27.3/c2patool-v0.27.3-x86_64-unknown-linux-gnu.tar.gz" && \ tar -xzf /tmp/c2patool.tar.gz -C /tmp && \ install -m 0755 /tmp/c2patool/c2patool /usr/local/bin/c2patool && \ rm -rf /tmp/c2patool* USER www-data ``` Vor Übernahme die Versionsnummer gegen die aktuell neueste `c2patool-v*`-Release prüfen (contentauth/c2pa-rs Releases) — nicht blind `0.27.3` übernehmen, falls seitdem Zeit vergangen ist. ## Teil B — `remote_thumbnails` aktivieren (mit Sicherheits-Hinweis) Fund: `configs/shopware/z-shopware.yaml` in `projekt-sw6` ist laut dessen eigener README (Abschnitt 3) **kein** live gemounteter Container-Mount, sondern eine Referenzkopie, die manuell in den laufenden Shop-Code unter `volumes/html/config/packages/z-shopware.yaml` deployed werden muss. Jede Änderung braucht also sowieso einen manuellen Deploy-Schritt. Ergänzung unter dem bereits vorhandenen `shopware.media:`-Block: ```yaml shopware: media: enable_url_upload_feature: true enable_url_validation: true remote_thumbnails: enable: false # ACHTUNG: erst auf true, wenn imagor läuft — siehe unten pattern: '{mediaUrl}/{mediaPath}?width={width}&ts={mediaUpdatedAt}' ``` **Kritisch:** `enable: false` lassen, bis der `docker-imagor-media`-Stack (#8, bereits umgesetzt) tatsächlich deployed, per Traefik erreichbar UND `imagorBaseUrl` im Plugin (`WSC_SWPlugin_AiSeoTools`) auf die echte imagor-Domain gesetzt ist. Wird `enable: true` vorher gesetzt, schaltet Shopware sofort die lokale Thumbnail-Generierung für **alle** Medien ab — ohne funktionierendes imagor-Backend gehen dann Produktbilder im Storefront kaputt. Nach dem Deploy der Datei: `bin/console cache:clear`.

csaeum referenced this issue

2026-08-02 18:58:02 +00:00

docs: update STATUS.md - imagor stack complete, live test planned #13

csaeum referenced this issue from a commit

2026-08-03 16:40:32 +00:00

docs(status): document imagor Issue #9 local rollout and 403 root cause

csaeum referenced this issue

2026-08-03 16:40:53 +00:00

docs(status): imagor Issue #9 local rollout and 403 root cause #14

csaeum referenced this issue from a commit

2026-08-03 16:46:20 +00:00

Merge pull request 'docs(status): imagor Issue #9 local rollout and 403 root cause' (#14) from docs/status-2026-08-03-imagor-issue-9 into main