PrestaShop-Ordnerstruktur erklaert: Was jedes Verzeichnis tut und wann Sie es brauchen

Warum das Verstaendnis der Ordnerstruktur wichtig ist

PrestaShop ist eine umfangreiche Anwendung. Eine typische Installation umfasst ueber 30.000 Dateien in Hunderten von Verzeichnissen. Die meisten Shopbetreiber muessen nie einen Blick auf das Dateisystem werfen. Doch wenn Sie Module entwickeln, Themes anpassen, Fehler beheben oder Ihren eigenen Server verwalten, spart das Wissen darueber, welches Verzeichnis welche Aufgabe hat, Stunden an Sucharbeit und verhindert kostspielige Fehler.

Dieser Leitfaden behandelt die wichtigsten Verzeichnisse einer PrestaShop 1.7.x-, 8.x- oder 9.x-Installation. Wir beginnen mit den Verzeichnissen, mit denen Sie am haeufigsten arbeiten werden, und arbeiten uns zu denen vor, die Sie in Ruhe lassen sollten.

/modules/ -- Das Herzstück der PrestaShop-Anpassung

Dies ist das Verzeichnis, mit dem Sie am meisten interagieren werden. Jedes Modul -- ob aus dem Marktplatz installiert, als ZIP hochgeladen oder individuell entwickelt -- befindet sich hier als Unterverzeichnis.

modules/
  ps_emailsubscription/       -- natives PrestaShop-Modul
  mprcheckoutrevolution/      -- Drittanbieter-Modul
  mymodule/                   -- Ihr eigenes Modul
    mymodule.php              -- Haupt-Moduldatei (erforderlich)
    config.xml                -- zwischengespeicherte Modul-Metadaten
    views/
      templates/              -- Smarty-Templates
      css/                    -- Stylesheets
      js/                     -- JavaScript
    controllers/
      front/                  -- Front-Office-Controller
      admin/                  -- Admin-Controller
    sql/                      -- Installations-/Upgrade-SQL
    upgrade/                  -- Versions-Upgrade-Skripte
    translations/             -- Uebersetzungsdateien
    vendor/                   -- Composer-Abhaengigkeiten

Wichtige Regeln:

• Die Haupt-PHP-Datei muss exakt denselben Namen wie das Verzeichnis tragen: modules/mymodule/mymodule.php
• Der Klassenname muss ebenfalls uebereinstimmen: class Mymodule extends Module
• Bearbeiten Sie niemals native PS-Module (mit dem Praefix ps_) -- Updates ueberschreiben Ihre Aenderungen. Verwenden Sie stattdessen Hooks, Overrides oder Theme-Template-Overrides
• Modul-Dateien muessen dem Webserver-Benutzer gehoeren (www-data bei den meisten Linux-Setups), damit Uploads und Cache-Generierung funktionieren

Wann Sie dieses Verzeichnis benoetigen: Module installieren, Module entwickeln, Modul-Probleme debuggen, pruefen welche Module installiert sind, Modul-Quellcode einsehen.

/themes/ -- Visuelles Erscheinungsbild und Templates

Die gesamte visuelle Ausgabe des Front-Office wird durch Themes gesteuert. Jedes Theme ist ein Unterverzeichnis mit Templates, Assets und Konfiguration.

themes/
  classic/                    -- PS-Standard-Theme (1.7/8)
    config/theme.yml          -- Theme-Metadaten, Asset-Registrierung
    templates/                -- Smarty-.tpl-Dateien
      catalog/                -- Produkt-, Kategorieseiten
      checkout/               -- Warenkorb, Checkout-Ablauf
      cms/                    -- CMS-Seiten
      customer/               -- Kontoseiten
      _partials/              -- Header, Footer, Benachrichtigungen
      layouts/                -- Seitenlayout-Wrapper
    assets/
      css/                    -- kompiliertes CSS
      js/                     -- kompiliertes JS
      img/                    -- Theme-Bilder (Icons, Platzhalter)
    modules/                  -- Modul-Template-Overrides
  hummingbird/                -- PS 9-Standard-Theme
  my-child-theme/             -- Ihr Child-Theme

