Po zalogowaniu do panelu administracyjnego PrestaShop 1.6 widzisz ścianę czerwonych komunikatów z frazami typu jak na zdjęciu poniżej?
error module XML list
Spokojnie – sklep działa normalnie dla klientów, a problem leży w zepsutym mechanizmie pobierania danych z zewnętrznego API PrestaShop. W tym artykule wyjaśniamy, skąd się biorą te błędy i jak je wyeliminować na stałe w dwóch krokach przez FTP.

Czym są pliki country_module_list.xml i must_have_modules_list.xml?

PrestaShop 1.6 i 1.7  posiada wbudowany mechanizm, który regularnie komunikuje się z zewnętrznym serwerem api.addons.prestashop.com. Celem tego połączenia jest pobranie aktualnej listy rekomendowanych modułów dopasowanych do kraju sklepu oraz listy modułów oznaczonych jako „niezbędne” (must-have). Pobrane dane są zapisywane lokalnie w katalogu /config/xml/ w dwóch plikach:

  • default_country_modules_list.xml – lista modułów polecanych dla danego kraju,
  • must_have_modules_list.xml – lista modułów uznanych przez PrestaShop za kluczowe dla każdego sklepu.

Pliki te są odczytywane przez dashboard back-office i wyświetlane w sekcji „Polecane moduły”. Funkcja była przydatna w erze aktywnego rozwoju PrestaShop 1.6, gdy ekosystem modułów był na bieżąco aktualizowany. Dziś, kilkanaście lat po premierze tej wersji, mechanizm stał się wyłącznie źródłem problemów.

Dlaczego w PrestaShop 1.6 pojawiają się błędy XML?

Błędy nie wynikają z problemu z samym sklepem ani bazą danych. Ich prawdziwa przyczyna jest prosta: PrestaShop próbuje pobrać plik XML z zewnętrznego serwera, ale zamiast poprawnego XML-a otrzymuje stronę HTML – najczęściej stronę błędu 404, 503 lub przekierowanie. Dzieje się tak dlatego, że API PrestaShop dla wersji 1.6 jest już od dawna niestabilne lub niedostępne – wersja ta wyszła z oficjalnego wsparcia producenta.

Parser XML PrestaShop usiłuje następnie przetworzyć ten HTML jako XML, co kończy się lawiną komunikatów o błędach składni:

  • Opening and ending tag mismatch – tagi HTML jak <head>, <p>, <link> nie są poprawnym XML-em,
  • EntityRef: expecting ’;’ – znaki specjalne w HTML (np. & w atrybutach) łamią parser XML,
  • Specification mandates value for attribute async – atrybuty boolowskie HTML5 jak async czy selected nie mają wartości, co jest niedopuszczalne w XML,
  • Premature end of data – parser XML natknął się na koniec nieoczekiwanego dokumentu.

Przy każdym załadowaniu dashboardu sklep wysyła żądanie do zewnętrznego API, dostaje HTML zamiast XML i raportuje dziesiątki błędów. Błędy te są całkowicie niegroźne dla działania sklepu od strony klientów – nie wpływają na proces zakupu, ceny, stany magazynowe ani SEO frontendu. Są wyłącznie problemem widocznym w back-office administratora.

Jak naprawić błędy XML w PrestaShop 1.6 – instrukcja krok po kroku

Rozwiązanie składa się z dwóch kroków wykonywanych przez FTP. Cały proces zajmuje mniej niż 5 minut. Przed rozpoczęciem pobierz na komputer lokalny kopię zapasową pliku classes/Tools.php.

Krok 1 – wyłącz komunikację z API Addons w pliku Tools.php

Przez FTP otwórz plik classes/Tools.php. Na końcu pliku znajdź linię:

protected static $is_addons_up = true;

Zmień wartość true na false:

protected static $is_addons_up = false;

Zapisz plik i wgraj przez FTP. Ta zmiana sprawia, że metoda addonsRequest() zwraca false natychmiast, bez żadnych prób połączenia z zewnętrznym API – problem jest eliminowany u samego źródła.

Krok 2 – usuń uszkodzone pliki XML

