Jak wyłączyć CSS/JS modułu bez jego odinstalowywania

Problem: potrzebujesz modułu, ale nie jego zasobów na każdej stronie

Istnieje wiele sytuacji, w których chcesz zachować moduł PrestaShop zainstalowany i aktywny, ale zapobiec ładowaniu jego plików CSS lub JavaScript na konkretnych stronach, a nawet na wszystkich stronach. Być może masz moduł, którego funkcjonalność jest Ci potrzebna, ale którego stylizacja koliduje z Twoim szablonem. Być może moduł ładuje ciężką bibliotekę JavaScript, którą już dołączyłeś przez swój szablon. Być może chcesz zastąpić domyślne style modułu własnym niestandardowym CSS bez ingerencji oryginalnych stylów. Lub być może zidentyfikowałeś w audycie wydajności, że moduł ładuje zasoby na stronach, gdzie nie ma żadnego widocznego wyniku, i chcesz wyeliminować to marnotrawstwo.

Odinstalowanie modułu nie wchodzi w grę, ponieważ potrzebujesz jego podstawowej funkcjonalności: jego hooków, tabel bazy danych, konfiguracji, funkcji panelu administracyjnego. Musisz jedynie chirurgicznie usunąć konkretne pliki CSS lub JavaScript z wyjścia front office. PrestaShop zapewnia kilka mechanizmów do osiągnięcia tego celu, a ten artykuł omawia je wszystkie szczegółowo, od najprostszych po najbardziej zaawansowane.

Metoda 1: Używanie Theme.yml do usuwania zasobów modułu

Najprostszym i najłatwiejszym w utrzymaniu sposobem usunięcia CSS lub JavaScript modułu w PrestaShop 1.7 i nowszych jest plik konfiguracyjny szablonu, theme.yml. Ten plik, znajdujący się w katalogu głównym Twojego szablonu, kontroluje, które zasoby szablon ładuje i które zasoby modułów usuwa.

Otwórz swój plik theme.yml i poszukaj sekcji assets. Jeśli nie istnieje, możesz ją utworzyć. W sekcji assets możesz określić pliki CSS i JavaScript do usunięcia po ich identyfikatorze zasobu (asset ID). Każdy zasób zarejestrowany przez registerStylesheet lub registerJavascript ma identyfikator, który zazwyczaj składa się z nazwy modułu i opisowego sufiksu.

Aby znaleźć identyfikatory zasobów używane przez moduł, sprawdź kod źródłowy strony i poszukaj znaczników link arkuszy stylów oraz elementów skryptów. PrestaShop dodaje atrybut id do tych elementów w trybie debugowania, lub możesz znaleźć identyfikatory w kodzie źródłowym modułu, gdzie wywołuje registerStylesheet lub registerJavascript.

W pliku theme.yml dodaj sekcję pod assets, następnie css, następnie all. Dodaj wpis z identyfikatorem zasobu i ustaw go na false. Na przykład, jeśli moduł rejestruje arkusz stylów z identyfikatorem modulename-style, dodałbyś modulename-style z wartością false pod sekcją css all. Zrób to samo dla plików JavaScript pod sekcją js all.

Po modyfikacji theme.yml musisz wyczyścić pamięć podręczną PrestaShop z poziomu Zaawansowane parametry, Wydajność. Zmiany w theme.yml wchodzą w życie po przebudowaniu pamięci podręcznej. To podejście utrzymuje się mimo aktualizacji modułów, ponieważ usunięcie jest zdefiniowane w Twoim szablonie, nie w samym module. Jednak usuwa zasoby ze wszystkich stron. Jeśli potrzebujesz zasobów na niektórych stronach, ale nie na innych, będziesz potrzebować bardziej ukierunkowanego podejścia.

Metoda 2: Media::unregisterStylesheet i Media::unregisterJavascript

PrestaShop 1.7 wprowadził metody klasy Media — unregisterStylesheet i unregisterJavascript — które pozwalają programistycznie usuwać konkretne zasoby zarejestrowane przez inne moduły. Te metody są potężne, ponieważ możesz wywoływać je warunkowo, usuwając zasoby tylko na konkretnych stronach, zachowując je na innych.

