Struktura folderów PrestaShop: co robi każdy katalog i kiedy jest potrzebny

Zweryfikowano dla PrestaShop 1.6, 1.7, 8.x i 9.x. Poniższe katalogi istnieją we wszystkich tych wersjach; główna różnica polega na tym, ile elementów przeniesiono do /src/ (Symfony) oraz na tym, że PrestaShop 9 jest dostarczany z motywem Hummingbird zamiast Classic. Różnice zależne od wersji są wskazane w tabelach na końcu.

Dlaczego warto rozumieć strukturę folderów

PrestaShop to duża aplikacja. Typowa instalacja zawiera ponad 30 000 plików rozmieszczonych w setkach katalogów. Większość właścicieli sklepów nigdy nie musi zaglądać do systemu plików. Jeśli jednak tworzysz moduły, dostosowujesz motywy, diagnozujesz problemy albo zarządzasz własnym serwerem, wiedza o tym, za co odpowiada dany katalog, oszczędza godziny szukania i pomaga uniknąć kosztownych błędów.

Ten przewodnik opisuje najważniejsze katalogi w instalacji PrestaShop 1.7.x, 8.x lub 9.x. Zaczynamy od folderów, z którymi będziesz pracować najczęściej, a potem przechodzimy do tych, które najlepiej zostawić w spokoju.

/modules/ -- Serce personalizacji PrestaShop

To katalog, z którym będziesz mieć najwięcej kontaktu. Każdy moduł, zainstalowany z marketplace, wgrany jako ZIP albo napisany na zamówienie, znajduje się tutaj jako osobny podkatalog.

modules/
  ps_emailsubscription/       -- PrestaShop native module
  mprcheckoutrevolution/      -- third-party module
  mymodule/                   -- your custom module
    mymodule.php              -- main module file (required)
    config.xml                -- cached module metadata
    views/
      templates/              -- Smarty templates
      css/                    -- stylesheets
      js/                     -- JavaScript
    controllers/
      front/                  -- front office controllers
      admin/                  -- admin controllers
    sql/                      -- install/upgrade SQL
    upgrade/                  -- version upgrade scripts
    translations/             -- translation files
    vendor/                   -- Composer dependencies

Najważniejsze zasady:

• Główny plik PHP musi mieć dokładnie taką samą nazwę jak katalog: modules/mymodule/mymodule.php
• Nazwa klasy w środku również musi się zgadzać: class Mymodule extends Module
• Nigdy nie edytuj natywnych modułów PS (z prefiksem ps_) -- aktualizacje nadpiszą Twoje zmiany. Zamiast tego użyj hooków, override’ów albo nadpisywania szablonów w motywie
• Pliki modułu muszą należeć do użytkownika serwera WWW (www-data w większości konfiguracji Linuksa), aby wgrywanie plików i generowanie cache działały poprawnie

Kiedy potrzebujesz tego katalogu: Instalowanie modułów, tworzenie modułów, diagnozowanie problemów z modułami, sprawdzanie, które moduły są zainstalowane, przeglądanie kodu źródłowego modułów.

/themes/ -- Wygląd i szablony

Cały wizualny efekt widoczny w sklepie kontrolują motywy. Każdy motyw jest osobnym podkatalogiem zawierającym szablony, zasoby i konfigurację.

themes/
  classic/                    -- PS default theme (1.7/8)
    config/theme.yml          -- theme metadata, asset registration
    templates/                -- Smarty .tpl files
      catalog/                -- product, category pages
      checkout/               -- cart, checkout flow
      cms/                    -- CMS pages
      customer/               -- account pages
      _partials/              -- header, footer, notifications
      layouts/                -- page layout wrappers
    assets/
      css/                    -- compiled CSS
      js/                     -- compiled JS
      img/                    -- theme images (icons, placeholders)
    modules/                  -- module template overrides
  hummingbird/                -- PS 9 default theme
  my-child-theme/             -- your child theme

Najważniejsze zasady:

• Nigdy nie edytuj motywu nadrzędnego bezpośrednio. Utwórz motyw potomny, który dziedziczy po motywie nadrzędnym, i nadpisuj tylko to, co faktycznie zmieniasz.
• Aktywny motyw ustawisz w panelu administracyjnym: Panel administracyjny > Wygląd > Motyw & logo
• modules/ wewnątrz motywu ma pierwszeństwo przed własnymi szablonami modułu -- właśnie w ten sposób motywy dostosowują wygląd modułów
• PrestaShop 9 używa Hummingbird (Bootstrap 5, warstwy CSS). PrestaShop 1.7/8 używa Classic (Bootstrap 4).

