PrestaShop-Ordnerstruktur erklärt: Was jedes Verzeichnis macht und wann Sie es brauchen

Abgeglichen mit PrestaShop 1.6, 1.7, 8.x und 9.x. Die folgenden Verzeichnisse gibt es in diesen Versionen; der wichtigste Unterschied ist, wie viel bereits nach /src/ (Symfony) gewandert ist und dass PrestaShop 9 Hummingbird statt Classic ausliefert. Versionsspezifische Unterschiede sind in den Tabellen am Ende markiert.

Warum es wichtig ist, die Ordnerstruktur zu verstehen

PrestaShop ist eine große Anwendung. Eine typische Installation enthält über 30.000 Dateien in Hunderten von Verzeichnissen. Die meisten Shopbetreiber müssen sich das Dateisystem nie ansehen. Wenn Sie aber Module entwickeln, Themes anpassen, Fehler debuggen oder Ihren eigenen Server verwalten, spart das Wissen um die Aufgaben der einzelnen Verzeichnisse viele Stunden Suche und verhindert teure Fehler.

Dieser Leitfaden behandelt die wichtigsten Verzeichnisse in einer PrestaShop-Installation mit 1.7.x, 8.x oder 9.x. Wir beginnen mit den Ordnern, mit denen Sie am häufigsten arbeiten, und gehen dann zu denen über, die Sie besser in Ruhe lassen.

/modules/ -- Das Herz der PrestaShop-Anpassung

Mit diesem Verzeichnis werden Sie am häufigsten zu tun haben. Jedes Modul -- egal ob aus dem Marketplace installiert, als ZIP hochgeladen oder individuell entwickelt -- liegt hier als Unterverzeichnis.

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

Wichtige Regeln:

• Die zentrale PHP-Datei muss exakt denselben Namen haben wie das Verzeichnis: modules/mymodule/mymodule.php
• Der Klassenname darin muss ebenfalls passen: class Mymodule extends Module
• Bearbeiten Sie niemals native PS-Module (mit Präfix ps_) -- Updates überschreiben Ihre Änderungen. Verwenden Sie stattdessen Hooks, Overrides oder Template-Overrides im Theme
• Moduldateien müssen dem Webserver-Benutzer gehören (www-data auf den meisten Linux-Systemen), damit Uploads und Cache-Erzeugung funktionieren

Wann Sie dieses Verzeichnis brauchen: Module installieren, Module entwickeln, Modulprobleme debuggen, prüfen, welche Module installiert sind, Quellcode von Modulen ansehen.

/themes/ -- Visuelles Erscheinungsbild und Templates

Die gesamte visuelle Ausgabe im Frontoffice wird von Themes gesteuert. Jedes Theme ist ein Unterverzeichnis mit Templates, Assets und Konfiguration.

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

Wichtige Regeln:

• Bearbeiten Sie niemals das Parent-Theme direkt. Erstellen Sie ein Child-Theme, das vom Parent erbt, und überschreiben Sie nur das, was Sie ändern.
• Das aktive Theme wird unter Backoffice > Design > Theme & Logo festgelegt
• modules/ innerhalb eines Themes hat Vorrang vor den Templates des Moduls selbst -- so passen Themes die Modulausgabe an
• PrestaShop 9 verwendet Hummingbird (Bootstrap 5, CSS Layers). PrestaShop 1.7/8 verwendet Classic (Bootstrap 4).

Wann Sie dieses Verzeichnis brauchen: Shop-Design anpassen, Child-Themes erstellen, Modul-Templates überschreiben, Template-Probleme debuggen.

/config/ -- Konfigurationsdateien

Zentrale Konfiguration, die PrestaShop bei jeder Anfrage liest.

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

Wichtige Dateien:

• settings.inc.php -- Enthält Datenbank-Host, Datenbankname, Benutzer, Passwort und den Cookie-Verschlüsselungsschlüssel. Diese Datei wird während der Installation erzeugt. Sichern Sie sie. Wenn Sie den Cookie-Schlüssel verlieren, werden alle bestehenden Kundensitzungen und Mitarbeitersitzungen ungültig.
• defines.inc.php -- Hier schalten Sie den Debug-Modus um: Setzen Sie _PS_MODE_DEV_ für die Entwicklung auf true (zeigt Fehler an) und für die Produktion auf false. Enthält außerdem _PS_CACHE_ENABLED_ und weitere Laufzeit-Flags.