Aby skorzystać z tego podejścia, potrzebujesz niestandardowego modułu lub modyfikacji istniejącego modułu. W metodzie hookActionFrontControllerSetMedia swojego modułu wywołaj Media::unregisterStylesheet z identyfikatorem zasobu pliku CSS, który chcesz usunąć. Podobnie wywołaj Media::unregisterJavascript z identyfikatorem zasobu pliku JavaScript. Możesz opakować te wywołania w logikę warunkową, aby usuwać zasoby tylko na konkretnych typach stron.

Na przykład, jeśli chcesz usunąć zasoby modułu slidera z każdej strony oprócz strony głównej, sprawdziłbyś, czy bieżący kontroler to IndexController. Jeśli to nie strona główna, wywołujesz metody unregister. Jeśli to strona główna, nie robisz nic i pozwalasz zasobom ładować się normalnie.

Kluczową kwestią w tym podejściu jest kolejność wykonywania hooków. Twoja metoda hookActionFrontControllerSetMedia musi wykonać się po module, którego zasoby chcesz usunąć. PrestaShop wykonuje callbacki hooków w kolejności rejestracji modułów na hooku, co możesz kontrolować przez stronę Wygląd, Pozycje w panelu administracyjnym. Przesuń swój niestandardowy moduł poniżej docelowego modułu na hooku actionFrontControllerSetMedia, aby zapewnić, że Twoje wywołania unregister następują po zarejestrowaniu zasobów przez docelowy moduł.

Jeśli problematyczny moduł używa starszych metod addCSS i addJS zamiast registerStylesheet i registerJavascript, metody unregister mogą nie zadziałać, ponieważ starsze metody nie korzystają z tego samego systemu zarządzania zasobami. W takim przypadku potrzebujesz innego podejścia.

Metoda 3: Niestandardowy moduł do blokowania konkretnych zasobów

Gdy potrzebujesz precyzyjnej kontroli nad tym, które zasoby ładują się na których stronach, stworzenie dedykowanego modułu zarządzania zasobami jest najbardziej elastycznym rozwiązaniem. Ten moduł działa jako centralne miejsce, w którym definiujesz reguły blokowania lub zezwalania na konkretne zasoby modułów.

Utwórz nowy moduł z metodą hookActionFrontControllerSetMedia. Wewnątrz tej metody zdefiniuj tablicę reguł zasobów. Każda reguła określa nazwę modułu, identyfikatory zasobów do zablokowania oraz warunki, w których je blokować. Warunki mogą być oparte na nazwie kontrolera, typie strony lub dowolnych innych kryteriach dostępnych w kontekście PrestaShop.

Twój moduł iteruje przez reguły przy każdym ładowaniu strony, sprawdza warunki i wywołuje Media::unregisterStylesheet lub Media::unregisterJavascript dla każdego zasobu, który powinien być zablokowany na bieżącej stronie. To scentralizowane podejście jest znacznie łatwiejsze w utrzymaniu niż rozpraszanie logiki usuwania zasobów po wielu modułach lub plikach szablonów.

Możesz ulepszyć ten moduł o stronę konfiguracji w panelu administracyjnym, która pozwala zarządzać regułami przez interfejs administratora PrestaShop zamiast edytować kod. Prosty formularz z polami na nazwę modułu, identyfikator zasobu i multiselect dla typów stron, na których zasób powinien być zablokowany, daje Ci przyjazny dla użytkownika sposób zarządzania ładowaniem zasobów bez dotykania kodu po początkowej konfiguracji.

To podejście działa zarówno z nowym systemem registerStylesheet, jak i ze starszym systemem addCSS, choć możesz potrzebować różnych technik dla każdego z nich. Dla zasobów zarejestrowanych nowym systemem użyj metod Media::unregister. Dla zasobów dodanych starszym systemem możesz bezpośrednio manipulować tablicami css_files i js_files kontrolera w metodzie hookActionFrontControllerSetMedia.

Metoda 4: Podejście z odpinaniem hooków

Bardziej agresywnym, ale czasami koniecznym podejściem jest całkowite odpięcie modułu od hooków, na których rejestruje swoje zasoby. Przejdź do Wygląd, następnie Pozycje w panelu administracyjnym. Znajdź moduł na hooku displayHeader lub actionFrontControllerSetMedia. Kliknij przycisk usunięcia lub odpięcia, aby usunąć moduł z tego hooka całkowicie.

