[In der nächsten Version behoben] Bug Report: Fatal Error in WPML String Translation 3.4.1 on PHP 8.1+
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
# Bug Report: Fatal Error in WPML String Translation 3.4.1 on PHP 8.1+
## Environment
- **WPML String Translation Version:** 3.4.1
- **PHP Version:** 8.1+
- **WordPress Version:** 6.x
- **WooCommerce:** Active (with German Market)
- **Server:** Linux (ISPConfig)
## Error
```
PHP Fatal error: Uncaught ValueError: DOMDocument::loadHTML(): Argument #1 ($source) must not be empty
in .../wp-content/plugins/wpml-string-translation/StringTranslation/Infrastructure/StringHtml/Repository/HtmlStringsRepository.php:31
```
The method `HtmlStringsService::readHtmlFromBuffer()` is registered as an `ob_start()` callback (line 56). During shutdown, WordPress calls `wp_ob_end_flush_all()` which flushes the output buffer and triggers this callback.
The callback correctly handles AJAX and JSON requests:
```php
// HtmlStringsService.php:59-67
public function readHtmlFromBuffer( $output ) {
if ( ( wpml_is_ajax() || wp_is_json_request() ) ) {
// AJAX/JSON handled safely
} else {
// Regular requests -> passes $output directly to HTML parser
$htmlStrings = $this->extractStringsFromHtml( (string) $output );
}
...
}
```
However, **redirect requests are not handled**. When WordPress performs a `wp_redirect()` + `exit` (e.g., WooCommerce checkout, add-to-cart, login), no HTML output is generated. The output buffer is empty, and `$output` is an empty string.
This empty string is passed through to `HtmlStringsRepository::loadHtml()`:
### Option B: In `HtmlStringsRepository::loadHtml()`
```php
private function loadHtml( string $html ) {
if ( $html === '' ) {
return new \DOMDocument();
}
// ... existing code
}
```
## Current Workaround
We use a must-use plugin that drains all output buffers before `wp_ob_end_flush_all` runs, using `ob_get_clean()` (which does not trigger callbacks) instead of `ob_end_flush()` (which does):
This workaround bypasses WPML's output buffer callback entirely, which means WPML's frontend string detection is disabled. A proper fix in the plugin is preferred.
Ich muss in dem Fall wissen, wie genau ich dieses Problem replizieren kann.
Kann ich mir das eventuell zuerst einmal auf einer Staging-Site anschauen, auf der dieser Fehler auftritt?
Tritt der Fehler nur dann auf, wenn das Plugin "German Market" verwendet wird?
---
Ich möchte einen temporären Zugriff (wp-admin und FTP) auf die Website anfordern, um das Problem genauer zu untersuchen.
Die dafür erforderlichen Felder findest du unterhalb des Kommentarbereichs, wenn Du dich anmeldest, um die nächste Antwort zu hinterlassen. Die Informationen, die du angibst, sind privat, was bedeutet, dass nur du und ich sie sehen und darauf zugreifen können.
WICHTIG
Lege bitte unbedingt eine Sicherungskopie der Website und der Datenbank an, bevor Du uns den Zugriff gewährst.
Wenn Du die Felder "wp-admin / FTP" nicht sehen kannst, werden Ihre Anmeldedaten für Post und Website als "PUBLIC" (Öffentlich) festgelegt. Veröffentliche die Daten NICHT, es sei denn, Du siehst die erforderlichen wp-admin / FTP-Felder.
Ich muss hier eventuell ein Plugin namens "All In One WP Migration" installieren, um eine Kopie der Website anzulegen, auf welcher ich das Problem genauer untersuchen kann.
Ich wäre allerdings auch sehr dankbar, wenn du zu diesem Zweck selbst eine Staging Site von deinem Server aus bereitstellen könntest.
Bei Fragen zum Erstellen einer solchen Staging Site kannst Du deinen Hosting-Anbieter konsultieren. Achte bitte darauf, dass WPML auf diesem Staging ebenso unter https://wpml.org/de/account/websites/ registriert sein muss.
Solltest Du dazu nicht in der Lage sein, eine solche Kopie der Website zum Testen bereitzustellen, dann lass es mich bitte auf diesem Ticket wissen.
Das private Antwortformular sieht folgendermaßen aus: versteckter Link
Klicke beim nächsten Antworten auf "I still need assistance".
Video: versteckter Link
Beachte bitte, dass wir verpflichtet sind, diese Informationen auf jedem Ticket individuell anzufordern. Wir dürfen nicht auf Zugangsinformationen zugreifen, die nicht speziell auf diesem Ticket im privaten Antwortformular übermittelt wurden.
Vielen Dank, dass du dieses Problem an uns berichtet hast!
Ich habe die entsprechende Funktion in deiner Version von WPML String Translation nun angepasst und der Fehler scheint nun nicht mehr aufzutreten.
Datei \wp-content\plugins\wpml-string-translation\StringTranslation\Infrastructure\StringHtml\Repository\HtmlStringsRepository.php auf Zeile 27 ersetze die Funktion loadHtml() mit dieser Version:
Kannst du dir das bitte mal anschauen und mich wissen lassen, ob du den Fehler weiterhin bestätigen kannst?
Ich werde diese Problem intern eskalieren, muss aber zunächst versuchen diesen Fehler auf einer neuen Test Site zu replizieren, um das Problem und eine mögliche Lösung an unsere Entwickler weiterleiten zu können.
Ich habe heute auf einem Apache Server mit PHP 8.1 eine lokale Kopie deiner Website getestet und kann den folgenden Fehler, ohne Anwendung der vorhandenen Workarounds, leider nicht replizieren:
PHP Fatal error: Uncaught ValueError: DOMDocument::loadHTML(): Argument #1 ($source) must not be empty in /var/www/clients/client1/web37/web/wp-content/plugins/wpml-string-translation/StringTranslation/Infrastructure/StringHtml/Repository/HtmlStringsRepository.php:31
Der Fehler scheint auf deiner Website dann aufzutreten, wenn WPML in Zweitsprachen nach übersetzbaren Strings sucht und dabei auf einen leeren Output Buffer trifft. In PHP 8.1 führt DOMDocument::loadHTML('') zu einem Fatal Error. Der Workaround verhindert dies, indem der Buffer vorzeitig geleert wird, sodass WPML gar nicht erst versucht, ihn zu parsen.
Woher dieser leere Buffer in deiner Umgebung genau kommt, ist mir aktuell unklar. In meiner lokalen Testumgebung (Apache mit PHP 8.1) tritt dieser Zustand nicht auf, daher konnte ich den Fehler nicht nachstellen. Der einzige schwerwiegende Fehler, den ich dort sehe, ist:
PHP Fatal error: Uncaught Error: Call to a member function get_user_id() on bool in /var/www/clients/client1/web37/web/wp-content/themes/flatsome-child/inc/b2b.php:15
Stack trace:
#0 /var/www/clients/client1/web37/web/wp-content/themes/flatsome-child/inc/cart.php(485): is_b2b()
#1 /var/www/clients/client1/web37/web/wp-includes/class-wp-hook.php(341): get_cached_cart()
#2 /var/www/clients/client1/web37/web/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#3 /var/www/clients/client1/web37/web/wp-includes/plugin.php(522): WP_Hook->do_action()
#4 /var/www/clients/client1/web37/web/wp-admin/admin-ajax.php(192): do_action()
#5 {main}
thrown in /var/www/clients/client1/web37/web/wp-content/themes/flatsome-child/inc/b2b.php on line 15
Ich kann das Problem mit WPML intern nur dann eskalieren, wenn ich es zuverlässig replizieren kann. Da du jedoch nginx mit PHP 8.1 einsetzt, werde ich diese Konstellation nachstellen und prüfen, ob sich der Fehler damit reproduzieren lässt. Ich melde mich anschließend mit einem Update zurück.
Es könnte außerdem erwägenswert sein, ein Update auf PHP 8.3 durchzuführen, da dort der Umgang mit DOMDocument::loadHTML('') weniger restriktiv ist und der Fehler unter Umständen nicht mehr auftritt.
danke für dein Update! Kurz zur Klarstellung: Der Fehler ist nicht webserver-spezifisch (nginx vs. Apache). Das Output Buffering ist reines PHP-Verhalten und identisch auf beiden Plattformen.
Der Schlüssel zum Reproduzieren ist der Request-Typ:
Der Fehler tritt nicht bei normalen Pageloads auf (da gibt es immer HTML-Output). Er tritt bei Redirect-Requests auf, bei denen WordPress wp_redirect() + exit ausführt und kein HTML generiert wird. Der Output-Buffer ist dann leer.
So kannst du es reproduzieren:
1. WooCommerce mit aktivem WPML String Translation (ohne den loadHtml-Fix)
2. Einen der folgenden Aktionen ausführen:
- Produkt in den Warenkorb legen (POST → Redirect)
- Login durchführen (POST → Redirect)
- Checkout absenden (POST → Redirect)
3. Im Error-Log erscheint der Fatal Error
Bei diesen Aktionen ruft WordPress wp_redirect() + exit auf. Beim Shutdown flusht wp_ob_end_flush_all() den leeren Buffer → WPML's readHtmlFromBuffer() Callback bekommt einen leeren String → DOMDocument::loadHTML('') wirft den ValueError.
Der von dir angewendete Fix (empty-Check in loadHtml()) ist genau die richtige Lösung. Es wäre super, wenn das ins nächste offizielle Release aufgenommen wird.
Zum b2b.php-Fehler: Danke für den Hinweis, den haben wir auf unserer Seite behoben.
Wenn ich ein Produkt in den Warenbork lege, erhalte ich:
PHP Warning: Undefined array key "product" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce\cart\mini-cart.php on line 130
PHP Warning: Undefined array key "permalink" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce\cart\mini-cart.php on line 131
Öffne ich den Warenkorb oder melde mich und gehe ich zur Kasse, erhalte ich:
PHP Warning: Undefined array key "permalink" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce\cart\mini-cart.php on line 131
PHP Warning: Undefined array key "oop" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce\cart\cart.php on line 88
Führe ich eine Bestellung durch, erhalte ich:
PHP Warning: Undefined array key "page" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce\emails\email-order-details.php on line 73
PHP Warning: Undefined array key "de-mwst-1-19" in C:\laragon\www\ava-innovation\wp-
content\themes\flatsome-child\woocommerce\emails\email-order-details.php on line 160
PHP Warning: Undefined array key "page" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce-german-market\emails\customer-confirm-order.php on line 46
PHP Warning: Undefined array key "de-mwst-1-19" in C:\laragon\www\ava-innovation\wp-content\themes\flatsome-child\woocommerce-german-market\emails\customer-confirm-order.php on line 152
Ich kann hier nur zahlreiche Probleme im Child-Theme bestätigen.
Den berichteten WPML-Fehler kann ich auf meiner Localhost-Installation der Kopie eurer Website leider weiterhin nicht bestätigen.
danke für die Tests. Kurz zu den Warnings: Das sind PHP 8.x Strictness-Warnings (Undefined array key) — keine Fatal Errors und unabhängig vom gemeldeten WPML-Bug.
Mir fällt auf, dass du immer noch auf Apache/Laragon testest (C:\laragon\www). Der Webserver ist zwar nicht die Ursache, aber das Redirect-Verhalten auf Localhost kann vom Produktivserver abweichen.
Unabhängig von der Reproduzierbarkeit: Der Fix (empty-Check in loadHtml()) ist schlicht notwendig. DOMDocument::loadHTML('') wirft auf PHP 8.1+ einen ValueError — das ist dokumentiertes PHP-Verhalten. Ein leerer Output-Buffer ist ein valider Edge-Case (Redirects, AJAX ohne Output, REST-Responses). Der Code muss diesen Fall abfangen, egal auf welcher Umgebung.
Euer eigener Patch löst das Problem korrekt. Könnt ihr den trotzdem ins nächste Release aufnehmen — auch ohne lokale Reproduktion? Es ist ein defensiver One-Liner, der keine Seiteneffekte hat.
Ja, natürlich. Es ist nur so, dass ich generell den Fehler zuerst replizieren muss, um es den Entwicklern als Bug zu präsentieren.
Allerdings macht es auch aus meiner Sicht durchaus Sinn, den "Empty-Check" in loadHTML() in WPML Core zu implementieren.
Ich werde dies nun intern an den Second-Tier-Support weiterleiten, damit dieser dies nochmals verifiziert und dann an das Entwicklungsteam weiterleitet.
Feedback from Second Tier Support:
Wir können am zuvor empfohlenen Workaround (Anpassen der Funktion loadHtml) weiter festhalten und das Problem wurde an das WPML-Entwicklungsteam weitergeleitet.
Ein Fix wird in der kommenden Version von WPML integriert sein.