Wichtige Regeln:

• Bearbeiten Sie niemals das Parent-Theme direkt. Erstellen Sie ein Child-Theme, das vom Parent erbt, und ueberschreiben Sie nur das, was Sie aendern.
• Das aktive Theme wird im Back-Office unter Design > Theme & Logo festgelegt
• modules/ innerhalb eines Themes hat Vorrang vor den eigenen Templates des Moduls -- so passen Themes die Modul-Ausgabe an
• PrestaShop 9 verwendet Hummingbird (Bootstrap 5, CSS-Layers). PrestaShop 1.7/8 verwendet Classic (Bootstrap 4).

Wann Sie dieses Verzeichnis benoetigen: Das Erscheinungsbild des Shops anpassen, Child-Themes erstellen, Modul-Templates ueberschreiben, Template-Probleme debuggen.

/config/ -- Konfigurationsdateien

Zentrale Konfiguration, die PrestaShop bei jeder Anfrage einliest.

config/
  config.inc.php              -- NICHT BEARBEITEN: automatisch generiert, laedt settings.inc.php
  settings.inc.php            -- Datenbank-Zugangsdaten, Cookie-Schluessel, PS-Version
  defines.inc.php             -- Pfad-Konstanten, Debug-Flags
  smarty.config.inc.php       -- Konfiguration der Smarty-Template-Engine
  autoload.php                -- Composer-Autoloader-Bootstrap

Wichtige Dateien:

• settings.inc.php -- Enthaelt Ihren Datenbank-Host, -Namen, -Benutzer, -Passwort und den Cookie-Verschluesselungsschluessel. Diese Datei wird waehrend der Installation generiert. Sichern Sie diese Datei. Wenn Sie den Cookie-Schluessel verlieren, werden alle bestehenden Kunden- und Mitarbeiter-Sitzungen ungueltig.
• defines.inc.php -- Hier schalten Sie den Debug-Modus um: Setzen Sie _PS_MODE_DEV_ auf true fuer die Entwicklung (zeigt Fehler an), false fuer die Produktion. Enthaelt auch _PS_CACHE_ENABLED_ und weitere Laufzeit-Flags.

Wann Sie dieses Verzeichnis benoetigen: Neue Installation einrichten, Datenbank-Zugangsdaten aendern, Debug-Modus umschalten, Verbindungsprobleme beheben.

/var/ -- Cache, Logs und temporaere Dateien

PrestaShops Laufzeitdaten. Dieses Verzeichnis waechst mit der Zeit und kann bedenkenlos geleert werden (ausser Logs, die Sie behalten moechten).

var/
  cache/
    prod/                     -- Produktions-Cache
      smarty/
        compile/              -- kompilierte Smarty-Templates
        cache/                -- Smarty-Ausgabe-Cache
      ContainerProdDebugProjectContainer.php  -- Symfony-DI-Container
    dev/                      -- Entwicklungs-Cache (wenn _PS_MODE_DEV_ = true)
  logs/
    prod.log                  -- Symfony-/PS-Fehlerprotokolle
    dev.log                   -- Entwicklungsmodus-Protokolle

Wichtige Operationen:

