[Geschlossen] Gravity Forms Multilingual

Hallo, nein ich habe keine Staging Umgebung sondern arbeite in Life in einer Art continious integration mit fortlaufenden Tests. Wir könnten ggf. einen gemeinsamen Termin vereinbaren und in einer Screenshare session drauf schauen?

Bei aktiviertem Plugin Gravity Forms Multilingual (WPML Add-on) tritt in der Gravity-Forms-Admin-Ansicht einzelner Entries ein reproduzierbarer 502-Fehler auf. Der Fehler betrifft ausschließlich die Ansicht einzelner Einträge unter /wp-admin/admin.php?page=gf_entries&view=entry&id=FORM_ID&lid=ENTRY_ID und ist eindeutig sprachabhängig.

Für denselben Entry funktioniert die Anzeige nur in einer bestimmten Sprache, während sie in der jeweils anderen Sprache zuverlässig in einen 502-Fehler läuft. Beispiel: Entry 95303 kann in der Admin-Ansicht problemlos mit &lang=de geöffnet werden, führt aber mit &lang=en reproduzierbar zu einem 502-Fehler. Bei Entry 101780 ist es genau umgekehrt: &lang=en funktioniert, &lang=de führt zum Fehler. Dieses Verhalten ist konsistent und unabhängig von der Datenmenge oder Anzahl der Uploads.

Wichtig ist: Dieselben Entries lassen sich in Gravity Flow Views vollständig und fehlerfrei anzeigen, selbst wenn dort alle Felder inklusive Upload-Felder dargestellt werden. Der Fehler tritt ausschließlich in der Gravity-Forms-Admin-Entry-Ansicht auf und nur, wenn Gravity Forms Multilingual aktiv ist. Alle Custom-Snippets wurden testweise deaktiviert, Image-Hopper deaktiviert, und das Problem bleibt bestehen. Es handelt sich nicht um ein generelles Performance-Problem, sondern um ein sprachabhängiges Fehlverhalten.

Die Analyse zeigt, dass Gravity Forms Multilingual in der Admin-Entry-Ansicht offenbar versucht, Entry-Feldwerte (inklusive Multi-Upload-Felder mit Bildern und Videos) gemäß der aktuell gesetzten WPML-Sprache (?lang=xx) zu verarbeiten bzw. zu „übersetzen“. Wenn die angeforderte Sprache nicht der Ursprungssprache des Entries entspricht, läuft GFML in einen sehr aufwendigen oder fehlerhaften Verarbeitungspfad (vermutlich Media-/Attachment-Handling), was zu einem PHP-FPM-Abbruch und damit zum 502-Fehler führt. Gravity Flow ist davon nicht betroffen, da es eine eigene, schlankere Rendering-Logik verwendet und diesen GFML-Pfad nicht nutzt.

Als Workaround wurde implementiert, dass die Gravity-Forms-Admin-Entry-Ansicht automatisch in der Ursprungssprache des Entries geöffnet wird. Sobald die Admin-Sprache nicht mit der Entry-Sprache übereinstimmt, erfolgt ein Redirect auf die korrekte Sprache. Mit diesem Workaround bleibt Gravity Forms Multilingual vollständig aktiv, mehrsprachige Frontend-Formulare und Workflows funktionieren weiterhin, und der 502-Fehler tritt nicht mehr auf. Der Workaround belegt eindeutig, dass der Entry valide ist und die Daten nicht beschädigt sind, sondern dass der Fehler durch sprachfremdes Rendering eines Entries durch GFML verursacht wird.

Der eingesetzte Workaround-Code lautet:

add_action('admin_init', function () {

if (
! is_admin() ||
($_GET['page'] ?? '') !== 'gf_entries' ||
($_GET['view'] ?? '') !== 'entry'
) {
return;
}

$entry_id = isset($_GET['lid']) ? (int) $_GET['lid'] : 0;
if (! $entry_id) return;

// Aktuell angeforderte WPML-Sprache
$requested_lang = $_GET['lang'] ?? '';
if (! $requested_lang) return;

// Entry laden
if (! class_exists('GFAPI')) return;
$entry = GFAPI::get_entry($entry_id);
if (is_wp_error($entry)) return;

// Heuristik zur Ermittlung der Entry-Ursprungssprache
// (z. B. über source_url)
$entry_lang = '';
if (! empty($entry['source_url'])) {
if (strpos($entry['source_url'], '/de/') !== false) {
$entry_lang = 'de';
} else {
$entry_lang = 'en';
}
}

if ($entry_lang && $requested_lang !== $entry_lang) {
wp_safe_redirect(
add_query_arg('lang', $entry_lang, remove_query_arg('lang'))
);
exit;
}
});

Aus unserer Sicht sollte Gravity Forms Multilingual in der Admin-Entry-Ansicht entweder automatisch die Ursprungssprache des Entries verwenden, Upload-Felder nicht sprachabhängig verarbeiten oder bei einem Sprach-Mismatch sauber auf die Entry-Sprache zurückfallen, statt einen Fehler zu verursachen. Das beschriebene Verhalten ist deterministisch, reproduzierbar und hängt ausschließlich von Entry-ID und Sprache ab, weshalb ein Staging-System zur Analyse nicht erforderlich ist.