Skip to content

Kompatibilität

Diese Seite trennt Mindestanforderungen und im Code ausdrücklich berücksichtigte Integrationen von Bereichen, für die im Projekt keine belastbare Testaussage vorliegt.

Bereich Status Belegbares Verhalten
WordPress Mindestversion 5.7 Plugin-Header Requires at least: 5.7
PHP Mindestversion 7.4 Plugin-Header und FG-Core-Manifest verlangen PHP 7.4
Pretty Permalinks technisch erwartet Der Diagnosecheck stuft Plain Permalinks für Prefix-URLs als problematisch ein
Frontend-JavaScript nicht erforderlich Das Plugin registriert kein eigenes Frontend-JavaScript

Der README-Text nennt PHP 8.3 als getestet. Im Projekt liegt jedoch kein allgemeiner automatisierter Kompatibilitätstest für PHP-Versionen vor. Daher wird PHP 8.3 hier nicht als unabhängig verifizierte Testmatrix ausgewiesen.

FG Multilang WP kann öffentliche Post Types in der Administration als übersetzbar aktivieren. attachment wird aus dieser Post-Type-Auswahl ausgeschlossen.

Standardmäßig sind aktiv:

  • page,
  • post.

Für Custom Post Types werden sprachabhängige Slugs und Archive nur innerhalb der im Code vorgesehenen WordPress-Rewrite-Logik verarbeitet.

Öffentliche Taxonomien können aktiviert werden. Ausgeschlossen sind in der Administrationsauswahl:

  • nav_menu,
  • link_category,
  • post_format.

Standardmäßig sind category und post_tag aktiviert.

Status: technisch berücksichtigt, optional.

Ohne ACF läuft das Plugin weiter. ACF-spezifische Funktionen stehen dann nicht zur Verfügung.

Bei vorhandenem ACF sind im Code unter anderem berücksichtigt:

  • Kopieren normaler Post-Meta-Werte beim Erstellen einer Übersetzung,
  • Relink bestimmter ACF-Feldtypen,
  • ACF-WYSIWYG-Links,
  • ACF Options Pages über Field-Group-Locations mit options_page,
  • sprachabhängige Rückgabe von get_field(..., 'option') und get_field(..., 'options').

Eine projektspezifische Garantie für alle ACF-Feldtypen oder beliebig verschachtelte Custom-Strukturen lässt sich aus dem Code nicht ableiten.

Status: im ausgelieferten Paket enthalten.

Das Projekt enthält FG Core 1.1.3 unter includes/fg-core/. Beim Laden registriert jede eingebettete FG-Core-Kopie einen Kandidaten; der Bootstrap wählt unter geladenen Kandidaten die höchste Version und API-Version aus.

FG Multilang registriert sich anschließend beim aktiven Core für die gemeinsame FUNCKGROUP-Administration.

FG Core ist in diesem Paket deshalb keine separat zu installierende Laufzeitabhängigkeit.

Die Statusmeldung von FG Core wird unter Datenverarbeitung dokumentiert.

Status: optionale Filter-Integration.

FG Multilang WP registriert sich am Filter fg_static_export_urls und ergänzt dort seine Sprach-URLs. Es gibt keine harte Klassen- oder Konstantenabhängigkeit auf FG Static Export.

Die URL-Liste kann auch ohne installiertes Static-Export-Plugin über fgml_get_export_urls() berechnet werden.

Status: optional unterstützt.

Wenn WP_CLI aktiv und WP_CLI_Command verfügbar ist, registriert das Plugin den Befehl wp fgml mit den Subcommands:

  • status,
  • prepare,
  • create-missing,
  • flush.

FG Multilang WP registriert keine eigenen REST-Routen.

FG Multilang WP registriert keine eigenen WordPress-AJAX-Handler. Die String-Output-Ersetzung wird bei AJAX-Requests ausdrücklich übersprungen.

Ein eigener Mechanismus zur Übernahme eines Sprachprefixes in beliebige fremde admin-ajax.php-Requests ist im aktuellen Code nicht implementiert.

Die Mehrsprachigkeitsfunktionen selbst registrieren keinen eigenen Übersetzungs-Cronjob.

Das gebündelte FG Core registriert jedoch den täglichen Status-Cron fg_core_send_installation_status. Siehe Datenverarbeitung.

FG Core erfasst Multisite-Status, Network-ID und Blog-ID für seinen technischen Statusreport. FG Multilang selbst enthält jedoch keine explizite Network-Aktivierungsroutine, die bei einer Multisite-Installation über alle Sites iteriert.

Im Projekt liegt außerdem kein Multisite-Test vor. Eine offizielle Multisite-Unterstützung wird deshalb hier nicht behauptet.

Der Plugin-Code enthält keine serverabhängige .htaccess- oder Nginx-Konfiguration. Das Routing nutzt die WordPress-Rewrite-API.

Eine konkrete getestete Apache-/Nginx-Matrix ist im Projekt nicht vorhanden.

Der Sprachumschalter erzeugt serverseitiges HTML und benötigt kein eigenes Frontend-JavaScript. Eine definierte Browser-Support-Matrix ist im Projekt nicht enthalten.

Die Laufzeitlogik schreibt keine eigenen Cache-, Übersetzungs- oder Logdateien in das Dateisystem.

Für JSON-Imports liest das Plugin die von WordPress/PHP bereitgestellte temporäre Upload-Datei. Eine maximale JSON-Größe von 5 MB wird nach dem Einlesen geprüft.