• Cache leeren: rm -rf var/cache/prod/* -- die haeufigste Loesung fuer "Ich habe etwas geaendert, aber es passiert nichts"
• Alternativ: php bin/console cache:clear --env=prod
• Das Smarty-Compile-Verzeichnis speichert vorkompilierte Templates. Wenn eine Template-Aenderung nicht erscheint, loeschen Sie var/cache/prod/smarty/compile/*
• Logs pruefen: var/logs/prod.log ist die erste Anlaufstelle, wenn etwas nicht funktioniert. Es enthaelt PHP-Fehler, Symfony-Ausnahmen und Modul-Fehler.

Wann Sie dieses Verzeichnis benoetigen: Cache leeren nach Aenderungen, Fehler ueber Logs debuggen, Speicherplatz auf kleinen Servern freigeben.

/classes/ -- Kern-Geschaeftslogik (Legacy)

PrestaShops urspruengliches Objektmodell. Jede Datei ist eine PHP-Klasse, die eine Geschaeftsentitaet oder ein Hilfsprogramm repraesentiert.

classes/
  Product.php                 -- Produkt-Entitaet (Attribute, Preise, Lager)
  Category.php                -- Kategorie-Entitaet
  Cart.php                    -- Warenkorb-Logik
  Order.php                   -- Bestell-Entitaet
  Customer.php                -- Kunden-Entitaet
  Module.php                  -- Basis-Modulklasse (Installation, Hooks, Konfiguration)
  Tools.php                   -- Hilfsfunktionen (Weiterleitung, getValue, etc.)
  Db.php                      -- Datenbank-Abstraktionsschicht
  ObjectModel.php             -- Basis-ORM-Klasse
  shop/
    Shop.php                  -- Multishop-Logik
  tax/
    Tax.php                   -- Steuerberechnung
  stock/
    StockAvailable.php        -- Lagerverwaltung

Wichtige Regeln:

• Bearbeiten Sie diese Dateien niemals direkt. Verwenden Sie den /override/classes/-Mechanismus, wenn Sie das Kernverhalten aendern muessen (aber Overrides haben ihre eigenen Probleme -- bevorzugen Sie Hooks und Module).
• Ab PS 1.7+ werden viele dieser Klassen schrittweise durch Symfony-Services in /src/ ersetzt. Beide Systeme existieren parallel.
• ObjectModel ist die Basisklasse fuer alle Entitaeten. Sie zu verstehen ist essenziell fuer die Modulentwicklung -- sie stellt add(), update(), delete(), getFields() und Validierung bereit.

Wann Sie dieses Verzeichnis benoetigen: Verstehen, wie PrestaShop Preise berechnet, Lagerbestaende verwaltet und Bestellungen verarbeitet. Diese Dateien zu lesen (nicht zu bearbeiten) ist der Weg, die interne API kennenzulernen.

/controllers/ -- Anfrageverarbeitung

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

controllers/
  front/
    ProductController.php     -- Produktseite
    CategoryController.php    -- Kategorie-Auflistung
    CartController.php        -- Warenkorb-Operationen
    OrderController.php       -- Checkout-Schritte
    CmsController.php         -- CMS-Seiten
    SearchController.php      -- Suchergebnisse
  admin/
    AdminProductsController.php
    AdminOrdersController.php
    AdminCustomersController.php

Wichtige Regeln:

• Front-Controller erweitern FrontController. Admin-Controller erweitern AdminController.
• Ab PS 1.7+ werden Admin-Controller auf Symfony migriert (in /src/PrestaShopBundle/Controller/). Einige Admin-Seiten verwenden die neuen Symfony-Controller, andere nutzen noch die Legacy-Controller hier. Beide existieren parallel.
• Modul-Controller befinden sich in modules/ihrmodul/controllers/, nicht hier.

Wann Sie dieses Verzeichnis benoetigen: Verstehen, wie eine bestimmte Seite funktioniert, seitenbezogene Probleme debuggen, herausfinden welche Hooks auf welcher Seite verfuegbar 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/                    -- Bruecken zwischen Legacy und Symfony
  Core/
    Domain/                   -- CQRS-Befehle und -Abfragen
      Product/
        Command/              -- CreateProduct, UpdateProduct, etc.
        Query/                -- GetProductForEditing, etc.
    Grid/                     -- Admin-Listen-/Grid-Definitionen
    Form/                     -- Admin-Formular-Definitionen
  PrestaShopBundle/
    Controller/               -- Symfony-Admin-Controller
    Entity/                   -- Doctrine-Entitaeten
    Form/                     -- Formulartypen
    Translation/              -- Uebersetzungssystem
    Twig/                     -- Twig-Erweiterungen fuer Admin

Wichtige Regeln:

• Dieses Verzeichnis waechst mit jeder PS-Version, da immer mehr Funktionen zu Symfony migriert werden
• Die Adapter/-Schicht ist entscheidend -- sie kapselt Legacy-Klassen, damit Symfony-Services sie nutzen koennen
• In PS 9 sind die meisten Admin-Seiten vollstaendig Symfony-basiert. In PS 1.7/8 ist es eine Mischung aus Legacy und Symfony.
• Modulentwickler muessen hier selten etwas aendern -- interagieren Sie damit ueber Symfony-Services, die in der services.yml Ihres Moduls registriert sind

Wann Sie dieses Verzeichnis benoetigen: Fortgeschrittene Modulentwicklung mit Symfony-Services, Verstaendnis des CQRS-Musters fuer Produkt-/Bestellverwaltung in PS 8+, Beitraege zum PrestaShop-Core.

/override/ -- Das Override-System

PrestaShops Mechanismus zur Aenderung des Kernverhaltens, ohne die Core-Dateien zu bearbeiten.

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

Wichtige Regeln:

• Override-Klassen erweitern das Original und ueberschreiben bestimmte Methoden
• Pro Klasse ist nur ein Override moeglich. Wenn zwei Module versuchen, dieselbe Klasse zu ueberschreiben, gewinnt nur das letzte. Deshalb sind Overrides fragil -- Modul-Konflikte sind in aktiven Shops vorprogrammiert.
• Nach dem Hinzufuegen oder Entfernen von Overrides regenerieren Sie den Klassenindex: Loeschen Sie var/cache/prod/class_index.php und leeren Sie den Cache
• PS 9 markiert das Override-System als veraltet (deprecated). Bevorzugen Sie Hooks, Symfony-Service-Decoration oder CQRS-Befehle fuer neue Entwicklungen.
• Overrides koennen mysterioese Bugs verursachen, die schwer zu finden sind. Pruefen Sie immer override/, wenn Sie unerwartetes Verhalten debuggen.

Wann Sie dieses Verzeichnis benoetigen: Als letztes Mittel, wenn Hooks nicht die noetige Kontrolle bieten. Bevorzugen Sie immer Hooks und modulbasierte Ansaetze. Lesen Sie unsere Hooks- & Overrides-Referenz fuer das vollstaendige Bild.

/img/ -- Produkt- und Inhaltsbilder

img/
  p/                          -- Produktbilder (organisiert nach ID-Ziffern)
    1/2/3/                    -- Bilder von Produkt-ID 123
      123.jpg                 -- Original
      123-home_default.jpg    -- verkleinert fuer die Startseite
      123-large_default.jpg   -- verkleinert fuer die Produktseite
  c/                          -- Kategoriebilder
  m/                          -- Hersteller-/Markenlogos
  s/                          -- Lieferantenlogos
  cms/                        -- CMS-Seitenbilder (ueber Editor hochgeladen)
  l/                          -- Sprachflaggen-Icons
  tmp/                        -- temporaere Uploads

Wichtige Regeln:

• Produktbilder werden in einem Pfad gespeichert, der sich aus den Ziffern der Produkt-ID ableitet: Produkt 123 → img/p/1/2/3/. Dies verteilt Dateien ueber Verzeichnisse, um Dateisystem-Limits zu vermeiden.
• Die Bildregeneration (Back-Office > Design > Bildeinstellungen > Regenerieren) erstellt alle verkleinerten Versionen aus den Originalen neu. Bei grossen Katalogen kann dies Stunden dauern.
• Sichern Sie dieses Verzeichnis. Produktbilder koennen nicht regeneriert werden, wenn die Originale verloren gehen.
• WebP-Versionen werden ab PS 8+ neben JPG/PNG generiert, wenn aktiviert.

Wann Sie dieses Verzeichnis benoetigen: Fehlende Produktbilder debuggen, Bildqualitaet pruefen, Massenoperationen mit Bildern, Servermigration (dies ist oft das groesste Verzeichnis nach Dateianzahl).

/app/ -- Symfony-Anwendungskernel

app/
  AppKernel.php               -- Symfony-Kernel, registriert Bundles
  config/
    config.yml                -- Symfony-Service-Konfiguration
    parameters.php            -- automatisch generiert aus settings.inc.php
    routing.yml               -- URL-Routing-Definitionen
    security.yml              -- Authentifizierung/Autorisierung
    services.yml              -- Service-Container-Definitionen

Wichtige Regeln:

• AppKernel.php ist der Einstiegspunkt fuer die Symfony-Seite von PrestaShop. Er registriert alle Bundles einschliesslich der Modul-Bundles.
• config/routing.yml definiert die URL-Muster im Admin-Bereich. Modul-Admin-Routen werden separat ueber die eigenen Routing-Dateien des Moduls registriert.
• In PS 9 wurde der Kernel erheblich ueberarbeitet. Die Generierung von parameters.php kann abweichen.

Wann Sie dieses Verzeichnis benoetigen: Fortgeschrittenes Debugging von Symfony-Routing, Service-Container-Problemen oder Authentifizierungsproblemen. Die meisten Entwickler beruehren dies niemals direkt.

/translations/ -- Core-Uebersetzungsdateien

translations/
  default/                    -- Standard-englische Zeichenketten
  en-US/                      -- US-Englisch
  fr-FR/                      -- Franzoesisch
  de-DE/                      -- Deutsch
    ShopTheme.fr-FR.xlf       -- Front-Office-Uebersetzungen
    AdminNavigation.fr-FR.xlf -- Admin-Menueuebersetzungen

Wichtige Regeln:

• Core-Uebersetzungen verwenden das XLIFF-Format (.xlf). Modul-Uebersetzungen nutzen PHP-Arrays oder XLIFF, je nach PS-Version.
• Uebersetzungspakete werden ueber Back-Office > International > Uebersetzungen oder php bin/console prestashop:translation:export installiert
• In der Datenbank gespeicherte Uebersetzungen (im Back-Office bearbeitet) haben Vorrang vor dateibasierten Uebersetzungen.

Verzeichnisse, die Sie niemals aendern sollten

Diese Verzeichnisse sind Teil der Core-Infrastruktur von PrestaShop. Direkte Bearbeitung bedeutet, dass Ihre Aenderungen bei einem Update verloren gehen und Sie riskieren, die gesamte Installation zu beschaedigen:

• /vendor/ -- Composer-Abhaengigkeiten (Symfony, Doctrine, etc.). Verwaltet durch composer install. Niemals bearbeiten.
• /bin/ -- Konsolenbefehle (bin/console). Ausfuehren, nicht bearbeiten.
• /tools/ -- Build- und Wartungsskripte. Nur fuer internen Gebrauch.
• /install/ -- Installationsassistent. Wird nach der Installation geloescht (sollte aus Sicherheitsgruenden geloescht werden).
• /admin-dev/ (oder Ihr umbenannter Admin-Ordner) -- Admin-Einstiegspunkt. Aus Sicherheitsgruenden umbenennen, aber die Dateien darin nicht bearbeiten.
• /webservice/ -- REST-API-Endpunkt. Wird ueber das Back-Office konfiguriert, nicht durch Bearbeitung von Dateien.

Kurzreferenz: Wo Sie was finden

Was sich zwischen PS-Versionen aendert

Der allgemeine Trend ist klar: PrestaShop bewegt sich von der Legacy-Architektur (/classes/ + /controllers/ + /override/) hin zu Symfony (/src/ + Service-Decoration + CQRS). Neue Modulentwicklung sollte die Symfony-Muster nutzen, wo verfuegbar, und gleichzeitig die Abwaertskompatibilitaet mit 1.7 durch versionsabhaengigen Code wahren.

Naechster Teil dieser Serie

Dieser Ueberblick behandelt die Verzeichnisstruktur auf oberster Ebene. Zukuenftige Artikel werden tiefer in bestimmte Bereiche eintauchen: die Modul-Anatomie (was jede Datei in einem Modul tut), das Hook-System (wie Module mit PrestaShop interagieren, ohne den Core zu veraendern) und die Theme-Template-Engine (Smarty-Variablen, Bloecke und die Rendering-Pipeline).