PrestaShop: mapa paczkomatów InPost nie pokazuje się w koszyku. Dwie przyczyny

Jeśli po instalacji modułu paczkomatów InPost w PrestaShop koszyk nie pokazuje mapy, a blok z dodatkową zawartością przewoźnika jest pusty i ukryty, winny bywa motyw, nie moduł. W naszym przypadku zawiniły dwie rzeczy naraz: zahardkodowane ID przewoźnika i brakująca klasa CSS. Poniżej opisujemy, jak to rozpoznaliśmy i jak naprawiliśmy tak, żeby awaria nie wróciła po następnej edycji przewoźnika.

Dlaczego mapa paczkomatów nie pojawia się w koszyku?

Po przejściu ze starego modułu InPost na nowy (pminpostpaczkomaty w wersji 2.9.2) element listy przewoźnika renderował się, ale blok .carrier-extra-content był pusty i ukryty. Żadna z dwóch przyczyn z osobna nie tłumaczyła pełnego objawu. Dopiero naprawa obu przywróciła mapę.

Przyczyna 1: zahardkodowane ID przewoźnika

W pliku javascript.tpl motywu AngarTheme stały wartości starego modułu:

window.PACZKOMATY_ID = "#delivery-li-203";
window.PACZKOMATY_ID_DELIVERY = 203;

Nowy moduł używał przewoźnika o innym ID (183), więc querySelector zwracał null, a kod kończył się wczesnym return.

Przyczyna 2: brak klasy delivery-options w motywie

To była właściwa przyczyna pustego bloku. Moduł wstrzykuje widżet tak:

$('#' + t).closest('.delivery-options').append(value);

Motyw miał <div class="delivery-options-list"> i <ul id="shipping_method">, ale klasy .delivery-options nie było nigdzie. closest() zwracał pusty zbiór, a append() szedł w próżnię. Widżet powstawał i był wyrzucany. Test kontrolny w JSDOM potwierdził, że bez klasy closest() daje null, a z klasą widżet ląduje w koszyku.

Masz ten sam problem? Mapa paczkomatów znika w koszyku? Sprawdzimy motyw, moduł i dane przewoźników. Opisz sytuację →

Jak naprawić mapę paczkomatów, żeby nie znikała po edycji przewoźnika?

W shipping.tpl dodaliśmy brakującą klasę. Zero reguł CSS na .delivery-options w motywie, więc zmiana jest wizualnie neutralna:

<ul id="shipping_method" class="delivery-options">

W javascript.tpl zrobiliśmy przełącznik wariantów, z obiema implementacjami obok siebie, żeby w razie potrzeby wrócić do starego modułu:

window.INPOST_MAP_PROVIDER = 'pminpost';  // 'sensbit' = rollback

Moduł wstrzykuje widżet asynchronicznie, więc użyliśmy MutationObserver zamiast jednorazowego sprawdzenia. ID przewoźnika czytamy z wartości window.pm_inpostpaczkomaty_carrier*, które moduł przekazuje do JavaScriptu, zamiast wpisywać je na stałe.

Powód jest zasadniczy. PrestaShop nadaje nowe id_carrier przy każdej edycji przewoźnika, a stałe jest id_reference. Hardkod oznaczałby powtórkę tej samej awarii za kilka miesięcy.

Jakie pułapki kosztowały nas najwięcej czasu?

• Smarty parsuje klamrę w JavaScripcie, także w komentarzach. Zapis {childList: true, subtree: true} dawał błąd, a komentarz z {"1":"183"} też. Pomaga spacja po klamrze ({ childList: true }), bo Smarty ignoruje klamry ze spacją. Plik był poza blokiem literal, więc dotyczyło to każdego obiektu JS.
• array_filter w PHP zachowuje klucze. Przy dziurach json_encode daje obiekt {"1":"183"} zamiast tablicy, dlatego w JS użyliśmy Object.values().
• Inline display:none bloku .carrier-extra-content przebija reguła .show-inpost { display: block !important } z pliku CSS koszyka.

Weryfikację zrobiliśmy w JSDOM dla obu wariantów i ich izolacji, a także kompilacją szablonu Smarty w kontenerze produkcyjnym.

Który moduł naprawdę obsługuje przewoźników?

O tym, czy moduł jest aktywny w sklepie, rozstrzyga tabela ps_module_shop, nie kolumna active w ps_module. U nas realny ruch szedł jeszcze przez stary moduł, a nowy był w trakcie wdrożenia, więc przełącznik wariantów w JavaScripcie był potrzebny do bezpiecznego przejścia.

Nienaprawione w module. W ustawieniach lista metod dostawy pokazywała 6 z 17 przewoźników. Powód: Carrier::getCarriers() z domyślnym filtrem dokleja warunek c.is_module = 0. Poprawka to przekazanie filtru Carrier::ALL_CARRIERS, ale to kod modułu, który nadpisze się przy aktualizacji, więc lepiej zrobić to przez override.

Kiedy zlecić to specjalistom?

Gdy po zmianie modułu dostawy koszyk zachowuje się inaczej niż w dokumentacji, a w konsoli nie ma błędów. W ASAPDevs sprawdzamy motyw, moduł i dane przewoźników w ramach obsługi sklepów PrestaShop, a o płatności InPost w WooCommerce piszemy w artykule o InPost Pay w WooCommerce.

Źródła: dokumentacja deweloperska PrestaShop (klasy Cart, Carrier, OrderDetail); kod PrestaShop 1.7.8 użyty w diagnozie.