Kiedy potrzebujesz tego katalogu: Dostosowywanie wyglądu sklepu, tworzenie motywów potomnych, nadpisywanie szablonów modułów, diagnozowanie problemów z szablonami.

/config/ -- Pliki konfiguracyjne

Podstawowa konfiguracja, którą PrestaShop odczytuje przy każdym żądaniu.

config/
  config.inc.php              -- NEVER EDIT: auto-generated, loads settings.inc.php
  settings.inc.php            -- database credentials, cookie key, PS version
  defines.inc.php             -- path constants, debug flags
  smarty.config.inc.php       -- Smarty template engine configuration
  autoload.php                -- Composer autoloader bootstrap

Najważniejsze pliki:

• settings.inc.php -- Zawiera host bazy danych, nazwę bazy, użytkownika, hasło oraz klucz szyfrowania cookie. Ten plik jest generowany podczas instalacji. Zrób jego kopię zapasową. Jeśli stracisz klucz cookie, wszystkie istniejące sesje klientów i pracowników staną się nieważne.
• defines.inc.php -- Miejsce, w którym włączasz tryb debugowania: ustaw _PS_MODE_DEV_ na true dla środowiska deweloperskiego (pokazuje błędy), a na false dla produkcji. Zawiera też _PS_CACHE_ENABLED_ oraz inne flagi działania aplikacji.

Jedna rzecz często zaskakuje użytkowników PrestaShop 8 i 9: plik settings.inc.php może nie istnieć. Nowsze instalacje przechowują te same dane dostępowe w app/config/parameters.php, wygenerowanym przez instalator. Jeśli szukasz połączenia z bazą danych, a brakuje config/settings.inc.php, zajrzyj do app/config/parameters.php, to współczesne miejsce dla tych samych wartości.

Kiedy potrzebujesz tego katalogu: Konfigurowanie nowej instalacji, zmiana danych dostępowych do bazy danych, włączanie trybu debugowania, rozwiązywanie problemów z połączeniem.

/var/ -- Cache, logi i pliki tymczasowe

Dane robocze PrestaShop. Ten katalog rośnie z czasem; jego cache należy czyścić przez panel administracyjny lub konsolę, zachowując potrzebne logi.

var/
  cache/
    prod/                     -- production cache
      smarty/
        compile/              -- compiled Smarty templates
        cache/                -- Smarty output cache
      ContainerProdDebugProjectContainer.php  -- Symfony DI container
    dev/                      -- development cache (when _PS_MODE_DEV_ = true)
  logs/
    prod.log                  -- Symfony/PS error logs
    dev.log                   -- development mode logs

Najważniejsze operacje:

• Czyszczenie cache: Parametry zaawansowane > Wydajność > Wyczyść cache.
• Alternatywnie: php bin/console cache:clear --env=prod
• Katalog kompilacji Smarty przechowuje wstępnie skompilowane szablony. Jeśli zmiana w szablonie się nie pojawia, usuń var/cache/prod/smarty/compile/*
• Sprawdź logi: var/logs/prod.log to pierwsze miejsce, do którego warto zajrzeć, gdy coś przestaje działać. Zawiera błędy PHP, wyjątki Symfony i błędy modułów.

W PrestaShop 9 trzeba zachować szczególną ostrożność: panel administracyjny jest aplikacją Symfony z własnym wygenerowanym kontenerem w var/cache/prod/admin. Ślepe wykonanie rm -rf var/cache/prod/* na działającym sklepie PS 9 może zostawić panel administracyjny z niekompletnym kontenerem i powodować błędy 500 na stronie logowania, dopóki cache panelu nie zostanie odbudowany. W PS 9 lepiej użyć konsoli (php bin/console cache:clear --env=prod) zamiast ręcznego usuwania, a czyszczenie wykonać jako użytkownik serwera WWW, aby odtworzone pliki miały właściwego właściciela.

Kiedy potrzebujesz tego katalogu: Czyszczenie cache po zmianach, diagnozowanie błędów przez logi, zwalnianie miejsca na małych serwerach.

/classes/ -- Główna logika biznesowa (legacy)

Oryginalny model obiektowy PrestaShop. Każdy plik jest klasą PHP reprezentującą encję biznesową albo narzędzie.

classes/
  Product.php                 -- Product entity (attributes, prices, stock)
  Category.php                -- Category entity
  Cart.php                    -- Shopping cart logic
  Order.php                   -- Order entity
  Customer.php                -- Customer entity
  Module.php                  -- Base module class (install, hooks, config)
  Tools.php                   -- Utility functions (redirect, getValue, etc.)
  Db.php                      -- Database abstraction
  ObjectModel.php             -- Base ORM class
  shop/
    Shop.php                  -- Multi-shop logic
  tax/
    Tax.php                   -- Tax calculation
  stock/
    StockAvailable.php        -- Stock management

Najważniejsze zasady:

• Nigdy nie edytuj tych plików bezpośrednio. Jeśli musisz zmienić zachowanie rdzenia, użyj mechanizmu /override/classes/ (ale override’y mają własne problemy -- lepiej wybierać hooki i moduły).
• W PS 1.7+ wiele z tych klas jest stopniowo zastępowanych usługami Symfony w /src/. Oba systemy współistnieją.
• ObjectModel to klasa bazowa dla wszystkich encji. Jej zrozumienie jest kluczowe przy tworzeniu modułów -- zapewnia add(), update(), delete(), getFields() i walidację.

Kiedy potrzebujesz tego katalogu: Zrozumienie, jak PrestaShop wylicza ceny, zarządza stanami magazynowymi i przetwarza zamówienia. Czytanie (nie edytowanie) tych plików to sposób na poznanie wewnętrznego API.

/controllers/ -- Obsługa żądań

Kontrolery przetwarzają żądania HTTP i renderują strony. PrestaShop ma dwa zestawy: dla sklepu oraz dla panelu administracyjnego.

controllers/
  front/
    ProductController.php     -- product page
    CategoryController.php     -- category listing
    CartController.php        -- cart operations
    OrderController.php       -- checkout steps
    CmsController.php         -- CMS pages
    SearchController.php      -- search results
  admin/
    AdminProductsController.php
    AdminOrdersController.php
    AdminCustomersController.php

Najważniejsze zasady:

• Kontrolery sklepu rozszerzają FrontController. Kontrolery panelu administracyjnego rozszerzają AdminController.
• W PS 1.7+ kontrolery panelu administracyjnego są migrowane do Symfony (w /src/PrestaShopBundle/Controller/). Część stron administracyjnych używa nowych kontrolerów Symfony, a część nadal korzysta ze starszych kontrolerów znajdujących się tutaj. Oba rozwiązania współistnieją.
• Kontrolery modułów znajdują się w modules/yourmodule/controllers/, nie tutaj.

Kiedy potrzebujesz tego katalogu: Zrozumienie działania konkretnej strony, diagnozowanie problemów na poziomie strony, sprawdzanie, które hooki są dostępne na danej stronie (kontrolery wywołują Hook::exec()).

/src/ -- Warstwa Symfony (PS 1.7+)

Nowoczesna warstwa architektury. Od wersji 1.7 PrestaShop stopniowo przechodzi ze starszego wzorca /classes/ + /controllers/ na Symfony.

src/
  Adapter/                    -- bridges between legacy and Symfony
  Core/
    Domain/                   -- CQRS commands and queries
      Product/
        Command/              -- CreateProduct, UpdateProduct, etc.
        Query/                -- GetProductForEditing, etc.
    Grid/                     -- admin list/grid definitions
    Form/                     -- admin form definitions
  PrestaShopBundle/
    Controller/               -- Symfony admin controllers
    Entity/                   -- Doctrine entities
    Form/                     -- Form types
    Translation/              -- Translation system
    Twig/                     -- Twig extensions for admin

Najważniejsze zasady:

• Ten katalog rośnie z każdą wersją PS, ponieważ kolejne funkcje są przenoszone do Symfony
• Warstwa Adapter/ jest krytyczna -- opakowuje klasy legacy, aby mogły z nich korzystać usługi Symfony
• W PS 9 większość stron administracyjnych jest już w pełni oparta na Symfony. W PS 1.7/8 to mieszanka legacy i Symfony.
• Twórcy modułów rzadko muszą cokolwiek tutaj modyfikować -- korzystają z tej warstwy przez usługi Symfony zarejestrowane w pliku services.yml własnego modułu

Kiedy potrzebujesz tego katalogu: Zaawansowane tworzenie modułów z użyciem usług Symfony, zrozumienie wzorca CQRS dla zarządzania produktami i zamówieniami w PS 8+, kontrybuowanie do rdzenia PrestaShop.

/override/ -- System override’ów

Mechanizm PrestaShop do modyfikowania zachowania rdzenia bez edytowania plików rdzenia.

override/
  classes/
    Product.php               -- overrides classes/Product.php
    Cart.php                  -- overrides classes/Cart.php
  controllers/
    front/
      ProductController.php   -- overrides controllers/front/ProductController.php
    admin/
      AdminProductsController.php

Najważniejsze zasady:

• Klasy override rozszerzają oryginał i nadpisują konkretne metody
• Możliwy jest tylko jeden override dla jednej klasy. Jeśli dwa moduły próbują nadpisać tę samą klasę, wygra tylko ostatni. Dlatego override’y są kruche -- w aktywnych sklepach konflikty modułów są praktycznie gwarantowane.
• Po dodaniu lub usunięciu override’ów odtwórz indeks klas: usuń var/cache/prod/class_index.php i wyczyść cache
• PS 9 oznacza system override’ów jako przestarzały. W nowym kodzie preferuj hooki, dekorowanie usług Symfony albo komendy CQRS.
• Override’y potrafią powodować tajemnicze błędy, które trudno namierzyć. Podczas diagnozowania nietypowego zachowania zawsze sprawdź override/.

Kiedy potrzebujesz tego katalogu: W ostateczności, gdy hooki nie dają potrzebnej kontroli. Zawsze preferuj hooki i rozwiązania oparte na modułach. Pełny obraz znajdziesz w naszym materiale Hooki & override’y.

/img/ -- Obrazy produktów i treści

img/
  p/                          -- product images (organized by ID digits)
    1/2/3/                    -- product ID 123's images
      123.jpg                 -- original
      123-home_default.jpg    -- resized for homepage
      123-large_default.jpg   -- resized for product page
  c/                          -- category images
  m/                          -- manufacturer/brand logos
  s/                          -- supplier logos
  cms/                        -- CMS page images (uploaded via editor)
  l/                          -- language flag icons
  tmp/                        -- temporary uploads

Najważniejsze zasady:

• Obrazy produktów są przechowywane w ścieżce wyprowadzonej z cyfr ID produktu: produkt 123 → img/p/1/2/3/. Dzięki temu pliki są rozkładane między katalogami, co pozwala uniknąć limitów systemu plików.
• Regeneracja obrazów (panel administracyjny > Wygląd > Ustawienia obrazów > Regeneruj) odtwarza wszystkie pomniejszone wersje z oryginałów. Przy dużych katalogach może to potrwać wiele godzin.
• Zrób kopię zapasową tego katalogu. Obrazów produktów nie da się zregenerować, jeśli oryginały zostaną utracone.
• Wersje WebP są generowane obok JPG/PNG w PS 8+, gdy ta opcja jest włączona.

Kiedy potrzebujesz tego katalogu: Diagnozowanie brakujących obrazów produktów, sprawdzanie jakości obrazów, masowe operacje na obrazach, migracja serwera (często jest to największy katalog pod względem liczby plików).

/app/ -- Kernel aplikacji Symfony

app/
  AppKernel.php               -- Symfony kernel, registers bundles
  config/
    config.yml                -- Symfony service configuration
    parameters.php -- wygenerowana konfiguracja; nowsze instalacje przechowują tutaj dane dostępowe.
    routing.yml               -- URL routing definitions
    security.yml              -- authentication/authorization
    services.yml              -- service container definitions

Najważniejsze zasady:

• AppKernel.php to punkt wejścia dla części PrestaShop opartej na Symfony. Rejestruje wszystkie bundle, w tym bundle modułów.
• config/routing.yml definiuje wzorce adresów URL panelu administracyjnego. Trasy administracyjne modułów są rejestrowane osobno przez własne pliki routingu modułu.
• W PS 9 kernel został znacząco przebudowany. Generowanie parameters.php może się różnić.

Kiedy potrzebujesz tego katalogu: Zaawansowane diagnozowanie routingu Symfony, problemów z kontenerem usług albo uwierzytelnianiem. Większość programistów nigdy nie dotyka go bezpośrednio.

/translations/ -- Pliki tłumaczeń rdzenia

translations/
  default/                    -- default English strings
  en-US/                      -- US English
  fr-FR/                      -- French
  de-DE/                      -- German
    ShopTheme.fr-FR.xlf       -- front office translations
    AdminNavigation.fr-FR.xlf -- admin menu translations

Najważniejsze zasady:

• Tłumaczenia rdzenia używają formatu XLIFF (.xlf). Tłumaczenia modułów używają tablic PHP albo XLIFF, zależnie od wersji PS.
• Paczki tłumaczeń instaluje się przez panel administracyjny: Panel administracyjny > Międzynarodowe > Tłumaczenia albo przez php bin/console prestashop:translation:export
• Tłumaczenia zapisane w bazie danych (edytowane w panelu administracyjnym) mają pierwszeństwo przed tłumaczeniami z plików.

Katalogi, których nigdy nie należy modyfikować

Te katalogi są częścią podstawowej infrastruktury PrestaShop. Edytowanie ich bezpośrednio oznacza, że zmiany znikną przy aktualizacji, a Ty ryzykujesz uszkodzenie całej instalacji:

• /vendor/ -- Zależności Composera (Symfony, Doctrine itd.). Zarządzane przez composer install. Nigdy nie edytuj.
• /bin/ -- Komendy konsolowe (bin/console). Uruchamiaj je, ale ich nie edytuj.
• /tools/ -- Skrypty budowania i utrzymania. Do użytku wewnętrznego.
• /install/ -- Kreator instalacji. Po instalacji usuwany (i powinien być usunięty ze względów bezpieczeństwa).
• /admin-dev/ (albo Twój folder administracyjny po zmianie nazwy) -- Punkt wejścia panelu administracyjnego. Zmień nazwę dla bezpieczeństwa, ale nie edytuj plików w środku.
• /webservice/ -- Endpoint REST API. Konfigurowany w panelu administracyjnym, nie przez edycję plików.

Szybka ściąga: gdzie czego szukać

Na działającym serwerze ten szybki audyt pokaże Ci, gdzie sklep ma kod niestandardowy, zanim cokolwiek zmienisz:

find modules themes override -maxdepth 2 -type d | sort
find override -type f -name '*.php' -print
find themes -path '*/modules/*' -type f -name '*.tpl' -print
find var/logs -type f -mtime -3 -print

Co zmienia się między wersjami PS

Ogólny kierunek jest jasny: PrestaShop przechodzi z architektury legacy (/classes/ + /controllers/ + /override/) w stronę Symfony (/src/ + dekorowanie usług + CQRS). Nowe moduły powinny korzystać ze wzorców Symfony tam, gdzie są dostępne, zachowując zgodność wsteczną z 1.7 przez kod zależny od wersji.

Najczęściej zadawane pytania

Czy mogę bezpiecznie usunąć cały katalog var/, żeby zwolnić miejsce?

Usuwaj cache, a nie logi, których nadal możesz potrzebować, i nigdy nie czyść w ciemno cache panelu administracyjnego na działającym sklepie PrestaShop 9. Należy użyć metody czyszczenia cache przez panel administracyjny lub konsolę, aby cache został poprawnie odbudowany. Ale w PS 9 panel administracyjny opiera się na wygenerowanym kontenerze Symfony w var/cache/prod/admin, a surowe usunięcie może zepsuć logowanie do panelu błędem 500, dopóki kontener nie zostanie odbudowany. Na produkcji użyj przycisku "Wyczyść cache" w panelu administracyjnym albo php bin/console cache:clear --env=prod zamiast rm -rf. Logi w var/logs/ można bezpiecznie usuwać, ale często są jedynym zapisem tego, co poszło nie tak, więc przed czyszczeniem warto je zarchiwizować.

Edytowałem szablon / klasę, ale na stronie nic się nie zmieniło. Dlaczego?

Prawie zawsze winny jest cache. Smarty przechowuje skompilowane szablony w var/cache/prod/smarty/compile/, a PrestaShop cache’uje też kontener Symfony i indeks klas. Po edycji szablonów albo override’ów wyczyść cache. Jeśli to zmiana klasy PHP, a plik znajduje się na serwerze z OPcache, może być też konieczne zresetowanie OPcache (albo restart PHP-FPM), bo stary skompilowany bytecode może przetrwać nawet po wyczyszczeniu katalogu cache.

Gdzie powinny znajdować się moje zmiany, żeby przetrwały aktualizację?

Wszystko, co ma przetrwać aktualizację rdzenia, powinno trafić do /modules/ (Twoje własne moduły), do Twojego motywu potomnego w /themes/ albo, w ostateczności, do /override/. Edycja plików w /classes/, /controllers/, /src/, motywie nadrzędnym albo natywnych modułach ps_ oznacza, że następna aktualizacja nadpisze Twoją pracę. Cały sens systemu override’ów i modułów polega na tym, aby trzymać personalizacje poza katalogami zastępowanymi przez aktualizator.

Lista folderów z tego artykułu nie zgadza się z moją instalacją, niektórych brakuje.

Są dwa powody. Pierwszy to wersja: świeża instalacja PrestaShop 8/9 może przechowywać dane dostępowe do bazy w app/config/parameters.php, a nie w config/settings.inc.php, a układ Symfony w /src/ i /app/ zmienia się między wersjami. Drugi to utwardzenie bezpieczeństwa: wiele sklepów produkcyjnych zmienia nazwę folderu administracyjnego, usuwa /install/ po konfiguracji oraz ogranicza dostęp do /config/ i /app/config/. Brak katalogu /install/ to dobry znak, nie uszkodzona instalacja.

Jak znaleźć plik obsługujący konkretną stronę albo funkcję?

Zacznij od adresu URL. Strona sklepu mapuje się na kontroler w controllers/front/ (albo w controllers/front/ konkretnego modułu); pasujący szablon znajduje się w aktywnym motywie w templates/. W przypadku stron administracyjnych sprawdź, czy ekran jest legacy (controllers/admin/), czy Symfony (src/PrestaShopBundle/Controller/). Nowsze ekrany są w Symfony. Włącz _PS_MODE_DEV_ i pasek debugowania, aby zobaczyć dokładnie, który kontroler i szablon wyrenderowały daną stronę; to znacznie szybsze niż zgadywanie po nazwach plików.

To część 1 serii

Ten przegląd daje Ci mapę. Kolejne artykuły z tej serii wejdą w każdy katalog z dokładnością, jakiej wymaga przewodnik referencyjny -- plik po pliku, wzorzec po wzorcu, z prawdziwymi przykładami ze sklepów produkcyjnych.

Seria o architekturze PrestaShop:

• Przegląd struktury folderów (ten artykuł) -- do czego służą najważniejsze katalogi w skrócie
• Szczegółowo o /themes/ -- rozwiązywanie szablonów, pipeline zasobów, wnętrze motywów potomnych, Hummingbird vs Classic, warstwy CSS, jak Smarty renderuje stronę od żądania do HTML
• Szczegółowo o /modules/ -- cykl życia modułu, rejestracja hooków, skrypty aktualizacji, łańcuch instalacji/deinstalacji, działanie cache’owania config.xml, wzorce autoloadingu
• Szczegółowo o /classes/ i /src/ -- wnętrze ObjectModel, współistnienie legacy i Symfony, warstwa Adapter, wzorce komend/zapytań CQRS w PS 8/9
• Szczegółowo o /controllers/ -- kontrolery sklepu i panelu administracyjnego, stan migracji do Symfony per strona, routing, sposób wywoływania hooków przez kontrolery
• Szczegółowo o /config/ i /var/ -- sekwencja ładowania konfiguracji, warstwy cache (Smarty, Symfony, OPcache, Redis), flagi debugowania, referencja defines.inc.php
• Szczegółowo o /override/ -- jak system override’ów działa od środka, class_index.php, skąd biorą się konflikty, co zastępuje go w PS 9, kiedy używać go zamiast hooków
• Szczegółowo o /img/ -- przechowywanie obrazów według cyfr ID, pipeline regeneracji, generowanie WebP, integracja CDN, system typów obrazów

Każdy artykuł jest napisany z perspektywy osoby, która zbudowała i utrzymuje 159 modułów PrestaShop dla PS 1.6, 1.7, 8 i 9. To nie jest dokumentacja przepisana z oficjalnych źródeł -- to praktyczna wiedza z lat diagnozowania, profilowania i budowania systemów produkcyjnych.