Testbestellungen löschen: So bereinigen Sie PrestaShop vor dem Livegang

Geprüft und aktualisiert im Juni 2026 — das Fehlen einer nativen Aktion zum Löschen von Bestellungen und das Zurücksetzen des Rechnungszählers wurden in PrestaShop 1.7, 8 und 9 verifiziert.

Am Tag vor dem Start gleicht Ihre PrestaShop-Datenbank einem Tatort, den Sie selbst hinterlassen haben. Sie haben Bestellungen aufgegeben, um die Versandkosten zu testen, eine Karte zweimal durch das Zahlungs-Gateway laufen lassen, um sicherzugehen, „asdf asdf“ angelegt, um das Adressformular zu prüfen, und jeden Bestellstatus ausgelöst, um zu sehen, ob die E-Mails versendet werden. All das hat funktioniert — und genau das ist das Problem. Jede dieser Testbestellungen steckt jetzt in Ihren Statistiken, Ihrer Rechnungsnummernfolge und Ihrer Kundenliste. Am ersten Morgen mit echten Verkäufen liefert sie Ihnen unbemerkt falsche Signale darüber, wie der Shop läuft. In diesem Leitfaden geht es um eine ganz konkrete Aufgabe: Testbestellungen sauber zu entfernen, bevor Sie live gehen, und zwar in einem Shop, der noch nie eine echte Bestellung erhalten hat — denn sobald echte Bestellungen und Rechnungen existieren, macht PrestaShop das Löschen aus rechtlichen und buchhalterischen Gründen bewusst schwierig.

Der Fokus ist absichtlich eng. Warenkörbe, Protokolle und Verbindungstabellen für die laufende Performance zu bereinigen, ist ein anderer Ablauf — der Unterschied zwischen „ich starte nächste Woche“ und „meine Datenbank ist zwei Jahre lang gewachsen“ — und wir trennen beides, damit Sie nur das löschen, was ein Start tatsächlich erfordert.

Warum eine übrig gebliebene Testbestellung teurer ist, als sie aussieht

Eine Bestellung zu löschen wirkt wie Kosmetik. Ist es aber nicht. In PrestaShop ist eine Bestellung nicht eine einzelne Zeile — sie ist ein kleines Geflecht aus Zeilen, verteilt über ein gutes Dutzend Tabellen, von denen mehrere Berichte und Zähler speisen, auf die Sie ab dem ersten Tag angewiesen sind. Lassen Sie sie stehen, geht konkret Folgendes schief:

• Ihre erste Umsatzkennzahl ist falsch, und Sie merken es nicht. Das Dashboard und die Statistik-Seiten summieren ps_orders (und ps_order_detail), ohne zu wissen, welche Zeilen nur zum Testen von Versandkosten dienten. Tagesumsatz, durchschnittlicher Bestellwert und Conversion-Rate werden alle durch Bestellungen aufgebläht, die nie stattgefunden haben. Genau in dem Moment, in dem Sie ein sauberes Signal brauchen — „verkauft der neue Shop wirklich?“ — sind Ihre Daten am schmutzigsten.
• Ihre erste echte Rechnung trägt die Nummer #38. Rechnungsnummern werden in PrestaShop aus einem laufenden Zähler vergeben, nicht aus der Bestellung selbst. Vierzig Testbestellungen, die Rechnungen erzeugt haben, verbrauchen vierzig Nummern. Die erste echte Rechnung für Ihre Buchhaltung ist dann eine Nummer irgendwo Mitte dreißig mit siebenunddreißig unsichtbaren Vorgängern. Genau solche Lücken fallen bei einer Steuerprüfung auf.
• Ihre Kundenliste ist mit Geistereinträgen durchsetzt. „Test User“, „asdf asdf“ und Ihre drei eigenen Wegwerfkonten stehen in ps_customer neben echten Menschen. Jedes Segment, jeder Export und jede Kennzahl zur „Anzahl der Kunden“ zählt sie mit. Exportieren Sie diese Liste in ein E-Mail-Tool, erhalten die Testadressen — falls Sie echte verwendet haben — Marketing-Mails.
• Lagerbestand wurde für Verkäufe bewegt, die nie stattgefunden haben. Wenn Ihre Testbestellungen mit aktivierter Lagerverwaltung auf echte Produkte liefen, hat jede davon eine Zeile in ps_stock_mvt geschrieben und die Menge reduziert. Löschen Sie die Bestellung schlecht, bleibt die Lagerbewegung bestehen, und Ihr Bestand zum Start ist unbemerkt falsch. (Das abzugleichen ist eine eigene Aufgabe für Bestandsdaten — siehe Bestandsverwaltung, wenn Tabellenkalkulationen nicht mehr ausreichen.)

Was heißt das praktisch? Eine Testbestellung, die Sie zu löschen vergessen, überfüllt nicht nur eine Ansicht — sie verfälscht die drei Dinge, die ein Start Ihnen liefern soll: eine ehrliche Umsatzzahl, eine saubere Rechnungsnummernfolge und eine Kundenliste, der Sie vertrauen können. Sie zu entfernen dauert etwa fünfzehn Minuten und verschafft Ihnen eine Datenbank, die Sie tatsächlich lesen können.

Es gibt keinen sauberen Button „Bestellung löschen“ — und das ist wichtig

Hier kommt die erste Überraschung: Das native PrestaShop (1.7, 8, 9) bietet Ihnen keine normale Backoffice-Aktion zum Löschen einer Bestellung. Bestellungen gelten als Finanzdatensätze und sollen aus Gründen der rechtlichen und buchhalterischen Integrität erhalten bleiben. Deshalb bieten die Massenaktionen und Zeilenmenüs, zu denen Sie greifen würden, schlicht kein „Löschen“ wie bei Produkt- oder Kundenlisten. Das ist Absicht, kein Versehen.

Genau deshalb ist der einzig sichere Weg, Testbestellungen zu entfernen, dies zu tun, bevor echte Bestellungen existieren. Ihre realistischen Optionen sind:

• Ein sauberes Backup von vor dem Start wiederherstellen. Der einfachste und sicherste Reset: Nehmen Sie den Snapshot von vor Ihren Tests und rollen Sie darauf zurück. Alles Weitere geht davon aus, dass Sie das lieber vermeiden möchten, aber diese Option hat kein Risiko verwaister Zeilen.
• Auf einer Staging-Datenbank arbeiten. Testen Sie auf einer Kopie und stellen Sie anschließend eine saubere Produktionsdatenbank bereit, die nie eine Testbestellung gesehen hat.
• Ein spezielles Modul oder Skript zur Bestellbereinigung verwenden. Eine Bestellung korrekt zu entfernen bedeutet, das gesamte Geflecht zugehöriger Zeilen abzugehen. Deshalb gehört diese Aufgabe in ein versionsgetestetes Werkzeug, nicht in eine von Hand geklickte Admin-Aktion. Führen Sie es nur in einem Shop ohne echte Bestellungen aus.

Und selbst wenn eine Bestellung entfernt wird (durch ein Modul oder durch PrestaShops eigene Objektlogik Order::delete()), bereinigt das nie alles, was die Bestellung in zweiter Reihe umgibt:

• Der Kunde (ps_customer) und seine Adressen (ps_address) — eine Bestellung zu entfernen löscht nie die Person, die sie aufgegeben hat. Ihre Scheinkunden bleiben erhalten.
• Der ursprüngliche Warenkorb (ps_cart, ps_cart_product) — der Warenkorb, aus dem die Bestellung wurde, bleibt als „abgebrochener“ Warenkorb zurück.
• Die Rechnungszeile (ps_order_invoice) und der Rechnungsnummernzähler — das Entfernen der Bestellung rollt die verbrauchte Nummer nicht zurück.
• Jede Lagerbewegung (ps_stock_mvt), die bereits für echte Produkte geschrieben wurde.

Das Entfernen von Bestellungen ist also nur der erste Schritt, nicht die ganze Aufgabe. Das Muster, das Sie wirklich sauber zurücklässt, lautet: Bestellungen im Pre-Launch-Shop entfernen, dann die zugehörigen Kunden und Warenkörbe löschen und anschließend die nächste Rechnungsnummer ausdrücklich setzen. Unten sehen Sie, wie Sie jeden Teil deterministisch erledigen.

Die Bereinigung vor dem Livegang, Schritt für Schritt

1. Zuerst die Datenbank sichern — ohne Ausnahme. Erstellen Sie einen echten Datenbank-Dump: mit dem Backup-Tool Ihres Hosters, mit phpMyAdmin oder Adminer oder per mysqldump, wenn Sie Shell-Zugriff haben. (Hinweis: Der SQL Manager unter Erweiterte Einstellungen dient dazu, gespeicherte Abfragen gegen Ihre Daten auszuführen, nicht dazu, ein vollständiges Backup zu erstellen — verlassen Sie sich dafür nicht darauf.) Das Entfernen von Bestellungen ist destruktiv und lässt sich nicht rückgängig machen. Wenn Sie etwas im weiteren Ablauf überrascht, stellen Sie wieder her und versuchen es erneut.
2. Eine verbindliche Liste der Testbestell-IDs erstellen. Sortieren Sie unter Bestellungen → Bestellungen nach Datum und identifizieren Sie jede Bestellung von vor dem Start. Notieren Sie den ID-Bereich — fast immer ist es am Anfang ein zusammenhängender Block (1 bis irgendwas). Die Falle dabei ist ein Soft Launch: Wenn Sie bereits echte frühe Bestellungen angenommen haben, sind diese IDs mit den Tests vermischt. Listen Sie die echten Bestellungen ausdrücklich auf, damit Sie nie einen zahlenden Kunden löschen.
3. Die Bestellungen entfernen. Da das native PrestaShop keine Backoffice-Aktion zum Löschen von Bestellungen bietet, braucht dieser Schritt ein spezielles Bereinigungsmodul oder ein kleines Skript, das für jede Test-ID Order::delete() aufruft — oder, am einfachsten, Sie stellen stattdessen Ihr sauberes Backup von vor dem Start wieder her. Tun Sie das nur in einem Shop ohne echte Bestellungen.
4. Die Testkunden löschen. Gehen Sie zu Kunden → Kunden, suchen Sie die offensichtlich gefälschten Konten und löschen Sie sie — dadurch werden auch deren Adressen entfernt. Achten Sie wieder auf Käufer aus einem Soft Launch, die Sie behalten möchten.
5. Die nächste Rechnungsnummer ausdrücklich auf 1 setzen. Gehen Sie zu Bestellungen → Rechnungen und setzen Sie unter Rechnungsoptionen die Nächste verfügbare Rechnungsnummer auf 1 — tun Sie das nur in einem Shop, in dem noch nie eine echte Rechnung ausgestellt wurde, und bestätigen Sie, dass noch keine rechtliche Rechnungsnummernfolge begonnen hat. (Damit setzen Sie die Startnummer direkt; erwarten Sie nicht, dass ein Wert von 0 automatisch „bei 1 startet“.) Machen Sie dasselbe für die Lieferscheinnummerierung, falls Sie Lieferungen getestet haben (Bestellungen → Lieferscheine). Das ist der Schritt, den fast jeder vergisst, und genau der, den Ihre Buchhaltung bemerkt — wenn aber bereits echte Rechnungen existieren, lassen Sie die Nummernfolge unverändert und klären Sie stattdessen Ihre buchhalterischen Anforderungen.
6. Den Cache leeren. Erweiterte Einstellungen → Leistung → Cache leeren. Zähler und Listenansichten werden zwischengespeichert; ohne diesen Schritt kann der Adminbereich weiterhin veraltete Summen anzeigen.
7. Anhand der Zahlen prüfen, nicht anhand Ihrer Erinnerung. Öffnen Sie Bestellungen → Bestellungen (sollte leer sein oder nur echte Soft-Launch-Bestellungen enthalten), Kunden und das Dashboard. Wenn der Umsatz nicht null ist (oder nicht Ihrer tatsächlichen Soft-Launch-Zahl entspricht), wurde etwas nicht gelöscht — gehen Sie vor dem Start mit unsauberen Daten zurück zu Backup und Liste.

Wenn Sie Dutzende Testbestellungen haben: der SQL-Weg

Fünfzig Bestellungen einzeln durchzuklicken ist mühsam und fehleranfällig. Wenn Sie sich in Erweiterte Einstellungen → Datenbank → SQL Manager auskennen (für schreibgeschützte Untersuchungsabfragen ist das in Ordnung), können Sie die Testdaten zumindest präzise eingrenzen — aber wie der nächste Abschnitt erklärt, sollte das eigentliche Entfernen über getesteten Code laufen, nicht über ein von Hand geschriebenes DELETE. Der Grund liegt im PrestaShop-Schema: Viele Tabellen haben keine kaskadierenden Fremdschlüssel. Löschen Sie zuerst den übergeordneten Datensatz, verwaisen die Kinddatensätze, statt mit entfernt zu werden, und die vollständige Menge der zugehörigen Tabellen wird leicht unterschätzt.

Finden Sie zuerst die Testbestellungen, damit Sie mit echten IDs arbeiten, nicht mit Vermutungen. Zum Beispiel alles, was vor Ihrem Startdatum aufgegeben wurde:

SELECT id_order, reference, total_paid, date_add FROM ps_orders WHERE date_add < '2026-06-13 00:00:00' ORDER BY id_order;

Bevorzugen Sie klar, PrestaShops eigene Order::delete()-Logik die Kindzeilen behandeln zu lassen (aus einem kleinen Skript heraus über Ihre Test-IDs), statt die Löschung von Hand zu schreiben. Eine echte PrestaShop-Bestellung berührt weit mehr als das offensichtliche halbe Dutzend Tabellen — Bestelldetails und Verlauf, aber auch Versanddienstleister zur Bestellung, Bestellnachrichten, Rücksendungen und Belege, Anpassungen, Rechnungen, Steuern und ps_order_payment-Zeilen, die über die Bestellreferenz verknüpft sind statt über einen sauberen id_order-Kindlink — plus alle modulinternen Tabellen, die Ihre Installation hinzufügt. Genau deshalb ist eine handgeschriebene DELETE-Liste gefährlich: Jede Tabelle, die Sie vergessen, wird zu einer unsichtbaren verwaisten Zeile.

Deshalb gibt Ihnen dieser Leitfaden bewusst kein teilweises SQL-Rezept nach dem Motto „löschen Sie diese N Tabellen in dieser Reihenfolge“ — ein solches Rezept wäre für fast jeden echten Shop unvollständig. Nutzen Sie die Objektlogik (Order::delete()) oder ein versionsgetestetes Bereinigungsskript, das jede zugehörige Tabelle erfasst, einschließlich der Zahlungszeilen, die es über die Referenz nachschlagen muss. Danach bereinigen Sie die Satelliten separat — Kunden, Warenkörbe, Rechnungszähler.

Was heißt das praktisch? Eine zugehörige Tabelle auszulassen ist keine Spitzfindigkeit — machen Sie es falsch, bleiben unsichtbare verwaiste Zeilen zurück, die Berichte weiter verfälschen, obwohl im Adminbereich alles gelöscht aussieht. Genau diesen Fehler soll die ganze Übung verhindern, und deshalb stützen wir uns auf getesteten Code statt auf einen SQL-Block zum Kopieren.

Eine ehrliche Einschränkung: Das Leeren der Bestelltabellen (TRUNCATE ps_orders und verwandter Tabellen) ist die brachiale Option, die Sie online vorgeschlagen finden. Sie ist schnell und setzt Auto-Increment-IDs auf 1 zurück — attraktiv für einen Start —, aber sie umgeht jede Schutzschicht, berührt die Satellitentabellen nicht und zerstört ohne Weiteres eine Soft-Launch-Bestellung. Ziehen Sie das nur in einem Shop ohne echte Daten in Betracht und nur mit einem Backup, dessen Wiederherstellung Sie geprüft haben.

Demo-Daten gleich mit bereinigen

Testbestellungen blockieren den Start, aber wenn Sie PrestaShop mit Demo-Daten installiert haben, ist der Beispielkatalog ein eigenes Pre-Launch-Problem — und es lohnt sich, ihn in derselben Sitzung zu erledigen. Mit Demo-Daten installiert kann PrestaShop Beispielprodukte, Kategorien, Lieferanten, Marken und CMS-Seiten enthalten (die Platzhalter „Delivery“, „Legal Notice“, „About us“) — welche genau vorhanden sind, hängt von Version, Distribution und Sprache ab. Sie stehen zu lassen birgt zwei Risiken: Ein echtes Produkt landet versehentlich in einer Demo-Kategorie, und Google indexiert eine Seite „Terms and conditions“, die noch Lorem-ipsum-Text enthält.

Entfernen oder überarbeiten Sie unter Katalog und Design → Seiten: die Demo-Produkte und -Kategorien sowie die Platzhalter-CMS-Seiten (ersetzen Sie sie durch Ihre echten Rechtstexte, blenden Sie sie nicht nur aus). Tun Sie das über das Backoffice oder einen kontrollierten Importprozess — löschen Sie nicht von Hand Dateien unter /img, denn dort liegen Ihre Live-Bilder für Produkte, Kategorien, Marken, Lieferanten, Theme und System, nicht nur Demo-Bilder. Wenn Sie die Demo-Produkte über das Backoffice entfernen, werden ihre Bilddatensätze auf sichere Weise bereinigt. Wenn Sie danach Speicherplatz zurückgewinnen möchten, regenerieren oder entfernen Sie ungenutzte Bilder nur mit einem Backup in der Hinterhand. Wenn Sie mit einem großen Demo-Katalog starten und Ihren echten Katalog importieren, ist die saubere Umsetzung per CSV eine eigene Aufgabe — siehe Produktimport und -export in PrestaShop.

Vorbeugung: So entsteht das Chaos beim nächsten Mal gar nicht erst

Sie werden wieder testen — bei jeder Theme-Änderung, jedem Update eines Zahlungsmoduls und jedem PrestaShop-Upgrade. Ziel ist, dass künftige Tests keine Rückstände in Ihren Live-Daten hinterlassen:

• Testen Sie auf einer Staging-Kopie, nicht im Live-Shop. Eine duplizierte Installation, in der jede Testbestellung, jede Erstattung und jede Statusänderung abseits der Produktion passiert. Das ist der größte einzelne Gewinn: Ihre Live-Tabelle ps_orders enthält ausschließlich echte Verkäufe, also gibt es nichts zu bereinigen.
• Nutzen Sie den Sandbox-Modus für Zahlungen. Stripe, PayPal und die meisten Zahlungsanbieter bieten Test- oder Sandbox-Schlüssel, mit denen Scheingeschäfte ohne echte Belastung verarbeitet werden. Testen Sie den Kassenablauf, ohne jemals eine Live-Karte zu verwenden — und denken Sie daran, jedes Gateway vor dem Start wieder in den Live-Modus zu schalten (ein vergessener Sandbox-Schlüssel ist der spiegelbildliche Startfehler).
• Markieren Sie den unvermeidbaren Live-Test. Wenn Sie gegen die Produktion testen müssen, verwenden Sie eine erkennbare Markierung — einen Kunden namens ZZ-TEST, ein eigenes E-Mail-Muster, eine Notiz in der Bestellung — damit ein einziger sortierbarer Filter jede Testzeile zum Löschen sichtbar macht. Der Sinn klar markierter Testbestellungen hängt damit zusammen, wie Sie generell mit Bestellstatus umgehen; wenn Sie Status-E-Mails immer wieder testen, behandelt Anpassung und Automatisierung von Bestellstatus-Workflows die Automatisierung dieser Übergänge.

Häufig gestellte Fragen

Wie lösche ich eine Testbestellung in PrestaShop?

Das native PrestaShop (1.7, 8, 9) hat keine Backoffice-Aktion „Bestellung löschen“ — Bestellungen gelten als Finanzdatensätze und werden bewusst erhalten. Der einzig sichere Weg, Testbestellungen zu entfernen, ist vor der Existenz echter Bestellungen: Stellen Sie ein sauberes Backup von vor dem Start wieder her, stellen Sie eine Staging-Datenbank bereit, die nie eine Testbestellung gesehen hat, oder führen Sie ein versionsgetestetes Bereinigungsmodul beziehungsweise Skript aus, das Order::delete() über Ihre Test-IDs aufruft. Sichern Sie zuerst die Datenbank; das Entfernen von Bestellungen ist destruktiv und lässt sich nicht rückgängig machen.

Warum beginnt meine erste echte Rechnung mit Nummer 38 statt mit 1?

Rechnungsnummern kommen aus einem laufenden Zähler, nicht aus der Bestellung. Jede Testbestellung, die eine Rechnung erzeugt hat, hat also eine Nummer verbraucht. Gehen Sie nach dem Entfernen der Tests zu Bestellungen → Rechnungen → Rechnungsoptionen und setzen Sie die Nächste verfügbare Rechnungsnummer auf 1 — aber nur in einem Shop, in dem noch nie eine echte Rechnung ausgestellt wurde. Ein Wert von 0 startet nicht automatisch „bei 1“; setzen Sie die Startnummer direkt. Wenn bereits echte Rechnungen existieren, lassen Sie die Nummernfolge unverändert.

Entfernt das Löschen einer Bestellung auch den Kunden und den Warenkorb?

Nein. Das Entfernen einer Bestellung löscht nie die Person, die sie aufgegeben hat (ps_customer), oder ihre Adressen (ps_address), und der Warenkorb, aus dem die Bestellung wurde, bleibt als „abgebrochener“ Warenkorb (ps_cart) zurück. Es rollt auch weder den Rechnungsnummernzähler noch bereits geschriebene Lagerbewegungen zurück. Das Entfernen von Bestellungen ist also der erste Schritt, nicht die ganze Aufgabe — danach löschen Sie die Testkunden und Warenkörbe und setzen den Zähler separat zurück.

Kann ich einfach eine DELETE-Abfrage ausführen oder die Bestelltabellen per TRUNCATE leeren?

Vermeiden Sie das. Eine echte Bestellung berührt weit mehr als das offensichtliche halbe Dutzend Tabellen — Bestelldetails und Verlauf, Versanddienstleister, Nachrichten, Rücksendungen, Belege, Anpassungen, Rechnungen, Steuern und ps_order_payment-Zeilen, die über die Bestellreferenz statt über id_order verknüpft sind — plus modulinternen Tabellen. Ein handgeschriebenes DELETE, das eine davon vergisst, hinterlässt unsichtbare verwaiste Zeilen, die Berichte weiter verfälschen, obwohl im Adminbereich alles gelöscht aussieht. TRUNCATE ist schneller und setzt IDs auf 1 zurück, umgeht aber jede Schutzschicht und zerstört eine Soft-Launch-Bestellung. Verwenden Sie stattdessen Order::delete() oder ein getestetes Bereinigungsskript. Ein schreibgeschütztes SELECT, um die Test-IDs zuerst zu finden, ist in Ordnung.

Wie vermeide ich dieses Chaos beim nächsten Mal?

Testen Sie auf einer Staging-Kopie, nicht im Live-Shop — dann enthält Ihre Live-Tabelle ps_orders ausschließlich echte Verkäufe. Nutzen Sie den Sandbox- beziehungsweise Testmodus jedes Gateways für Zahlungstests (und denken Sie daran, jedes Gateway vor dem Start wieder auf live zu stellen). Wenn Sie gegen die Produktion testen müssen, markieren Sie die Bestellungen mit einem gut erkennbaren Merkmal (einem Kundennamen ZZ-TEST oder einem eigenen E-Mail-Muster), damit ein einziger sortierbarer Filter jede Testzeile zum Löschen sichtbar macht.

Wo das ins größere Bild passt

Testbestellungen zu löschen ist eine einmalige Startkontrolle. Die Gewohnheiten, die eine Bestelldatenbank nach dem Start sauber und vertrauenswürdig halten, sind eine eigene, laufende Disziplin — eine gelegentliche echte Bestellung korrigieren, die falsch herausging, per Bestellbearbeitung, einem Kunden, der seine Bestätigung verloren hat, über erneutes Senden von Bestellbestätigungen helfen, saubere Zahlen für die Buchhaltung mit CSV-Exporten für Bestellungen und Rechnungen ziehen und den täglichen Ablauf mit Bestellverwaltungs-Workflows, die Ihnen Stunden sparen in Bewegung halten.

Das Prinzip für den Starttag ist einfach: In Ihrer Datenbank sollten nur Bestellungen stehen, die ein Kunde tatsächlich aufgegeben hat. Entfernen Sie die Testbestellungen — in der richtigen Reihenfolge, mit zurückgesetztem Rechnungszähler und sicher beiseitegelegtem Backup — und die erste Umsatzzahl Ihres Shops sagt Ihnen die Wahrheit. Danach ist jeder saubere Bericht, den Sie lesen, eine kleine Belohnung für die fünfzehn Minuten, die Sie jetzt investiert haben. Wenn eine aufgeräumte Datenbank und verlässliche Statistiken dafür wichtig sind, wie Sie Ihren Shop führen, ist genau das die Art von Zuverlässigkeit im Hintergrund, für die unsere PrestaShop-Module gebaut sind.