To zapobiega ładowaniu jakichkolwiek zasobów przez moduł na jakiejkolwiek stronie. Inne hooki modułu, takie jak displayProductAdditionalInfo czy displayFooter, nadal działają normalnie. Jednak wyjście front office modułu może się zepsuć, jeśli zależy od swojego CSS do stylizacji lub JavaScript do interaktywnego zachowania.

To podejście jest najbardziej przydatne, gdy planujesz całkowicie zastąpić stylizację modułu własnym niestandardowym CSS. Odpinasz moduł od displayHeader, aby zapobiec ładowaniu jego CSS, a następnie piszesz własne style w niestandardowym pliku CSS szablonu, celując w elementy HTML modułu. To daje Ci pełną kontrolę nad wyglądem modułu bez żadnego konfliktu między oryginalnymi stylami a Twoimi modyfikacjami.

W przypadku JavaScript odpinanie jest bardziej ryzykowne. Jeśli moduł polega na swoim JavaScript do podstawowej funkcjonalności, takiej jak wywołania AJAX, walidacja formularzy lub dynamiczne ładowanie treści, usunięcie JavaScript zepsuje te funkcje. Odpinaj JavaScript tylko wtedy, gdy masz pewność, że wyjście front office modułu od niego nie zależy, lub jeśli zapewniasz zastępczą implementację przez swój szablon.

Ważne zastrzeżenie: jeśli zaktualizujesz moduł, proces aktualizacji może ponownie zarejestrować moduł na hookach, z których go usunąłeś. Po każdej aktualizacji modułu sprawdź Wygląd, Pozycje, aby potwierdzić, że Twoje odpięcie nadal obowiązuje. Niektóre moduły jawnie rejestrują swoje hooki podczas procesu aktualizacji, co nadpisuje Twoje ręczne odpięcie.

Metoda 5: Nadpisywanie zasobów modułu przez szablon

System szablonów PrestaShop pozwala nadpisywać pliki szablonów modułów, umieszczając je w katalogu modules Twojego szablonu. Choć jest to głównie używane do nadpisywania szablonów, możesz to również wykorzystać do pośredniej kontroli ładowania zasobów.

Jeśli moduł ładuje swoje zasoby przez pliki szablonów za pomocą funkcji Smarty, takich jak znaczniki skryptów lub arkuszy stylów bezpośrednio w plikach TPL, zamiast przez hooki PHP, możesz nadpisać te szablony w swoim szablonie i usunąć odniesienia do zasobów. Skopiuj plik szablonu modułu do katalogu modules swojego szablonu, zachowując tę samą strukturę katalogów, i edytuj kopię, aby usunąć niechciane odniesienia do CSS lub JavaScript.

To podejście jest specyficzne dla szablonu, co oznacza, że wpływa tylko na bieżący szablon. Jeśli zmienisz szablon, nadpisania nie zostaną przeniesione. Wymaga również utrzymania: gdy moduł aktualizuje swoje szablony, musisz zaktualizować swoje nadpisania, aby dopasować wszelkie zmiany strukturalne, zachowując jednocześnie swoje modyfikacje usuwania zasobów.

Dla modułów ładujących zasoby przez hooki PHP, a nie szablony, nadpisania szablonów nie pomagają w blokowaniu zasobów. W takim przypadku użyj jednej z innych metod opisanych w tym artykule.

PrestaShop 1.7 vs 8.x: różnice w podejściu

PrestaShop 8.x udoskonalił system zarządzania zasobami wprowadzony w wersji 1.7, ale fundamentalne podejścia pozostają takie same. Główne różnice dotyczą wewnętrznej implementacji i kilku dodatkowych funkcji.

W PrestaShop 1.7 system zarządzania zasobami wykorzystuje registerStylesheet i registerJavascript z systemem priorytetów. Metody Media::unregisterStylesheet i Media::unregisterJavascript działają niezawodnie dla zasobów zarejestrowanych przez ten system. Jednak moduły, które nadal używają starszych metod addCSS i addJS (które są przestarzałe, ale wciąż funkcjonalne), nie przechodzą przez nowy system zarządzania zasobami, co utrudnia ich czyste usunięcie.

PrestaShop 8.x poprawił wsteczną kompatybilność, dzięki czemu nawet zasoby dodane starszymi metodami są przetwarzane przez nowy potok zasobów. Oznacza to, że metody Media::unregister działają bardziej spójnie we wszystkich modułach, niezależnie od użytej metody rejestracji. Jeśli korzystasz z PrestaShop 8.x, podejście z unregister jest najbardziej niezawodną metodą dla wszystkich modułów.

