Kompatibilität
Diese Seite unterscheidet zwischen Anforderungen, im Code ausdrücklich berücksichtigter Integration und Bereichen, für die im Projekt keine belastbare Testaussage vorliegt.
Systemanforderungen
Section titled “Systemanforderungen”| Bereich | Status | Belegbares Verhalten |
|---|---|---|
| WordPress 6.5+ | erforderlich | Plugin-Header und Produktions-Check verlangen mindestens 6.5. |
| PHP 8.1+ | erforderlich | Plugin-Header, Composer und Produktions-Check verlangen mindestens 8.1. |
WP_HTML_Tag_Processor |
erforderlich für sichere Frontend-Umschreibung | Wird im Produktions-Check geprüft. |
| WordPress Upload-Verzeichnis | erforderlich beschreibbar | Wird im Produktions-Check geprüft. |
| Imagick | technisch berücksichtigt | Wird über reale WordPress-Image-Editor-Schreibtests geprüft. |
| GD | technisch berücksichtigt | Wird über reale WordPress-Image-Editor-Schreibtests geprüft. |
| Remote-Encoder | optional | Nur bei expliziter Konfiguration; kein harter Dienstzwang. |
FG Image benötigt keine Shell-Kommandos für die lokale Bildkonvertierung. Die lokale Verarbeitung verwendet die WordPress Image Editor API.
Webserver: Apache und Nginx
Section titled “Webserver: Apache und Nginx”Im Plugin-Code gibt es keine Apache- oder Nginx-spezifischen Rewrite-Regeln für die Bildausgabe. Die Varianten werden als normale Dateien im WordPress-Upload-Verzeichnis gespeichert und über reguläre URLs referenziert.
Eine ausdrückliche Apache-/Nginx-Testmatrix ist im Projekt nicht enthalten.
Browser
Section titled “Browser”FG Image führt keine Browser- oder User-Agent-Erkennung für AVIF/WebP durch. Stattdessen werden standardkonforme <picture>-/<source type="…">-Elemente verwendet, sodass der Browser ein von ihm unterstütztes Format auswählen kann.
Konkrete minimale Browserversionen werden im Projekt nicht definiert und werden daher hier nicht behauptet.
Bestehende Themes und <picture>
Section titled “Bestehende Themes und <picture>”Seit Version 1.0.1 ist bestehendes <picture>-Markup technisch berücksichtigt. FG Image erweitert eindeutig zuordenbare Pictures in-place und vermeidet verschachtelte <picture>-Elemente.
Custom-Theme-<img>-Elemente können verarbeitet werden, wenn die Zuordnung zu einem WordPress-Attachment eindeutig ermittelt werden kann. Externe oder nicht zuordenbare Bilder bleiben unverändert.
Eine allgemeine Kompatibilitätsgarantie für beliebige Themes lässt sich aus dem Code nicht ableiten.
CSS Grid und Flexbox
Section titled “CSS Grid und Flexbox”Von FG Image erzeugte <picture class="fg-image-picture">-Wrapper werden mit display: contents layoutneutralisiert und übernehmen Dimensionswerte per inherit. Diese Logik ist ausdrücklich für Layouts relevant, in denen das zusätzliche Wrapper-Element sonst die Platzierung des ursprünglichen <img> verändern würde.
Bootstrap .ratio
Section titled “Bootstrap .ratio”Version 1.0.4 enthält eine ausdrückliche Sonderregel für .ratio > .fg-image-picture. Direkt unter einem Bootstrap-.ratio-Container erhält der erzeugte Wrapper wieder eine reale Box mit 100 % Breite und Höhe; das enthaltene <img> füllt diese Box ebenfalls.
Die Regel basiert auf der Bootstrap-Klassenkonvention .ratio, ohne im Plugin eine Bootstrap-Version zu erkennen oder vorauszusetzen.
FG Performance
Section titled “FG Performance”Status: technisch integriert.
FG Image registriert einen Filter auf fg_performance_critical_assets_preloads. Wenn ein Image-Preload eindeutig einem WordPress-Attachment mit vollständigen FG-Varianten zugeordnet werden kann und die Frontend-Ausgabe aktiv ist, kann der Preload auf den bevorzugten modernen Source umgeschrieben werden.
Die Integration wird über die Konstante FG_PERFORMANCE_VERSION im Diagnose-Status erkannt. Es gibt keine harte Abhängigkeit von FG Performance.
FG Static Export
Section titled “FG Static Export”Status: technisch integriert.
FG Image registriert einen Filter auf fg_static_export_html und stellt darin den eigenen Extension-Point fg_image_static_export_html bereit. Das Bild-Markup wird von dieser Integrationsklasse selbst nicht zusätzlich verändert.
Die Integration wird über FG_STATIC_EXPORT_VERSION im Diagnose-Status erkannt. Es gibt keine harte Abhängigkeit.
FG Cache
Section titled “FG Cache”Status: Invalidierungs-API vorhanden.
Bei Änderungen an registrierten Varianten löst FG Image fg_image_cache_invalidation_requested mit einem Payload aus Attachment-ID, Original-URL, Variantenpfaden/-URLs, Änderungsgrund und Plugin-Version aus.
FG Image purgt selbst keinen Page Cache. Wenn FG_CACHE_VERSION definiert ist, zeigt die Diagnose an, dass ein FG Cache erkannt wurde.
CDN und externe Storage-URLs
Section titled “CDN und externe Storage-URLs”FG Image enthält keinen fest verdrahteten CDN-Anbieter. Über fg_image_variant_url kann eine Integration die berechnete Varianten-URL verändern.
Die interne URL-Umschreibung versucht Query-Strings und Fragmente zu erhalten und kann relative bzw. filename-basierte Kandidaten verarbeiten. Eine konkrete CDN-Kompatibilitätsliste ist nicht Bestandteil des Projekts.
Multisite
Section titled “Multisite”Der eingebettete FG Core erkennt Multisite-Kontext für seine Statuskommunikation. Im eigentlichen FG-Image-Bildkern ist jedoch keine gesonderte Netzwerkaktivierungs-, Netzwerk-Settings- oder Multisite-Testlogik dokumentiert.
Daher wird Multisite hier nicht als getestet ausgewiesen. Der offene Verifikationspunkt ist zusätzlich in REVIEW.md festgehalten.
REST API, AJAX, Cron und WP-CLI
Section titled “REST API, AJAX, Cron und WP-CLI”Für die Bildfunktionen von FG Image 1.0.4 sind im Projekt keine eigenen REST-Routen, keine wp_ajax_*-Endpunkte und keine WP-CLI-Kommandos registriert.
Die Bild-Stapelverarbeitung arbeitet über Admin-POST-Requests und nicht über WP-Cron. Der eingebettete FG Core verwendet dagegen einen täglichen Cronjob für seine Statuskommunikation.