Eine Sache führt bei PrestaShop 8 und 9 oft zu Verwirrung: settings.inc.php existiert möglicherweise nicht. Neuere Installationen speichern dieselben Zugangsdaten stattdessen in app/config/parameters.php, erzeugt vom Installer. Wenn Sie die Datenbankverbindung suchen und config/settings.inc.php fehlt, schauen Sie in app/config/parameters.php. Das ist der moderne Speicherort für dieselben Werte.

Wann Sie dieses Verzeichnis brauchen: Neue Installation einrichten, Datenbank-Zugangsdaten ändern, Debug-Modus umschalten, Verbindungsprobleme beheben.

/var/ -- Cache, Logs und temporäre Dateien

Laufzeitdaten von PrestaShop. Dieses Verzeichnis wächst mit der Zeit; leeren Sie seinen Cache über das Backoffice oder die Konsole und bewahren Sie die Logs auf, die Sie behalten möchten.

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

Wichtige Vorgänge:

• Leeren Sie den Cache über Erweiterte Einstellungen > Leistung > Cache leeren.
• Alternativ: php bin/console cache:clear --env=prod
• Das Smarty-Compile-Verzeichnis speichert vorkompilierte Templates. Wenn eine Template-Änderung nicht erscheint, löschen Sie var/cache/prod/smarty/compile/*
• Logs prüfen: var/logs/prod.log ist die erste Anlaufstelle, wenn etwas kaputtgeht. Es enthält PHP-Fehler, Symfony-Exceptions und Modulfehler.

Ein Hinweis speziell für PrestaShop 9: Das Backoffice ist eine Symfony-App mit eigenem generiertem Container unter var/cache/prod/admin. Ein blindes rm -rf var/cache/prod/* in einem Live-Shop mit PS 9 kann im Adminbereich einen unvollständigen Container hinterlassen und auf der Login-Seite 500-Fehler auslösen, bis der Admin-Cache neu aufgebaut wurde. Verwenden Sie bei PS 9 lieber die Konsole (php bin/console cache:clear --env=prod) statt roher Löschung, und leeren Sie den Cache als Webserver-Benutzer, damit die neu erzeugten Dateien den richtigen Besitzer haben.

Wann Sie dieses Verzeichnis brauchen: Cache nach Änderungen leeren, Fehler über Logs debuggen, Speicherplatz auf kleinen Servern freigeben.

/classes/ -- Zentrale Geschäftslogik (Legacy)

Das ursprüngliche Objektmodell von PrestaShop. Jede Datei ist eine PHP-Klasse, die eine Geschäftsentität oder ein Hilfswerkzeug abbildet.

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

Wichtige Regeln:

• Bearbeiten Sie diese Dateien niemals direkt. Verwenden Sie den Mechanismus /override/classes/, wenn Sie Kernverhalten ändern müssen (Overrides bringen allerdings eigene Probleme mit sich -- bevorzugen Sie Hooks und Module).
• In PS 1.7+ werden viele dieser Klassen schrittweise durch Symfony-Services in /src/ ersetzt. Beide Systeme existieren nebeneinander.
• ObjectModel ist die Basisklasse für alle Entitäten. Sie zu verstehen ist für die Modulentwicklung unverzichtbar -- sie stellt add(), update(), delete(), getFields() und Validierung bereit.

Wann Sie dieses Verzeichnis brauchen: Verstehen, wie PrestaShop Preise berechnet, Lagerbestände verwaltet und Bestellungen verarbeitet. Diese Dateien zu lesen (nicht zu bearbeiten) ist der Weg, die interne API zu verstehen.

/controllers/ -- Verarbeitung von Anfragen

Controller verarbeiten HTTP-Anfragen und rendern Seiten. PrestaShop hat zwei Gruppen: Frontoffice und Admin.

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

Wichtige Regeln:

• Front-Controller erweitern FrontController. Admin-Controller erweitern AdminController.
• In PS 1.7+ werden Admin-Controller zu Symfony migriert (in /src/PrestaShopBundle/Controller/). Manche Adminseiten verwenden die neuen Symfony-Controller, andere noch die Legacy-Controller hier. Beides existiert nebeneinander.
• Modul-Controller liegen in modules/yourmodule/controllers/, nicht hier.

Wann Sie dieses Verzeichnis brauchen: Verstehen, wie eine bestimmte Seite funktioniert, seitenbezogene Probleme debuggen, herausfinden, welche Hooks auf welcher Seite verfügbar sind (Controller rufen Hook::exec() auf).

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

Die moderne Architekturschicht. PrestaShop migriert seit Version 1.7 schrittweise vom Legacy-Muster /classes/ + /controllers/ zu 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

Wichtige Regeln:

• Dieses Verzeichnis wächst mit jeder PS-Version, weil weitere Funktionen zu Symfony migrieren
• Die Adapter/-Schicht ist entscheidend -- sie kapselt Legacy-Klassen, damit Symfony-Services sie nutzen können
• In PS 9 sind die meisten Adminseiten vollständig Symfony. In PS 1.7/8 ist es eine Mischung aus Legacy und Symfony.
• Modulentwickler müssen hier nur selten etwas ändern -- interagieren Sie damit über Symfony-Services, die in der services.yml Ihres Moduls registriert sind

Wann Sie dieses Verzeichnis brauchen: Fortgeschrittene Modulentwicklung mit Symfony-Services, Verständnis des CQRS-Musters für Produkt-/Bestellverwaltung in PS 8+, Beiträge zum PrestaShop-Core.

/override/ -- Das Override-System

Der PrestaShop-Mechanismus, um Kernverhalten zu ändern, ohne Core-Dateien zu bearbeiten.

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

Wichtige Regeln:

• Override-Klassen erweitern das Original und überschreiben bestimmte Methoden
• Pro Klasse ist nur ein Override möglich. Wenn zwei Module dieselbe Klasse überschreiben wollen, gewinnt nur das zuletzt installierte. Deshalb sind Overrides fragil -- Modulkonflikte sind in aktiven Shops praktisch garantiert.
• Nach dem Hinzufügen oder Entfernen von Overrides den Klassenindex neu erzeugen: var/cache/prod/class_index.php löschen und den Cache leeren
• PS 9 stuft das Override-System als veraltet ein. Verwenden Sie für neue Entwicklungen lieber Hooks, Symfony-Service-Dekoration oder CQRS-Commands.
• Overrides können rätselhafte Fehler verursachen, die schwer nachzuverfolgen sind. Prüfen Sie beim Debuggen unerwarteten Verhaltens immer override/.

Wann Sie dieses Verzeichnis brauchen: Als letzte Option, wenn Hooks nicht genug Kontrolle bieten. Bevorzugen Sie immer Hooks und modulbasierte Ansätze. Lesen Sie unsere Referenz zu Hooks & Overrides für das vollständige Bild.

/img/ -- Produkt- und Inhaltsbilder

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

Wichtige Regeln:

• Produktbilder werden in einem Pfad gespeichert, der aus den Ziffern der Produkt-ID abgeleitet ist: Produkt 123 → img/p/1/2/3/. So werden Dateien auf Verzeichnisse verteilt, um Dateisystem-Limits zu vermeiden.
• Die Bildregenerierung (Backoffice > Design > Bildeinstellungen > Regenerieren) erstellt alle verkleinerten Versionen aus den Originalen neu. Bei großen Katalogen kann das Stunden dauern.
• Sichern Sie dieses Verzeichnis. Produktbilder lassen sich nicht neu erzeugen, wenn die Originale verloren gehen.
• WebP-Versionen werden in PS 8+ bei aktivierter Option parallel zu JPG/PNG erzeugt.

Wann Sie dieses Verzeichnis brauchen: Fehlende Produktbilder debuggen, Bildqualität prüfen, Massenaktionen für Bilder, Servermigration (nach Dateianzahl ist dies oft das größte Verzeichnis).

/app/ -- Symfony-Anwendungskernel

app/
  AppKernel.php               -- Symfony kernel, registers bundles
  config/
    config.yml                -- Symfony service configuration
    parameters.php -- generierte Konfiguration; neuere Installationen speichern hier die Zugangsdaten.
    routing.yml               -- URL routing definitions
    security.yml              -- authentication/authorization
    services.yml              -- service container definitions

Wichtige Regeln:

• AppKernel.php ist der Einstiegspunkt für die Symfony-Seite von PrestaShop. Er registriert alle Bundles, einschließlich Modul-Bundles.
• config/routing.yml definiert Admin-URL-Muster. Admin-Routen von Modulen werden separat über die eigenen Routing-Dateien des Moduls registriert.
• In PS 9 wurde der Kernel deutlich überarbeitet. Die Erzeugung von parameters.php kann abweichen.

Wann Sie dieses Verzeichnis brauchen: Fortgeschrittenes Debugging von Symfony-Routing, Service-Container-Problemen oder Authentifizierungsproblemen. Die meisten Entwickler fassen es nie direkt an.

/translations/ -- Core-Übersetzungsdateien

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

Wichtige Regeln:

• Core-Übersetzungen verwenden das XLIFF-Format (.xlf). Modulübersetzungen verwenden je nach PS-Version PHP-Arrays oder XLIFF.
• Übersetzungspakete werden über Backoffice > International > Übersetzungen oder php bin/console prestashop:translation:export installiert
• In der Datenbank gespeicherte Übersetzungen (im Backoffice bearbeitet) haben Vorrang vor dateibasierten Übersetzungen.

Verzeichnisse, die Sie niemals ändern sollten

Diese Verzeichnisse gehören zur Core-Infrastruktur von PrestaShop. Wenn Sie sie direkt bearbeiten, gehen Ihre Änderungen beim Update verloren, und Sie riskieren, die gesamte Installation zu beschädigen:

• /vendor/ -- Composer-Abhängigkeiten (Symfony, Doctrine usw.). Wird von composer install verwaltet. Niemals bearbeiten.
• /bin/ -- Konsolenbefehle (bin/console). Ausführen, nicht bearbeiten.
• /tools/ -- Build- und Wartungsskripte. Interne Verwendung.
• /install/ -- Installationsassistent. Wird nach der Installation gelöscht (sollte es aus Sicherheitsgründen jedenfalls sein).
• /admin-dev/ (oder Ihr umbenannter Admin-Ordner) -- Admin-Einstiegspunkt. Aus Sicherheitsgründen umbenennen, aber die Dateien darin nicht bearbeiten.
• /webservice/ -- REST-API-Endpunkt. Wird über das Backoffice konfiguriert, nicht durch Bearbeiten von Dateien.

Schnellreferenz: Wo Sie was finden

Auf einem Live-Server zeigt Ihnen diese schnelle Prüfung, wo der Shop individuellen Code enthält, bevor Sie irgendetwas anfassen:

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

Was sich zwischen PS-Versionen ändert

Der Trend ist eindeutig: PrestaShop bewegt sich von der Legacy-Architektur (/classes/ + /controllers/ + /override/) in Richtung Symfony (/src/ + Service-Dekoration + CQRS). Neue Modulentwicklung sollte, wo verfügbar, auf Symfony-Muster setzen und zugleich die Abwärtskompatibilität mit 1.7 über versionsabhängigen Code wahren.

Häufig gestellte Fragen

Kann ich das gesamte Verzeichnis var/ sicher löschen, um Speicherplatz freizugeben?

Löschen Sie den Cache, nicht die Logs, die Sie noch brauchen, und wischen Sie den Admin-Cache in einem Live-Shop mit PrestaShop 9 niemals blind weg. Leeren Sie den Cache über das Backoffice oder die Konsole, damit er korrekt neu aufgebaut wird. In PS 9 stützt sich das Backoffice jedoch auf einen generierten Symfony-Container unter var/cache/prod/admin, und ein rohes Löschen kann den Admin-Login mit einem 500-Fehler lahmlegen, bis dieser Container neu aufgebaut ist. Verwenden Sie in der Produktion lieber die Backoffice-Schaltfläche "Cache leeren" oder php bin/console cache:clear --env=prod statt rm -rf. Logs unter var/logs/ können zwar gelöscht werden, sind aber oft der einzige Nachweis dafür, was schiefgelaufen ist. Archivieren Sie sie daher vor dem Leeren.

Ich habe ein Template / eine Klasse bearbeitet, aber auf der Website ändert sich nichts. Warum?

Fast immer: Cache. Smarty speichert kompilierte Templates unter var/cache/prod/smarty/compile/, und PrestaShop cached außerdem den Symfony-Container und den Klassenindex. Leeren Sie nach Änderungen an Templates oder Overrides den Cache. Wenn es sich um eine Änderung an einer PHP-Klasse handelt und die Datei auf einem Server mit OPcache liegt, müssen Sie eventuell auch OPcache zurücksetzen (oder PHP-FPM neu starten), weil der alte kompilierte Bytecode selbst nach dem Leeren des Cache-Verzeichnisses bestehen bleiben kann.

Wo müssen meine Änderungen liegen, damit sie ein Upgrade überleben?

Alles, was ein Core-Update überstehen soll, gehört in /modules/ (Ihre eigenen Module), in Ihr Child-Theme unter /themes/ oder, als letzte Option, nach /override/. Wenn Sie Dateien unter /classes/, /controllers/, /src/, im Parent-Theme oder in nativen ps_-Modulen bearbeiten, überschreibt das nächste Upgrade Ihre Arbeit. Der Sinn des Override- und Modulsystems ist gerade, Ihre Anpassungen aus den Verzeichnissen herauszuhalten, die der Upgrader ersetzt.

Die Ordnerliste in diesem Artikel passt nicht zu meiner Installation, einige fehlen.

Das hat zwei Gründe. Erstens die Version: Eine frische PrestaShop-8/9-Installation speichert DB-Zugangsdaten möglicherweise in app/config/parameters.php statt in config/settings.inc.php, und das Symfony-Layout unter /src/ und /app/ verschiebt sich zwischen Versionen. Zweitens die Absicherung: Viele Produktionsshops benennen den Admin-Ordner um, löschen /install/ nach der Einrichtung und beschränken den Zugriff auf /config/ und /app/config/. Ein fehlendes Verzeichnis /install/ ist ein gutes Zeichen, kein Hinweis auf eine kaputte Installation.

Wie finde ich heraus, welche Datei für eine bestimmte Seite oder Funktion zuständig ist?

Beginnen Sie bei der URL. Eine Frontoffice-Seite wird einem Controller in controllers/front/ (oder in controllers/front/ eines Moduls) zugeordnet; das passende Template liegt in Ihrem aktiven Theme unter templates/. Prüfen Sie bei Adminseiten, ob die Ansicht Legacy (controllers/admin/) oder Symfony (src/PrestaShopBundle/Controller/) ist. Neuere Ansichten sind Symfony. Aktivieren Sie _PS_MODE_DEV_ und die Debug-Toolbar, um genau zu sehen, welcher Controller und welches Template eine bestimmte Seite gerendert haben; das ist deutlich schneller als Rätselraten anhand von Dateinamen.

Dies ist Teil 1 einer Serie

Diese Übersicht gibt Ihnen die Karte an die Hand. Die folgenden Artikel dieser Serie führen Sie mit der Tiefe eines Referenzleitfadens in jedes Verzeichnis hinein -- Datei für Datei, Muster für Muster, mit echten Beispielen aus Produktionsshops.

Die PrestaShop-Architekturserie:

• Überblick über die Ordnerstruktur (dieser Artikel) -- was die wichtigsten Verzeichnisse auf einen Blick machen
• /themes/ Tiefenanalyse -- Template-Auflösung, Asset-Pipeline, Interna von Child-Themes, Hummingbird vs Classic, CSS Layers, wie Smarty eine Seite von der Anfrage bis zum HTML rendert
• /modules/ Tiefenanalyse -- Modul-Lebenszyklus, Hook-Registrierung, Upgrade-Skripte, Installations-/Deinstallationskette, wie config.xml-Caching funktioniert, Autoloading-Muster
• /classes/ und /src/ Tiefenanalyse -- Interna von ObjectModel, wie Legacy und Symfony nebeneinander existieren, die Adapter-Schicht, CQRS-Command-/Query-Muster in PS 8/9
• /controllers/ Tiefenanalyse -- Front- vs. Admin-Controller, Symfony-Migrationsstand je Seite, Routing, wie Hooks pro Controller aufgerufen werden
• /config/ und /var/ Tiefenanalyse -- Ladeabfolge der Konfiguration, Cache-Schichten (Smarty, Symfony, OPcache, Redis), Debug-Flags, die defines.inc.php-Referenz
• /override/ Tiefenanalyse -- wie das Override-System intern funktioniert, class_index.php, warum es Konflikte verursacht, was es in PS 9 ersetzt und wann Sie es statt Hooks verwenden sollten
• /img/ Tiefenanalyse -- Bildspeicherung nach ID-Ziffern, Regenerierungs-Pipeline, WebP-Erzeugung, CDN-Integration, das Bildtyp-System

Jeder Artikel ist aus der Perspektive von jemandem geschrieben, der 159 PrestaShop-Module für PS 1.6, 1.7, 8 und 9 gebaut und gepflegt hat. Das ist keine umformulierte Dokumentation aus den offiziellen Handbüchern -- sondern praktisches Wissen aus Jahren des Debuggens, Profilings und Aufbaus produktiver Systeme.