Przez FTP przejdź do katalogu /config/xml/ i usuń dwa pliki:

  • default_country_modules_list.xml
  • must_have_modules_list.xml

Nie usuwaj pozostałych plików XML w tym katalogu – są one potrzebne do prawidłowego działania sklepu.

Po wykonaniu obu kroków, przy kolejnym załadowaniu dashboardu back-office, wszystkie błędy XML powinny całkowicie zniknąć.

Jakie są konsekwencje wyłączenia addonsRequest w PrestaShop?

To pytanie, które zadaje sobie każdy administrator po wdrożeniu tej poprawki. Odpowiedź jest prosta: konsekwencje dla działającego sklepu są minimalne.

Co przestaje działać po ustawieniu $is_addons_up = false:

  • Sekcja „Polecane moduły” na dashboardzie – nie wyświetli listy modułów polecanych przez PrestaShop Addons,
  • Sekcja „Must-have modules” – lista niezbędnych modułów nie będzie pobierana,
  • Automatyczne sugestie modułów podczas konfiguracji – instalator nie będzie podpowiadał rozszerzeń z marketplace.

Co nadal działa normalnie:

  • Wszystkie zainstalowane moduły – działają bez żadnych zmian,
  • Ręczna instalacja modułów przez BO lub FTP – bez zmian,
  • Zakupy, koszyk, płatności, wysyłka – absolutnie bez zmian,
  • SEO i indeksowanie przez Google – brak jakiegokolwiek wpływu,
  • Cały front-end sklepu – bez zmian.

Warto pamiętać, że PrestaShop 1.6 nie jest już oficjalnie wspierany przez producenta, a ekosystem Addons dla tej wersji jest szczątkowy. Większość administratorów i tak nie korzysta z rekomendacji modułów wyświetlanych na dashboardzie. Wyłączenie tej funkcji nie ma praktycznego znaczenia dla codziennego prowadzenia sklepu.

Jeśli kiedykolwiek zdecydujesz się na aktualizację PrestaShop do nowszej wersji 1.6.x, plik classes/Tools.php zostanie nadpisany oryginalną wersją. Warto odnotować tę modyfikację w dokumentacji technicznej sklepu, aby pamiętać o ponownym jej zastosowaniu.

Kopia zapasowa przed modyfikacją – obowiązek, nie opcja

Przed jakąkolwiek ingerencją w pliki PrestaShop zawsze należy wykonać kopię zapasową. W tym przypadku minimalny zakres kopii to plik classes/Tools.php – pobierz go przez FTP na komputer lokalny przed edycją. Jeśli coś pójdzie nie tak podczas zapisu lub wgrywania, masz oryginalny plik pod ręką i możesz go natychmiast przywrócić. Dobrą praktyką jest również posiadanie aktualnej kopii całej bazy danych sklepu – niezależnie od wykonywanych prac technicznych.

Podsumowanie

Błędy XML w panelu administracyjnym PrestaShop 1.6 związane z plikami country_module_list.xml i must_have_modules_list.xml to klasyczny problem wynikający z niedostępności zewnętrznego API addons.prestashop.com dla tej wersji oprogramowania. Sklep pobiera HTML zamiast XML i nie potrafi go przetworzyć, zaśmiecając dashboard dziesiątkami komunikatów o błędach.

Rozwiązanie sprowadza się do dwóch prostych działań przez FTP: zmiany jednej wartości w classes/Tools.php z true na false oraz usunięcia dwóch uszkodzonych plików XML z katalogu /config/xml/. Wyłączenie mechanizmu addonsRequest nie wpływa na sprzedaż, SEO ani działanie zainstalowanych modułów – jedyna stracona funkcjonalność to wyświetlanie rekomendacji modułów z marketplace, z którego i tak mało kto korzysta w sklepach opartych na wersji 1.6.

Jeśli nie czujesz się pewnie przy edycji plików PHP lub wolisz zlecić to specjaliście, chętnie wykonam tę naprawę za Ciebie. Koszt usługi to 200 zł netto.

AJIT Adam Jasiński
Tel.: 728 658 005
E-mail: ajit@ajit.pl