config\/xml\/<\/code><\/pre><\/div>Die wichtigsten davon sind:
- must_have_modules_list.xml<\/span> \u2013 Liste der von PrestaShop als \u201eMust-Have\u201d gekennzeichneten Module<\/li>
- modules_native_addons.xml<\/span> \u2013 Liste der in Addons verf\u00fcgbaren nativen Module<\/li>
- Standard_L\u00e4nder_Module_Liste.xml<\/span> \u2013 empfohlene Module f\u00fcr ein bestimmtes Land<\/li>
- trusted_modules_list.xml<\/span> \u2013 Liste vertrauensw\u00fcrdiger, von PrestaShop verifizierter Module<\/li><\/ul>Diese Dateien haben keinen Einfluss auf das Frontend des Shops oder die Verarbeitung von Bestellungen. Sie dienen ausschlie\u00dflich zur Anzeige von Informationen im Bereich der Module des Admin-Panels.
Wie sieht ein XML-Fehler aus und wo tritt er auf?<\/h6>Der Fehler tritt meist direkt im Admin-Panel auf \u2013 im Reiter Module<\/strong> oder nach dem Betreten Modulmanager<\/strong>. Die Mitteilungen k\u00f6nnen wie folgt aussehen:
Fehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei must_have_modules_list.xml\nFehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei modules_native_addons.xml\nFehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei default_country_modules_list.xml<\/code><\/pre><\/div>Hinweis<\/div>Diese Fehler treten in PrestaShop 1.7 sowie in PrestaShop 8.x auf. In \u00e4lteren Versionen 1.6 funktioniert der Mechanismus \u00e4hnlich, auch wenn die Speicherorte einiger Dateien abweichen k\u00f6nnen.<\/div><\/div>
Woher kommt dieser Fehler?<\/h6>PrestaShop sendet HTTP-Anfragen an die PrestaShop Addons API, um aktuelle Modullisten abzurufen. Ein Beispiel-Endpunkt sieht so aus:
https:\/\/api.addons.prestashop.com\/?version=1.7.8.x&method=listing&action=must-have<\/code><\/pre><\/div>Der Shop erwartet eine Antwort im XML-Format. Ein Problem tritt auf, wenn:- API Addons gibt eine Antwort in einem anderen Format zur\u00fcck (z. B. JSON oder eine HTML-Fehlerseite)<\/li>
- Die Verbindung zur API ist durch die Firewall oder die Serverkonfiguration blockiert<\/li>
- Der Server des Shops hat keinen Zugriff auf externe Ressourcen (kein ausgehender HTTP\/HTTPS-Verkehr).<\/li>
- API Addons ist vor\u00fcbergehend nicht verf\u00fcgbar oder gibt ein Timeout zur\u00fcck<\/li>
- Die PrestaShop-Version ist zu alt und wird nicht mehr von der API unterst\u00fctzt<\/li><\/ul>PHP-Parser Einfaches XML String Laden<\/span> bei dem Versuch, eine falsche Antwort zu verarbeiten, wird genau dieser Fehler gemeldet \u2013 Start-Tag erwartet<\/em>.
Beeinflusst der Fehler die Funktionsweise des Shops?<\/h6>Erfolg<\/div>Das Frontend des Shops, der Warenkorb, Bestellungen, Zahlungen und alle Kaufprozesse funktionieren normal. Der Fehler betrifft ausschlie\u00dflich das Backend \u2013 speziell den Bereich der Modulverwaltung.<\/div><\/div>Was kann im Bedienfeld ausfallen:- Liste empfohlener Module<\/li>
- \u201eMust-have\u201d-Bereich im Modulmanager<\/li>
- Marktplatz-Add-ons, verf\u00fcgbar \u00fcber den Administrator<\/li>
- Modulvorschl\u00e4ge f\u00fcr das Land<\/li>
- langsamere Seitenladezeit Module (Timeout bei Verbindungsversuch zur API)<\/li><\/ul>
Schritt 1 \u2013 \u00dcberpr\u00fcfung des Inhalts von XML-Dateien<\/h6>Bevor Sie \u00c4nderungen vornehmen, ist es ratsam zu pr\u00fcfen, was sich derzeit in den Dateien befindet. Durch SSH<\/a> wir f\u00fchren durch:
Katze config\/xml\/must_have_modules_list.xml<\/code><\/pre><\/div>Wenn die Datei leer ist, HTML (z. B. eine 503-Fehlerseite) oder JSON anstelle von XML enth\u00e4lt, ist dies die Ursache des Problems.
Tipp<\/div>Um den Inhalt einer Datei zu \u00fcberpr\u00fcfen, k\u00f6nnen Sie auch den Dateimanager im Hosting-Panel (z. B. Hestia CP, cPanel) oder einen FTP-Client verwenden \u2013 ein SSH-Zugriff ist nicht erforderlich.<\/div><\/div>
Schritt 2 \u2013 Austausch der Dateien gegen korrektes XML<\/h6>Die schnellste L\u00f6sung ist, den Inhalt der problematischen Dateien durch minimales, korrektes XML zu ersetzen. Per SSH f\u00fchren wir durch:
echo '' > config\/xml\/must_have_modules_list.xml\necho '' > config\/xml\/modules_native_addons.xml\necho '' > config\/xml\/default_country_modules_list.xml\necho '' > config\/xml\/trusted_modules_list.xml<\/code><\/pre><\/div>Sie k\u00f6nnen Dateien auch manuell \u00fcber FTP hochladen. Der Inhalt jeder Datei sollte wie folgt aussehen:
<\/code><\/pre><\/div>Warnung<\/div>Nur der Austausch der Dateien wird das Problem vor\u00fcbergehend l\u00f6sen. PrestaShop wird beim n\u00e4chsten Aktualisieren der Modulseite versuchen, die Daten erneut von der API abzurufen und k\u00f6nnte die Dateien mit einer fehlerhaften Antwort \u00fcberschreiben.<\/div><\/div>
Schritt 3 \u2013 Dauerhafte L\u00f6sung durch Klassen-Override<\/h6>Um das Herunterladen von XML aus der Addons API dauerhaft zu blockieren, erstellen wir einen Klassen-Override Werkzeuge<\/span>. Wir erstellen eine Datei:
override\/classes\/Tools.php<\/code><\/pre><\/div>Betreffend den folgenden Inhalt:
<?php\nclass Tools extends ToolsCore\n{\n protected static $is_addons_up = false;\n}<\/code><\/pre><\/div>Eigenschaft $ist_addons_up = false<\/span> verhindert, dass PrestaShop versucht, eine Verbindung zur Addons-API herzustellen \u2013 und folglich keine XML-Dateien herunterl\u00e4dt oder \u00fcberschreibt.
Nachdem die Override-Datei erstellt wurde, leeren wir den Cache. F\u00fcr PrestaShop 1.7 \/ 8.x<\/strong>:
rm -rf var\/cache\/dev\/*\nrm -rf var\/cache\/prod\/*<\/code><\/pre><\/div>Sie k\u00f6nnen den Cache auch \u00fcber das Administrationspanel l\u00f6schen: Erweitert > Leistung > Cache leeren<\/strong>.
Infos<\/div>Nach Anwendung von \"override\" funktioniert der Modulbereich weiterhin vollumf\u00e4nglich \u2013 Module k\u00f6nnen aus ZIP-Dateien installiert, deinstalliert und aktualisiert werden. Nur die Integration mit dem Addons-Marktplatz im Admin-Panel wird deaktiviert.<\/div><\/div>
Alternative \u2013 Schreibschutz f\u00fcr Dateien<\/h6>Wenn wir kein Override verwenden m\u00f6chten, k\u00f6nnen die XML-Dateien auf schreibgesch\u00fctzt gesetzt werden. PrestaShop kann sie dann nicht \u00fcberschreiben:
chmod 444 config\/xml\/must_have_modules_list.xml\nchmod 444 config\/xml\/modules_native_addons.xml\nchmod 444 config\/xml\/default_country_modules_list.xml\nchmod 444 config\/xml\/trusted_modules_list.xml<\/code><\/pre><\/div>Hinweis<\/div>Die Methode mit chmod ist einfacher, aber sie eliminiert nicht die Versuche, sich mit der API zu verbinden \u2013 PrestaShop wird sie weiterhin ausf\u00fchren, was das Laden der Modulseiten verlangsamen kann. Das \u00dcberschreiben der Klasse Tools ist eine technisch sauberere L\u00f6sung.<\/div><\/div>
Was verlieren wir nicht, wenn wir die Add-ons-API deaktivieren?<\/h6>Es ist erw\u00e4hnenswert, dass die meisten dieser Funktionen in einer Produktionsumgebung ohnehin nicht t\u00e4glich genutzt werden: