Code- und Modulverzeichnisstruktur von PrestaShop

So würden wir vorgehen

Wir würden mit der Aufgabe beginnen, das von der Live-Domain ausgelieferte Shop-Stammverzeichnis und dessen genaue Version bestätigen und dann die relevanten Dateien prüfen, ohne sie zu ändern. Nutzen Sie das Backoffice für unterstützte Konfigurations- und Cachevorgänge, und legen Sie geplante Anpassungen in ein gepflegtes Modul oder Child-Theme statt in Core-Dateien.

Erstellen Sie vor jeder Änderung oder Löschung ein Datei- und Datenbank-Backup, proben Sie die Änderung auf einer Staging-Kopie und bestätigen Sie die Rollback-Schritte; der Backup-Leitfaden und der Staging-Leitfaden behandeln beides. Der Upgrade-Weg hängt von Ihren bestehenden Modulen, Integrationen, Ihrem Theme, Ihren Daten und individuellem Code ab. Bei einer großen Migration ist der übliche sichere Weg ein sauberer Zielshop auf Staging, neu aufgebaute und getestete Anpassungen, eine geprobte Datenmigration und eine geplante Umstellung. Ein Update der bestehenden Installation bleibt eine Option, wenn Inventar und Staging-Tests es stützen. Der Leitfaden zur Migration auf PrestaShop 9 vergleicht beide Wege.

Den Plan für Ihre Versionsfamilie wählen

Die folgenden Pfade sind relativ zum Shop-Stammverzeichnis. Sie dienen als Ausgangspunkte zur Prüfung anhand der installierten Version und versprechen keine identische Struktur in jeder Minor-Version oder jedem Hostingpaket. Ein vorhandenes Verzeichnis beweist nicht, dass der Shop es aktuell nutzt.

Prüfen Sie die Version im Backoffice oder in den Bereitstellungsunterlagen. Auch ein in einem Unterverzeichnis installierter Shop kann dazu führen, dass Pfade von einem Beispiel abweichen. Die folgenden Menüpfade im Backoffice verwenden moderne Bezeichnungen. Nutzen Sie unter PrestaShop 1.6 für die entsprechenden Aufgaben Voreinstellungen > Themes, Voreinstellungen > Bilder und Lokalisierung > Übersetzungen.

Fragen Sie, bevor Sie weiter suchen, welches Verzeichnis die Live-Domain tatsächlich ausliefert. Ein Hostingkonto kann alte Kopien, Staging-Installationen oder verlinkte Release-Verzeichnisse enthalten. Ein vertrauter Ordner modules/ belegt nicht, dass Sie den aktiven Shop vor sich haben. Nutzen Sie den Kompatibilitätsleitfaden, wenn Sie Arbeiten über mehrere Versionen hinweg planen.

Die wichtigsten Plattformverzeichnisse finden

PrestaShop ab 1.7 kombiniert ältere Klassen und Controller mit einer Symfony-Schicht. Lesen Sie Core-Code, um das Verhalten zu verstehen, und halten Sie Shopanpassungen in Ihrem Modul, Child-Theme oder einem unterstützten Erweiterungspunkt.

Das vendor/ des Core enthält Composer-Abhängigkeiten; ein Fehler dort muss über den Paket- und Bereitstellungsprozess untersucht werden, weil direkte Änderungen leicht verloren gehen. bin/console führt Konsolenbefehle aus: Bestätigen Sie die verfügbaren Befehle und die PHP-Laufzeit, bevor Sie etwas ausführen. Das Admin-Einstiegsverzeichnis ist in bereitgestellten Shops normalerweise umbenannt. Installer-Verzeichnisse sollten nach der Installation entfernt werden. Konfigurieren Sie den Webservice-Zugriff über das Backoffice, statt seine Einstiegsskripte zu bearbeiten.

Weitere Verzeichnisse enthalten E-Mail-Vorlagen, PDF-Vorlagen, Lokalisierungsdaten, Uploads und Dateien herunterladbarer Produkte. Beziehen Sie deren Geschäftsdaten in Ihren Backupplan ein: Uploads und herunterladbare Produkte sind kein entbehrlicher Cache.

Dateien anhand Ihrer Aufgabe finden

Erfassen Sie für eine Fehlermeldung die Seite oder Aktion, den Zeitpunkt des Fehlers mit Zeitzone, die Version und einen relevanten, geschwärzten Protokollauszug. Senden Sie keine vollständige Konfigurationsdatei, um zu belegen, welche Datenbank verwendet wird.

Legacy- und modernen Code unterscheiden

Beispiele tatsächlicher Suchpfade für Legacy-Code:

classes/Product.php
classes/Category.php
classes/Cart.php
classes/Customer.php
classes/ObjectModel.php
classes/order/Order.php
classes/module/Module.php
classes/db/Db.php
classes/shop/Shop.php
classes/tax/Tax.php
classes/stock/StockAvailable.php

ObjectModel ist die Basis des älteren Active-Record-Modells. Es bietet Persistenz- und Validierungsmethoden für davon abgeleitete Klassen. Moderne Doctrine-Entitäten erweitern nicht alle ObjectModel.

Zu den Frontoffice-Controllern gehören controllers/front/ProductController.php, CategoryController.php, CartController.php, OrderController.php, CmsController.php und SearchController.php. Ältere Admin-Controller liegen unter controllers/admin/; eine migrierte Seite kann stattdessen einen Symfony-Controller verwenden.

Innerhalb von src/ verbindet Adapter/ ältere Funktionen, Core/Domain/ organisiert Domänenbefehle und -abfragen, und PrestaShopBundle/ enthält Symfony-Controller, Entitäten, Formulartypen, Übersetzungs- und Twig-Integration. Genaue Unterverzeichnisse und Routen variieren je nach Version.

In PrestaShop 9.1 enthält app/ separate Admin-, Front- und Admin-API-Kernel sowie Anwendungskonfiguration. Nehmen Sie nicht an, dass ein älteres AppKernel.php-Diagramm jeden Anfragepfad beschreibt.

PrestaShop 1.6 nutzt eine andere Übersicht: classes/, controllers/, modules/, themes/, override/, config/, cache/ und log/. Es hat nicht die übliche moderne Struktur mit src/, app/ und var/cache/. Vergleichen Sie bei der Pflege eines alten Shops den offiziellen 1.6-Quellbaum.

Ein Modul nach Zuständigkeiten gliedern

Die Hauptdatei verwendet den technischen Namen des Modulverzeichnisses. Beispielsweise enthält modules/cataloghelper/cataloghelper.php die entsprechende, von Module abgeleitete Modulklasse. Halten Sie dort Metadaten, Lebenszyklus-Einstiegspunkte und Hook-Anbindung.

modules/cataloghelper/
  cataloghelper.php
  config.xml
  logo.png
  composer.json
  controllers/
    front/
    admin/
  src/
    Service/
    Repository/
    Form/
    Installer/
  config/
  views/
    templates/
      front/
      admin/
      hook/
    css/
    js/
    img/
  translations/
  upgrade/
  vendor/

Dies ist ein Beispiel, keine verpflichtende Sammlung leerer Ordner, und ein fehlender optionaler Ordner ist kein Beweis für eine defekte Installation. Ein kleines Modul, das nur Hooks nutzt, braucht eventuell nur seine Hauptdatei und eine Vorlage. Ergänzen Sie Verzeichnisse, sobald ihre Aufgaben entstehen. Siehe die offiziellen Anforderungen an die Modulstruktur.

• Controllers: validieren Anfragen, rufen Services auf, weisen Daten zu und geben Antworten zurück. Halten Sie wiederverwendbare Preis-, Import- oder API-Logik außerhalb des Controllers, damit auch Hooks und Jobs sie aufrufen können.
• src: Platzieren Sie hier wiederverwendbare Services, Validatoren, Repositories, Installer und Integrationsclients mit einem passenden Autoloader. Moderne Controller und Servicedefinitionen können Symfony-Integration nutzen, wenn die Zielversion sie unterstützt.
• views: Trennen Sie Front-, Admin- und Hook-Templates. Rendern Sie vorbereitete Daten; halten Sie Datenbankabfragen und Geschäftsberechnungen aus Templates fern. Dokumentieren Sie, wie SCSS- oder JavaScript-Quellen die ausgelieferten Assets erzeugen.
• translations: Decken Sie Beschriftungen, Fehler, E-Mails, Hilfe- und Frontoffice-Texte über das unterstützte Übersetzungssystem ab.
• config.xml und logo.png: Halten Sie die Version des zwischengespeicherten Deskriptors mit der Versionseigenschaft des Moduls konsistent und liefern Sie das in Listen verwendete Symbol mit.

Ein Front-Controller unter controllers/front/display.php mit der zugehörigen Klasse CataloghelperDisplayModuleFrontController lässt sich über den Link-Builder adressieren, beispielsweise mit Modul-, Controller- und fc=module-Parametern. Nutzen Sie generierte Links zur Kompatibilität mit benutzerfreundlichen URLs.

Ältere Admin-Controller benötigen passende Tab- und Zugriffsintegration. Ein moderner Admin-Controller verwendet eine Route und Berechtigungskonfiguration. Ein Verzeichnisname allein macht eine Adminseite weder erreichbar noch fügt er sie ins Menü ein.

Abhängigkeiten und gezielte Upgrades ausliefern

Die Installation erstellt anfängliches Schema, Konfiguration, Tabs und Hook-Registrierungen. Versionierte Dateien in upgrade/ aktualisieren bestehende Installationen. Ein Skript wie upgrade-1.2.0.php kann upgrade_module_1_2_0($module) bereitstellen und ein zutreffendes Erfolgsergebnis zurückgeben.

Prüfen Sie bei einer zusätzlichen Prioritätsspalte und einem neuen Medien-Hook vor dem Hinzufügen der Spalte das bestehende Schema, registrieren Sie den Hook und melden Sie einen Fehler, wenn ein erforderlicher Schritt scheitert. Ein teilweises Deployment kann die Spalte hinterlassen, obwohl ein späterer Schritt fehlschlug. Gestalten Sie das Skript so, dass eine Wiederholung diesen Zustand behandelt.

Halten Sie destruktive Schemaänderungen und Datenumwandlungen explizit. Ein unterstützter Integritätsschutz kann deklarierte additive Reparaturen behandeln, Laufzeitprüfungen ersetzen aber keine Upgrade-Planung.

Benötigt das Modul vendor/autoload.php, nehmen Sie die erforderlichen Produktionsabhängigkeiten ins Release-ZIP auf. Ein gewöhnlicher Händlerupload führt Composer nicht für Sie aus. Bauen Sie Abhängigkeiten für die unterstützte PHP-Zielversion, schließen Sie reine Entwicklungspakete aus dem Produktionsartefakt aus und testen Sie das genaue ZIP.

Korrigieren Sie Abhängigkeiten in ihrer gepflegten Quelle und aktualisieren Sie dann das nutzende Modul. Manuelle Änderungen innerhalb von vendor/ können beim nächsten Build verschwinden.

Templates und PHP-Overrides getrennt verfolgen

In PrestaShop 1.7, 8 und 9 enthält ein Theme typischerweise config/theme.yml, Templates, Assets und ein Verzeichnis modules/ für Overrides von Modultemplates. Front-Templates können in Verzeichnisse für Katalog, Checkout, CMS, Kunde, Teilvorlagen und Layout gegliedert sein.

Verwenden Sie ein Child-Theme für Änderungen, die Updates des übergeordneten Themes überstehen sollen; unterstützt Ihr Theme eines, behandelt der Leitfaden zu Child-Themes die Einrichtung. Prüfen Sie das aktive Theme unter Design > Theme & Logo. Ein passendes Modultemplate im aktiven Theme kann Vorrang vor dem eigenen Template des Moduls haben.

PrestaShop 9.0 verwendet standardmäßig Classic. Hummingbird wird mit 9.1 zum Standard, während Classic verfügbar bleibt, wie in den Versionshinweisen zu Hummingbird 2.0 beschrieben. Prüfen Sie Framework und Assets des installierten Themes, statt die Bootstrap-Version aus der Core-Hauptversion abzuleiten.

Ein PHP-Override ändert Legacy-Verhalten. Kompatible Modulerweiterungen können in der installierten Override-Klasse zusammengeführt werden; doppelte Methoden- oder Eigenschafts-Overrides können jedoch die Installation scheitern lassen. Es gibt keine allgemeine Regel „das letzte Modul gewinnt“.

Legacy-Overrides werden in PrestaShop 9 weiterhin unterstützt. Bevorzugen Sie einen geeigneten Hook, Service-Dekoration, ein Event oder einen modulgehörigen Controller, wenn diese den benötigten Erweiterungspunkt bieten. Siehe die PrestaShop-Dokumentation zu Overrides und unseren Leitfaden zu Hooks und Overrides.

Beispiel: Eine Modulvorlagenänderung bleibt wirkungslos

