Shopware: „The content model is not determinist" beheben

Wenn dein Shopware-6-Admin beim Öffnen von Einstellungsseiten den Fehler „The content model is not determinist” (ERROR 3070) wirft, liegt das an einem libxml2-Update auf deinem Server — nicht an deinem Shop. Betroffen sind alle Shopware-Versionen vor 6.5.8.1. Die dauerhafte Lösung ist ein Shopware-Update; für ältere Versionen gibt es einen sauberen Workaround.

Die vollständige Fehlermeldung sieht so aus:

Unable to parse file ".../vendor/shopware/core/System/Resources/config/update.xml".
Message: [ERROR 3070] complex type 'input-field': The content model is not determinist.
(in in_memory_buffer - line 30, column 0)

Statt update.xml kann jede andere Konfigurations-Datei genannt werden — etwa basicInformation.xml oder bei Plugins die config.xml mit complex type pluginType. Die genannte XML-Datei ist nie das Problem.

Was ist passiert?

Die Bibliothek libxml2 C-Bibliothek für XML-Verarbeitung — Standard auf praktisch jedem Linux-Server. PHP nutzt sie für alle XML-Operationen. validiert ab Version 2.12.0 XSD-Schemata strenger. Mehrdeutige Schemata, die ältere Versionen fälschlich akzeptiert haben, werden jetzt abgelehnt. Das Update auf libxml2 ≥ 2.12 kam auf vielen Servern automatisch — als Teil der Sicherheitskorrektur für CVE-2024-25062 per Betriebssystem- oder Panel-Update. Hintergründe zur Lücke und weiteren betroffenen Systemen haben wir im Blog zusammengefasst: Problemlösungen zu CVE-2024-25062 (libxml2).

Shopwares Schema-Datei vendor/shopware/core/System/SystemConfig/Schema/config.xsd fällt durch diese strengere Prüfung. Der Fehler liegt also im mitgelieferten XSD-Schema XML Schema Definition — beschreibt, wie eine XML-Datei aufgebaut sein muss, damit sie gültig ist. , nicht in der gemeldeten XML-Datei. Shopware hat das Schema mit Commit NEXT-31872 korrigiert — enthalten ab Version 6.5.8.1.

Betroffen ist dein Shop, wenn beide Bedingungen zutreffen:

• Shopware 6.5.x vor 6.5.8.1 oder eine beliebige 6.4.x-Version läuft, und
• der Server libxml2 ≥ 2.12 hat (prüfbar per php -i | grep libxml).

Lösung 1: Shopware aktualisieren (empfohlen)

Die saubere, dauerhafte Lösung. Aktualisiere auf 6.5.8.1 oder neuer — damit ist das korrigierte Schema an Bord.

1. Leg ein Backup von Dateien und Datenbank an.
2. Führe das Update über die Admin-Oberfläche oder per CLI aus:

   composer update shopware/core --with-dependencies
   bin/console system:update:finish

3. Leere den Cache: bin/console cache:clear.
4. Öffne eine Einstellungsseite im Admin — der Fehler ist weg.

Shopware 6.4 ist End-of-Life

Die 6.4er-Reihe (letzte Version: 6.4.20.2) erhält keine Security-Updates mehr. Der Workaround unten hält deinen Shop am Laufen — plane aber zeitnah das Upgrade auf eine unterstützte Version. Stand Juni 2026 werden 6.5 (Security-Support bis 28.02.2027), 6.6 und 6.7 unterstützt; aktuelle Version ist 6.7. Beim Sprung von 6.4 auf 6.5+ kommen Breaking Changes auf dich zu: Bootstrap 5 im Storefront, Vue 3 in der Administration, neue PHP-Anforderungen. Teste das Upgrade vorher auf einer Staging-Umgebung.

Lösung 2: Workaround für 6.4 und ältere 6.5

Wenn das Update nicht sofort möglich ist, lässt sich das korrigierte Schema nachrüsten. Der einfachste Weg ist das Composer-Paket shyim/shopware-libxml2-fix — geschrieben vom Autor des offiziellen Fixes. Es patcht das XSD automatisch bei jedem composer install:

1. Installiere das Paket:

   composer require shyim/shopware-libxml2-fix

2. Leere den Cache:

   bin/console cache:clear

Alternativ manuell: die korrigierte config.xsd aus dem aktuellen Shopware-Repository herunterladen, nach vendor/shopware/core/System/SystemConfig/Schema/config.xsd kopieren und den Cache leeren.

Vendor-Änderungen sind flüchtig

Manuelle Änderungen im vendor-Ordner überleben kein composer install — beim nächsten Deployment ist der Fehler zurück. Für den Dauerbetrieb die Änderung als Patch über cweagans/composer-patches hinterlegen, oder gleich das oben genannte Fix-Paket nutzen, das genau das automatisiert.

Warum kein libxml2-Downgrade?

Ein Downgrade oder Pinning von libxml2 auf < 2.12 würde den Fehler ebenfalls beseitigen — wir raten davon ab. Du hältst damit eine Bibliothek mit bekannter Sicherheitslücke (CVE-2024-25062) auf dem Server, und beim nächsten Betriebssystem-Update bricht der Shop erneut. Die Ursache liegt im Shopware-Schema; dort gehört auch die Korrektur hin.

Wenn etwas schiefläuft

Fehler bleibt nach dem Update bestehen

Fast immer ein Caching-Problem — der alte Schema-Stand liegt noch im OPcache PHP-Bytecode-Cache — hält kompilierte PHP-Dateien im Speicher. Nach Datei-Änderungen kann er veralteten Code ausliefern. oder HTTP-Cache.

Lösung: bin/console cache:clear ausführen und zusätzlich HTTP-Cache sowie OPcache leeren (PHP-FPM-Neustart oder opcache_reset()).

Fehler erscheint nur bei einem bestimmten Plugin

Das Plugin liefert ein eigenes fehlerhaftes XSD mit (complex type pluginType) — der Shopware-Core-Fix hilft hier nicht.

Lösung: Plugin-Update einspielen oder den Plugin-Hersteller kontaktieren.

composer require schlägt mit Versions-Konflikt fehl

Das Fix-Paket benötigt eine kompatible Composer-Konfiguration.

Lösung: Mit composer why-not shyim/shopware-libxml2-fix prüfen, welches Paket blockiert — meist hilft ein composer update --with-dependencies der genannten Abhängigkeit.

Übrigens: gleicher Fehler, andere Software

ERROR 3070 nach dem libxml2-Update trifft nicht nur Shopware 6. Magento meldet ihn in der esconfig.xsd — wie du ihn dort behebst, steht im Magento-Artikel. Gleiche Ursache, eigener Fix.

Verwandte Artikel

• Magento: „The content model is not determinist” beheben — dasselbe Problem beim Magento-Reindex.
• Backup & Wiederherstellung — vor jedem Shopware-Update Pflicht.
• Fehlersuche — weitere Diagnose-Quereinstiege, wenn der Shop nicht tut, was er soll.

Du kommst nicht weiter?

Wenn der Fehler nach Update oder Workaround weiter auftritt: Ticket im Kundencenter öffnen. Hilfreich für die Diagnose: deine Shopware-Version, die vollständige Fehlermeldung und ob der Fehler im Admin, im Storefront oder in beiden auftritt.