PrestaShop 8.x wprowadził również lepsze unieważnianie pamięci podręcznej zasobów (cache-busting), co oznacza, że gdy usuwasz lub modyfikujesz zasoby, zmiany wchodzą w życie natychmiast po wyczyszczeniu pamięci podręcznej, bez klientów widzących przestarzałe wersje z cache. W PrestaShop 1.7 czasami trzeba było wyczyścić zarówno pamięć podręczną PrestaShop, jak i pamięć podręczną przeglądarki, lub poczekać na ponowne wygenerowanie połączonych plików przez system Combine, Compress, Cache (CCC).

Obie wersje obsługują podejście z theme.yml do usuwania zasobów, a składnia jest identyczna. Jeśli piszesz niestandardowy moduł do zarządzania zasobami, ten sam kod działa zarówno na 1.7, jak i 8.x z minimalnymi różnicami.

Pomiar zysków wydajności po wyłączeniu zasobów

Po wyłączeniu zasobów modułu powinieneś zmierzyć poprawę wydajności, aby potwierdzić, że Twoje zmiany przyniosły oczekiwany efekt. Użyj kombinacji narzędzi do kompleksowego pomiaru.

Zacznij od zakładki Sieć (Network) w Chrome DevTools. Porównaj łączną liczbę żądań i łączny przesłany rozmiar przed i po zmianach. Filtruj po CSS i JS, aby zobaczyć konkretną redukcję w liczbie i rozmiarach plików arkuszy stylów i JavaScript. Znacząca optymalizacja powinna wykazać wyraźną redukcję zarówno liczby żądań, jak i łącznego rozmiaru.

Uruchom audyt wydajności Lighthouse przed i po zmianach. Skup się na metrykach najbardziej dotkniętych przez ładowanie CSS i JavaScript: First Contentful Paint jest wpływany przez CSS blokujący renderowanie, Largest Contentful Paint jest wpływany przez ogólne ładowanie zasobów, a Total Blocking Time jest wpływany przez parsowanie i wykonywanie JavaScript. Zapisz te metryki z co najmniej trzech uruchomień i porównaj średnie.

Użyj zakładki Coverage w Chrome DevTools do mierzenia wykorzystania CSS i JavaScript. Otwórz zakładkę Coverage z menu trzech kropek pod Więcej narzędzi, następnie przeładuj stronę. Zakładka Coverage pokazuje, ile z każdego pliku CSS i JavaScript jest faktycznie używane na bieżącej stronie. Pliki z wysokim procentem nieużywanego kodu (pokazane na czerwono) są kandydatami do usunięcia lub warunkowego ładowania. Po wyłączeniu zasobów modułu pozostałe pliki powinny wykazywać wyższe procenty wykorzystania, co wskazuje, że pomyślnie usunąłeś marnotrawstwo.

Rozważ również metryki z rzeczywistego ruchu z Twojej platformy analitycznej. Jeśli korzystasz z Google Analytics lub podobnego narzędzia, porównaj czasy ładowania stron za tydzień przed i po optymalizacji. Dane z rzeczywistego ruchu od prawdziwych odwiedzających na różnych urządzeniach i w różnych warunkach sieciowych dają Ci najbardziej dokładny obraz poprawy wydajności.

Ryzyka i kwestie kompatybilności

Wyłączanie zasobów modułu niesie ze sobą ryzyka, które musisz zrozumieć i zarządzać. Najczęstszym ryzykiem jest psucie się wyglądu wizualnego. Gdy usuniesz CSS modułu, jego elementy HTML tracą stylizację i mogą wyświetlać się nieprawidłowo. Może to obejmować drobne problemy kosmetyczne, takie jak złe kolory lub odstępy, po poważne problemy z układem, takie jak nakładające się elementy lub niewidoczna treść.

Usuwanie JavaScript niesie wyższe ryzyko. Nowoczesne moduły często polegają na swoim JavaScript do podstawowej funkcjonalności. Usunięcie JavaScript może spowodować, że funkcje przestaną działać całkowicie: przyciski niereagrujące na kliknięcia, formularze niewykonujące wysyłki, popupy nieotwierające się, treść AJAX nieładująca się. Zawsze testuj każdą funkcję modułu po usunięciu jego JavaScript.

Istnieje również ryzyko kompatybilności z aktualizacjami modułu. Gdy moduł jest aktualizowany, deweloper może dodać nowe pliki CSS lub JavaScript z innymi identyfikatorami zasobów. Twoje reguły usuwania, czy to w theme.yml, czy w niestandardowym module, mogą nie przechwycić nowych zasobów, ponieważ celują w stare identyfikatory. Po każdej aktualizacji modułu zweryfikuj, że Twoje blokowanie zasobów nadal działa poprawnie i w razie potrzeby zaktualizuj reguły.

Niektóre moduły wykonują detekcję funkcji w swoim JavaScript i zachowują się inaczej, gdy ich CSS nie jest załadowany. Moduł może sprawdzać istnienie konkretnych klas CSS lub obliczonych stylów przed inicjalizacją swojej funkcjonalności JavaScript. Usunięcie CSS w tym przypadku nie tylko zmienia wygląd, ale również psuje zachowanie JavaScript zależne od tych stanów zdefiniowanych przez CSS.

Na koniec zwróć uwagę na zależności między modułami. Moduł A może ładować bibliotekę JavaScript, taką jak plugin lightbox, którą Moduł B również używa, ale nie ładuje samodzielnie, ponieważ zakłada, że Moduł A ją zapewnia. Usunięcie plików JavaScript Modułu A zepsułoby oba moduły w tym scenariuszu. Sprawdź współdzielone zależności przed usunięciem jakichkolwiek zasobów.

Praktyczny przebieg bezpiecznego usuwania zasobów

Postępuj zgodnie z tym przebiegiem, aby bezpiecznie wyłączyć zasoby modułu bez psucia sklepu. Po pierwsze, udokumentuj swój aktualny stan. Zrób zrzuty ekranu każdego typu strony, na którym moduł wyświetla treść. Zapisz wyniki Lighthouse i statystyki z zakładki Sieć. To daje Ci punkt odniesienia do porównania i referencję tego, jak moduł powinien wyglądać i funkcjonować.

Po drugie, zidentyfikuj konkretne zasoby, które chcesz usunąć. Użyj DevTools do znalezienia dokładnych nazw plików i identyfikatorów zasobów. Określ, które strony potrzebują zasobów, a które nie.

Po trzecie, wdróż usunięcie używając najbardziej odpowiedniej metody z tego artykułu. Dla prostego globalnego usunięcia użyj theme.yml. Dla warunkowego usunięcia opartego na typie strony utwórz niestandardowy moduł z wywołaniami Media::unregister. Dla pełnej wymiany zasobów odpnij moduł i dostarcz własne style.

Po czwarte, testuj dokładnie. Sprawdź każdy typ strony, na którym moduł powinien wyświetlać treść. Zweryfikuj, że wygląd wizualny modułu jest prawidłowy i wszystkie interaktywne funkcje działają. Sprawdź strony, na których usunąłeś zasoby, aby potwierdzić, że nie są już ładowane. Testuj na wielu przeglądarkach i urządzeniach.

Po piąte, zmierz poprawę wydajności. Uruchom audyty Lighthouse i porównaj z bazowym pomiarem. Sprawdź zakładkę Sieć pod kątem zmniejszonej liczby żądań i rozmiarów. Jeśli poprawa jest znacząca, Twoja optymalizacja była udana. Jeśli poprawa jest minimalna, usunięte zasoby mogły nie być głównym wąskim gardłem wydajności i powinieneś zbadać inne możliwości optymalizacji.

Po szóste, udokumentuj swoje zmiany. Zapisz, które zasoby usunąłeś, jakiej metody użyłeś i które strony są dotknięte. Ta dokumentacja jest niezbędna do rozwiązywania przyszłych problemów, szczególnie po aktualizacjach modułów, oraz do przekazywania wiedzy, jeśli ktoś inny będzie utrzymywał sklep.

Stosując to systematyczne podejście, możesz bezpiecznie zmniejszyć wagę stron swojego sklepu i poprawić czasy ładowania bez poświęcania funkcjonalności modułów, na których Twój sklep polega. Kluczem jest zawsze testowanie i pomiar: nigdy nie zakładaj, że usunięcie zasobu jest bezpieczne, i zawsze weryfikuj wyniki konkretnymi danymi.