1. Bestätigen Sie, dass Sie den aktiven Shop und das aktive Theme einschließlich des relevanten Multistore-Kontexts prüfen und dass die bereitgestellte Datei diejenige ist, die Sie bearbeitet haben.
2. Suchen Sie das Template des Moduls und prüfen Sie, ob das aktive Theme oder sein übergeordnetes Theme eine weitere Kopie liefert.
3. Bestätigen Sie auf Staging, welches Template tatsächlich ausgewählt wird. Ein übereinstimmender Dateiname allein reicht nicht.
4. Nehmen Sie die beabsichtigte Änderung am unterstützten Ort für Anpassungen vor, folgen Sie dann dem Cacheverfahren unten und testen Sie die Seite.

Zugangsdaten und Bootstrap-Einstellungen finden

config/config.inc.php ist Core-Bootstrap-Code. Er lädt Definitionen, Autoloading und bootstrap.php; er ist keine vom Installer erzeugte Zugangsdaten-Datei.

Moderne Installationen ab 1.7 nutzen app/config/parameters.php für Installationsparameter einschließlich Datenbankzugangsdaten und Schlüssel. Historische Installationen können eine Verarbeitung von parameters.yml haben. Älteres 1.6 nutzt gewöhnlich config/settings.inc.php.

Halten Sie Dateien mit Zugangsdaten und deren Backups privat. Prüfen Sie, ob eine Datei existiert, ohne ihre Werte auszugeben, und halten Sie ihren Inhalt aus Tickets, Screenshots und öffentlichen Downloads heraus. Bewahren Sie Installationsschlüssel bei einem Umzug; geänderte Schlüssel können Sitzungen und geschützte Anwendungswerte beeinträchtigen.

config/defines.inc.php enthält Definitionen wie _PS_MODE_DEV_. Der Bootstrap leitet _PS_CACHE_ENABLED_ vom Installationsparameter ps_cache_enable ab. Dies sind getrennte Einstellungen.

Aktivieren Sie Entwicklungsdiagnosen auf einer geschützten Staging-Umgebung. Zeigen Sie Kunden keine detaillierten Exception-Seiten oder Debug-Werkzeugleisten: Beginnen Sie mit den Protokollen und reproduzieren Sie auf Staging, und versehen Sie jede Diagnoseänderung im Produktivsystem mit einem kontrollierten Verfahren und einer klaren Rückkehr zum Normalbetrieb.

Cache, Protokolle und Deployment-Berechtigungen verwalten

Moderne Caches liegen unter var/cache/, einschließlich umgebungsspezifischer Symfony- und Smarty-Daten. Unter 1.7 hängen Cache- und Protokollorte von der Minor-Version ab; prüfen Sie daher die installierte Struktur. Verwenden Sie Erweiterte Einstellungen > Leistung > Cache leeren oder den unterstützten Konsolenbefehl im Shop-Stammverzeichnis:

php bin/console cache:clear --env=prod

Ein Cachevorgang über die Kommandozeile ist eine Bereitstellungsaufgabe: Bestätigen Sie, dass die Version den Befehl bereitstellt, und führen Sie Wartungsarbeiten mit der richtigen PHP-Binärdatei, Umgebung und dem richtigen Anwendungsbenutzer der Bereitstellung aus. Stellen Sie sicher, dass neu erzeugte Cachedateien für PHP zugänglich bleiben. Löschen Sie nicht das gesamte Verzeichnis var/, um Platz zu schaffen: Es kann neben Caches auch Protokolle, Sitzungen und Laufzeitdaten von Modulen enthalten. Löschen Sie auch nicht das gesamte 1.6-Verzeichnis cache/, und kopieren Sie keine erzeugten Container zwischen Versionen. Schlägt das Leeren des Caches fehl, sichern Sie die Fehlermeldung und prüfen Sie Berechtigungen und das Verfahren der Version, statt wiederholt Ordner zu löschen.

Erscheint eine Änderung nicht, gehen Sie die möglichen Ursachen der Reihe nach durch:

1. Bestätigen Sie, dass die vorgesehene Quelldatei die aktive Version erreicht hat.
2. Bestätigen Sie das aktive Theme, das überschriebene Template oder den Code, der die Anfrage tatsächlich bedient, sowie die gewählte Umgebung.
3. Prüfen Sie Anwendungscaches, Browser- und Proxy-Caches, CDN-Caches und den PHP-OPcache. Das Leeren eines Caches beweist nicht, dass die anderen aktualisiert wurden.
4. Proben Sie die unterstützte Aktualisierung auf Staging mit vorbereitetem Backup und Rollback und prüfen Sie etwaige Fehler bei der Neuerzeugung.
5. Prüfen Sie die Seite erneut und dokumentieren Sie das funktionierende Bereitstellungsverfahren.

Das Verhalten des OPcache hängt von seinen Servereinstellungen ab und kann ein autorisiertes Zurücksetzen oder einen Neustart der PHP-Worker erfordern.

Suchen Sie in var/logs/ nach konfigurierten Anwendungsprotokollen und prüfen Sie auch PHP-FPM-, Webserver- und Modulprotokolle; Ihr Hoster speichert PHP- und Webserverprotokolle eventuell außerhalb des Shopverzeichnisses. Eine einzelne Datei prod.log ist kein universelles Ziel für jeden PHP- oder Modulfehler; ein leeres Protokoll beweist daher erst dann, dass kein Fehler aufgetreten ist, wenn Sie das konfigurierte Ziel geprüft haben. Archivieren Sie für die Diagnose benötigte Protokolle, bevor Sie eine Aufbewahrungsbereinigung anwenden.

Ist der Speicherplatz das Problem, ermitteln Sie zuerst, was wächst. Protokolle erfordern eine Aufbewahrungsentscheidung, Bilder, Uploads und Downloads eine Prüfung von Zuständigkeit und Verweisen, der Cache das unterstützte Verfahren der Version.

Quelldateien müssen für den PHP-Worker lesbar sein; sie müssen nicht alle dem Webserverbenutzer gehören oder von ihm beschreibbar sein. Ein separater Bereitstellungsbenutzer kann den Code verwalten. Es gibt keinen universellen Webserver-Benutzernamen und keinen universellen Befehl für Eigentümerrechte, der für jeden Host passt: Bestätigen Sie Bereitstellungskonto, PHP-Prozessbenutzer und Zugriffsmodell mit dem Hosting-Administrator. Gewähren Sie Schreibzugriff nur dort, wo Uploads, Installation oder Laufzeiterzeugung ihn erfordern, mit dem tatsächlichen Benutzer- und Gruppenmodell. Vermeiden Sie Berechtigungen, die für alle beschreibbar sind.

Bilder und Übersetzungen finden

Produktbildpfade verwenden die Bild-ID, die sich von der Produkt-ID unterscheidet. Bild 123 kann ein Original unter img/p/1/2/3/123.jpg und erzeugte Größen wie 123-home_default.jpg in diesem Verzeichnis haben. Ein Produkt kann mehrere Bild-IDs besitzen.

Weitere Verzeichnisse sind img/c/ für Kategorien, img/m/ für Marken, img/s/ für Lieferanten, img/cms/ für Editorinhalte und img/tmp/ für temporäre Dateien. Erzeugte Endungen und Bildformate hängen von Version und Einstellungen ab, und eine Medien- oder Speicherintegration kann den beobachteten Pfad ändern.

Sichern Sie Bildoriginale. Die Neuerzeugung von Vorschaubildern unter Design > Bildeinstellungen benötigt diese Originale; verlorene Fotos lassen sich damit nicht wiederherstellen. Testen Sie die Neuerzeugung an einem geeigneten Stapel vor einem großen Katalogvorgang.

Beginnen Sie bei einem fehlenden Bild mit einem betroffenen Produkt und seinem tatsächlichen Bildverweis. Vergleichen Sie die angefragte URL mit dem Bilddatensatz, der Originaldatei und der benötigten erzeugten Größe, und prüfen Sie dann Dateieigentümer und etwaige Medien- oder CDN-Integrationen. Erraten Sie die Bild-ID nicht aus der Produktnummer, benennen Sie keine Ordner um und erzeugen Sie nicht zuerst alles neu. Produktdateien und Kunden-Uploads benötigen eventuell auch eingeschränkten Zugriff.

Core-Übersetzungen nutzen gebiets- und sprachspezifische Ressourcen einschließlich XLIFF. Module können je nach Integration ältere PHP-Arrays oder das moderne Übersetzungssystem verwenden. Prüfen Sie Übersetzungsdomänen, Gebietsschema und Backoffice-Anpassungen, wenn der Wortlaut von einer Datei abweicht.

Die Installation oder der Import einer Sprache über International > Übersetzungen unterscheidet sich vom Export von Modulübersetzungen. Prüfen Sie, soweit verfügbar, den Modulexportbefehl mit:

php bin/console prestashop:translation:export-module --help

Der Befehl erwartet den technischen Namen des Moduls und kann ein Gebietsschema annehmen. Er exportiert die Übersetzungsressourcen des Moduls; er installiert kein Sprachpaket. Zur Backoffice-Seite von Sprachen siehe den Leitfaden zu Übersetzungen und internationalem Verkauf.

Die Datei hinter einer Funktion finden

1. Beginnen Sie mit Seiten-URL oder Route und identifizieren Sie den Controller.
2. Prüfen Sie bei einer Modulseite die Controller oder Routendefinitionen dieses Moduls.
3. Verfolgen Sie den aufgerufenen Service oder das ältere Modell zum tatsächlichen Pfad.
4. Verfolgen Sie die Template-Auflösung durch aktives Theme und Modul-Overrides.
5. Prüfen Sie Hook-Registrierungen und installierte PHP-Overrides, wenn das Verhalten vom Core abweicht.
6. Prüfen Sie nach einer kontrollierten Änderung Protokolle und Caches.

Diese rein lesenden Suchen aus dem Shop-Stammverzeichnis helfen, Anpassungen zu finden:

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

Eine Suche zeigt, welche Dateien existieren, nicht welche ausgeführt werden: Ein gefundener Override oder ein gefundenes Template braucht weiterhin die obigen Prüfungen, und das Entfernen von Dateien ist keine Abkürzung bei der Diagnose.

Halten Sie Änderungen, die Upgrades überstehen sollen, in gepflegten Modul- oder Theme-Quellen, unter Versionskontrolle und mit einem dokumentierten Bereitstellungsweg. Änderungen an Core und Abhängigkeiten können durch Updates überschrieben werden, und das Ersetzen einer vorhandenen Datei eines Moduls oder übergeordneten Themes birgt dasselbe Risiko. Auch ein individuelles Modul braucht über Upgrades hinweg Wartung und Tests.

Den Rückweg vorbereiten, bevor Dateien geändert werden

• Konfigurationsänderung: Schützen Sie eine Kopie der ursprünglichen Einstellungen, testen Sie auf Staging und behalten Sie einen Rückweg zu den vorherigen Werten. Beschränken Sie den Zugriff auf Backupkopien, die Geheimnisse enthalten.
• Code- oder Templateänderung: Halten Sie den Diff fest, spielen Sie ihn auf Staging ein, prüfen Sie den betroffenen Kunden- oder Mitarbeiterablauf und behalten Sie das vorherige bereitstellbare Release für ein Rollback.
• Entfernen von Dateien: Klären Sie, wem die Dateien gehören und ob Datenbankeinträge oder externe Dienste noch auf sie verweisen. Testen Sie den unterstützten Entfernungsprozess auf Staging mit einem wiederherstellbaren Backup; folgen Sie bei Modulen dem Leitfaden zur Modulentfernung, statt ein Verzeichnis zu löschen, um zu sehen, was passiert.

Aktualisieren Sie vor einer Live-Bereitstellung das Backup und vereinbaren Sie, wer den Betrieb wiederherstellen kann. Das Wiederherstellen alter Dateien und das Wiederherstellen einer alten Datenbank sind getrennte Vorgänge mit unterschiedlichen Auswirkungen, und Bestellungen oder Uploads, die nach dem Backup eingehen, müssen vor beiden gesichert werden. Kenntnis der Ordnerstruktur hilft Ihnen, eine präzise Frage zu stellen; sie ersetzt nicht das Bereitstellungsverfahren des Shops.

Bitten Sie die Agentur, das aktive Shop-Stammverzeichnis, die Übersicht über Version und Theme, die Orte der Anpassungen, die beschreibbaren Laufzeitorte sowie das benannte Backup- und Rollback-Verfahren zu übergeben.

Fragen von Shopbetreibern

Bedeutet ein Modulordner, dass das Modul installiert ist?

Nein. Prüfen Sie seinen Status im relevanten Shopkontext, seine Version im Vergleich zum Paket und seine Hook-Registrierungen. Übrig gebliebene Dateien allein zeigen weder, was läuft, noch ob eine Entfernung sicher ist.

Warum unterscheidet sich unsere Ordnerliste von diesem Leitfaden?

Version, Paketierung, Hosting und Bereitstellungsentscheidungen verändern die Struktur. Bestätigen Sie die aktive Installation, bevor Sie einen fehlenden Ordner anlegen, den Admin-Ordner umbenennen oder Dateien aus einer anderen Version kopieren, um einem Beispiel zu entsprechen.

Dürfen wir einen Ordner löschen, dessen Name temporär aussieht?

Nicht allein aufgrund seines Namens. Auch ein Verzeichnis mit temporär klingendem Namen kann Dateien enthalten, auf die Datensätze verweisen; prüfen Sie daher zuerst Zuständigkeit und Verweise und folgen Sie dem Schritt zum Entfernen von Dateien oben.