Von PrestaShop zu einem eigenen Shop wechseln

Was PrestaShop ist, und wer es hinter sich lässt

PrestaShop ist eine quelloffene Shopsoftware in PHP. Du lädst sie herunter, installierst sie auf deinem eigenen Server, und sie läuft auf einer MySQL oder MariaDB Datenbank, die dir gehört.¹ Der Kern steht unter der Lizenz OSL 3.0, die mitgelieferten Module und das Classic Theme unter AFL 3.0, also kann niemand deinen Shop abschalten oder einen Anteil an deinem Umsatz nehmen.² In Europa ist PrestaShop seit Jahren verbreitet, besonders in Frankreich, Spanien, Italien und auch bei uns in Österreich, und für einen schlanken Shop mit einem gewöhnlichen Katalog ist es eine solide, fähige Plattform. Wenn das auf dich zutrifft, ist das kein Artikel, der dir das Weggehen einredet.

Der Shop, der aus PrestaShop herauswächst, geht meistens nicht, weil die Software nicht verkaufen könnte. Er geht wegen des Gewichts, das sich angesammelt hat. Ein echter PrestaShop Shop fährt in der Regel einen Turm aus Modulen, mehrere davon kostenpflichtig, und jedes muss mit den anderen und mit dem Kern kompatibel bleiben. Große Versionswechsel waren hart: Der Sprung von 1.6 auf 1.7 hat die Theme Architektur neu gebaut und begonnen, das Back Office auf Symfony umzustellen, und ein 1.6 Theme war mit 1.7 nicht kompatibel.³ Der Sprung von PrestaShop 8 auf PrestaShop 9, veröffentlicht am 10. Juni 2025, hat das Framework von Symfony 4.4 auf Symfony 6.4 gehoben, ältere PHP Versionen fallen gelassen, die alte Produktseite entfernt und die Bildung der Produkt URLs verändert, und das Projekt selbst warnt, dass Module und Themes dafür angepasst werden müssen.⁴ Nichts davon ist ein Skandal. Es ist der ehrliche Preis dafür, eine ausgereifte PHP Anwendung zu besitzen, die eine Kette aus Dritten mitpflegen muss.

Wer wechselt, ist also nicht unzufrieden mit dem Onlinehandel. Er ist die Pflege leid: die Modullizenzen, die alle zusammenpassen müssen, das Upgrade Projekt, das alle paar Jahre kommt, die Aufmerksamkeit für Hosting und Sicherheit, und der schrumpfende Kreis an Entwicklern, die an einer alternden Installation noch arbeiten wollen. Gewollt wird stattdessen eine einzige, getestete Anwendung, die man selbst kontrolliert, und genau das ist der Fall für einen maßgeschneiderten Solidus Shop.

Dieser Artikel ist die ehrliche Form dieses Umzugs. Die tiefen, plattformunabhängigen Details habe ich in einer Reihe von Begleittexten geschrieben, beginnend mit was sich überträgt und was nicht, und ich verlinke sie, statt sie zu wiederholen. Hier bleibe ich bei PrestaShop: was es sauber herausgibt, was es zurückhält, wie Export und API wirklich funktionieren, und die Fallen, die gerade für PrestaShop typisch sind.

Was dir gehört, und was zurückbleibt

Die große Stärke von PrestaShop als Plattform, die man verlässt, ist dieselbe wie die von WooCommerce: Weil du selbst hostest, hast du die Daten schon. Die Datenbank gehört dir, die Dateien gehören dir, und nichts steckt hinter einem Exportwerkzeug des Anbieters, das gedrosselt oder abgestellt werden kann. Der rohe Zugriff auf deine Datensätze ist damit sehr gut. Die Schwierigkeit ist nie, die Daten herauszubekommen. Sie ist, dass ein Teil davon in Modulen, Overrides und Formaten steckt, die nicht mitreisen, und dass ein paar Dinge aus Gründen, die keine Plattform ändern kann, gar nicht umziehen.

So sieht die ehrliche Aufteilung für einen typischen PrestaShop Shop aus.

Was sauber umzieht	Was Arbeit braucht oder gebunden ist	Wie ich es handhabe
Produkte, Kombinationen, Kategorien, Preise, Bilder, Lagerstand	Theme und Template Logik, die PrestaShop eigen ist	Neu gebaut als Solidus Storefront. Siehe die Produkt Spoke
Kundschaft, Adressen, Bestell und Rechnungshistorie	Passwörter, die gehasht und nie umkehrbar sind	Als Daten übernommen, Passwort wird einmal neu gesetzt. Siehe die Kunden Spoke
Suchmaschinenfreundliche URLs, für eine Weiterleitungskarte	Zahlungskonfiguration und gespeicherte Token, je Modul und je Gateway	Auf 301 Weiterleitungen abgebildet. Siehe die Token Spoke
Alles, was in MySQL lesbar ist	Geschäftslogik, vergraben in eigenen Modulen und Overrides	Neu umgesetzt als getesteter Rails Code
Abodatensätze, als Daten	Laufende Aboabrechnung, an ein Zahlungsmodul gebunden	Neu gebaut und bei Bedarf mit Hilfe des Gateways migriert. Siehe die Abo Spoke

Das Muster ist das, dem jede ehrliche Migration folgt. Die Hauptwörter ziehen gut um. Die Tätigkeitswörter, das Verhalten, das in Modulen und im Theme steckte, werden neu gebaut. Wem jeder dieser Datensätze rechtlich gehört, und warum das bei der Übergabe zählt, steht in wem gehören eigentlich deine Geschäftsdaten.

Der Export und die API, im Detail

PrestaShop gibt dir drei ehrliche Wege, Daten herauszuholen, und eine echte Migration nutzt alle drei.

Die CSV Import und Exportwerkzeuge. Unter den erweiterten Parametern gibt es ein eingebautes Importwerkzeug, das CSV Dateien für eine feste Auswahl an Entitäten liest: Kategorien, Produkte, Kombinationen, Kunden, Adressen, Marken, Lieferanten, Aliasse, Shop Kontakte, und Bestellungen an Lieferanten, wenn die erweiterte Lagerverwaltung an ist.⁵ Es ist ein wirklich nützliches Werkzeug, und es verrät durch die Form, die es erwartet, viel über das Datenmodell. Es hat auch Eigenheiten, die man kennen sollte, bevor man sich darauf verlässt. Das Trennzeichen ist ein Strichpunkt, also kämpft jeder Strichpunkt in deinem Text gegen den Parser. Jede Zeile muss gleich viele Spalten haben. Kategorien müssen vor den Produkten existieren, die sie referenzieren, also importierst du Kategorien zuerst über ihre ID. Jeder Import umfasst eine einzige Sprache, also müssen mehrsprachige Daten in je eine Datei pro Sprache getrennt werden. Bild URLs müssen absolut und erreichbar sein. Und es gibt eine Option, vor dem Import alles zu löschen, die genau das tut.⁵ Zum Herausholen exportiert die Produktliste im Katalog nach CSV, und für alles, was die Masken nicht abdecken, gehst du in die Datenbank.

Die Webservice API. PrestaShop bringt einen Webservice im REST Stil mit, standardmäßig abgeschaltet. Du schaltest ihn unter den erweiterten Parametern auf der Webservice Seite ein und legst dort einen Schlüssel an, und derselbe Schlüssel kann auf nur lesend gesetzt oder je Methode und je Ressource mit Rechten versehen werden, sodass du Kunden und Bestellungen zum Lesen freigibst, ohne irgendwo Schreibrechte zu erteilen.⁶ Die Authentifizierung ist HTTP Basic mit dem Schlüssel als Benutzernamen und ohne Passwort, der Schlüssel ist also das ganze Geheimnis und muss wie eines behütet werden. Die Doku empfiehlt, ihn in einem Authorization Header zu senden statt in der URL.⁷ Der Endpunkt liegt unter /api/ im Wurzelverzeichnis der Installation und braucht aktives URL Rewriting am Webserver. Ein Aufruf der Wurzel listet die Ressourcen auf, die dein Schlüssel erreichen darf, darunter customers, addresses, orders und order_histories.⁷ Ein Detail zählt für ein Migrationsskript: Der Webservice sprach historisch XML, und du stellst die Ausgabe mit einem Parameter output_format=JSON oder einem Output-Format Header auf JSON um, aber seit PrestaShop 8.1 gibt der Webservice nur noch JSON aus und kann JSON beim Schreiben weiterhin nicht lesen.⁷ PrestaShop 9 fügt eine eigene, neuere Admin API auf Basis von API Platform mit OAuth2 Token hinzu, die die Richtung vorgibt, vom Projekt aber noch als in Arbeit beschrieben wird.⁸ Eine plattformseitige Ratenbegrenzung, wie eine gehostete Plattform sie dir auferlegt, gibt es nicht: Die Grenze ist dein eigener Server, was in der Praxis heißt, dass du große Ressourcen seitenweise und außerhalb der Stoßzeiten abholst.

Direkter Datenbankzugriff. Weil der ganze Shop in deinem eigenen MySQL steckt, ist der vollständigste und verlässlichste Export schlicht, die Datenbank zu lesen. Für eine Migration behandle ich die Datenbank als die Quelle der Wahrheit und den Webservice als Bequemlichkeit, denn die Datenbank hält alles, auch die Modultabellen, die die API nie zeigt. Das ist der stille Vorteil einer selbst gehosteten Plattform, und der Grund, warum PrestaShop besser übergibt als jeder gehostete Mitbewerber.

Passwörter, und warum sie neu gesetzt werden

Hier rettet dich das Besitzen der Datenbank nicht. PrestaShop hasht die Passwörter von Kunden und Mitarbeitern. Es speichert sie nicht. Aktuelle Versionen hashen mit bcrypt, über PHPs password_hash und PASSWORD_BCRYPT, und akzeptieren beim Prüfen eines alten Hashs weiterhin ein älteres md5 Verfahren, damit alte Konten funktionieren.⁹ Seit PrestaShop 8.0 gibt es zusätzlich eine Passwortstärke Richtlinie auf Basis der Bibliothek zxcvbn.¹⁰ Ein bcrypt Hash lässt sich bauartbedingt nicht in das ursprüngliche Passwort zurückrechnen, es gibt also nichts mitzunehmen, womit sich eine Kundin mit ihrem bestehenden Passwort unverändert anmelden könnte.

Die ehrliche Folge: In einem maßgeschneiderten Solidus Shop setzt die Kundschaft ihr Passwort einmal neu, über einen einmaligen sicheren Link, beim ersten Besuch nach dem Umstieg. Als vorbereitete Servicenachricht statt als Überraschung am Starttag ist das ein Nichtereignis. Wie genau, steht in der Kunden Spoke, inklusive dem Erhalt der Einwilligungsnachweise und Adressen, sodass wirklich nur das Passwort neu ist.

Die Fallen, die gerade für PrestaShop typisch sind

Jede Plattform hat ihre eigenen Stellen, an denen eine Migration Zeit oder Geld verliert, wenn man sie nicht kommen sieht. Das sind die von PrestaShop.

Der Modulturm. Was einen PrestaShop Shop laufen lässt, ist selten der Kern allein. Es sind dreißig oder vierzig Module, mehrere davon kommerziell, gekauft über den offiziellen Marktplatz PrestaShop Addons.¹¹ Jedes bringt seine eigene Konfiguration mit, und manche halten echte Geschäftslogik: eine Preisregel, eine Versandberechnung, ein Treueprogramm. Beim Umzug zieht diese Logik nicht als Daten mit. Sie muss aus den Modulen herausgelesen, verstanden und neu gebaut werden. Die gute Nachricht ist, dass ein Neubau als getesteter Rails Code die Abhängigkeit für immer beendet. Die ehrliche Nachricht ist, dass das Finden all dessen die eigentliche Erkundungsarbeit ist, und ein Modul, an dessen Kauf sich niemand erinnert, ist genau dort, wo Überraschungen sitzen.

Overrides. PrestaShop erlaubt Entwicklern, Kernverhalten zu ändern, indem sie Dateien in einen Ordner override legen. Das ist ein vernünftiger Mechanismus, und es ist auch der Ort, an dem sich jahrelange undokumentierte Entscheidungen ansammeln. Vor einem Umzug durchsuche ich die Overrides und die eigenen Module nach Logik, von der das Geschäft abhängt und die sonst nirgends existiert, denn ein Override ist unsichtbar, bis es bricht.

Zahlungskonfiguration und Token. Zahlungen sind in PrestaShop Module, und jedes Zahlungsmodul speichert seine Konfiguration und seine gespeicherten Kartenverweise auf eigene Art. Es gibt keinen einzelnen, mitnehmbaren Export der gespeicherten Karten, weil die Kartendaten nie PrestaShop gehört haben. Sie liegen beim Zahlungsanbieter. Das sauberste Ergebnis ist, dasselbe Gateway zu behalten und den neuen Shop mit demselben Konto zu verbinden, damit gespeicherte Token gültig bleiben. Wo das Gateway wechselt, reisen gespeicherte Karten in der Regel nicht mit, und das flagge ich ganz am Anfang, nicht am Ende. Die tiefe Fassung steht in der Token Spoke, und die Risiken eines Gatewaywechsels überhaupt in die versteckten Gefahren beim Wechseln von Payment Gateways.

Abonnements. PrestaShop hat keine eingebaute wiederkehrende Abrechnung. Abos kommen aus einem Modul, und dieses Modul ist meist an ein Gateway gebunden, das das Mandat hält und die Abbuchungen ausführt. Abodatensätze lassen sich leicht genug als Daten exportieren, aber die laufende Abrechnungsbeziehung, das, was nächsten Monat wirklich Geld einzieht, ist der schwierigste Teil jeder Migration und braucht oft die Mitwirkung des alten Gateways, um ohne Unterbrechung für die Kundschaft umzuziehen. Es ist die erste Frage, die ich stelle, nicht die letzte. Die Abo Spoke behandelt die Optionen ehrlich.

URLs und SEO. PrestaShop baut suchmaschinenfreundliche URLs, und deine Platzierungen und Backlinks hängen an ihnen. PrestaShop 9 hat die Voreinstellung geändert, sodass Produkt URLs die Kategorie nicht mehr enthalten,⁴ eine Erinnerung daran, dass die URL Struktur eine Plattformentscheidung ist, in der du gelebt hast. In einem eigenen Shop entscheidest du die Struktur, und jede alte URL, die einen Besuch oder einen Link verdient hat, bekommt eine dauerhafte 301 Weiterleitung auf ihr neues Zuhause. Diese Weiterleitungskarte ist mühsame, eigene Arbeit, und sie zu überspringen ist der häufigste Weg, auf dem eine Migration still Besucher verliert. Die Mechanik steht in der Produkt Spoke.

Der ehrliche Umzug auf einen maßgeschneiderten Solidus Shop

Ein Weg weg von PrestaShop ist nicht ein Projekt, sondern fünf Stränge, und jeder bildet einen der Begleittexte ab.

Der Katalog ist der leichte Strang: Produkte, Kombinationen, Kategorien, Preise und Bilder aus MySQL gelesen, auf Solidus Produkte und Varianten abgebildet und geprüft. Kundschaft, ihre Adressen und die Bestellhistorie kommen als Datensätze mit, die Passwörter werden beim ersten Login neu gesetzt. Die Weiterleitungskarte macht aus jeder bedeutsamen alten URL eine 301. Zahlungen werden wo möglich mit demselben Gateway verbunden, damit Token überleben. Abonnements werden zuerst geplant, weil sie der eine Strang sind, der einen Start aufhalten kann.

Was neu gebaut statt migriert wird, ist die Storefront und die Geschäftslogik, die die Module getragen haben. Das ist der Teil, der im ersten Jahr Geld kostet, und zugleich der Teil, der danach aufhört, dich zu kosten, weil er zu deinem eigenen, getesteten Code wird, ohne Lizenz und ohne Anbieter zwischen dir und ihm. Ich beschreibe, wie jedes Merkmal am Ende einen ausführbaren Test hat, sodass du lesen kannst, was dein eigener Shop verspricht, und ich lege die ganze Rechnung über fünf Jahre, Besitzen gegen Mieten, in den Gesamtkosten über fünf Jahre dar und den Vergleich Plattform für Plattform in Solidus vs Shopify vs Shopware vs Magento vs WooCommerce. Weil WooCommerce die andere verbreitete, selbst gehostete quelloffene Plattform ist, die Leute gleichzeitig abwägen, steht ihr ehrlicher Ausstieg in von WooCommerce zu einem eigenen Shop wechseln.

Ein durchgerechnetes Beispiel

Machen wir es konkret mit einem erfundenen Unternehmen. Grazer Radteile (grazerradteile.example) ist ein Grazer Händler für Fahrradkomponenten und Verschleißteile, mit rund 9.000 Produkten und Kombinationen, starken Suchplatzierungen, über ein Jahrzehnt aufgebaut, und einer kleinen, treuen Aboseite: einem monatlichen Verschleißclub, bei dem Mitglieder einen festen Betrag zahlen und eine Box mit Kettenöl, Bremsbelägen und Schläuchen bekommen, abgebucht über ein Abomodul, das an ihre gespeicherte Karte gebunden ist. Der Shop läuft auf PrestaShop 1.7, trägt zweiundvierzig Module, elf davon kostenpflichtig, und die Inhaberin hat das Upgrade auf PrestaShop 8 zweimal verschoben, weil das Angebot sie erschreckt hat und zwei der kostenpflichtigen Module keine kompatible Version haben. Ihr Entwickler ist weitergezogen, und die neue Agentur will einen Retainer allein dafür, das Ding gepatcht zu halten. Sie ist nicht unzufrieden mit dem Verkaufen online. Sie ist unzufrieden mit der Pflege.

Bei einem ersten Blick trenne ich die Stränge nach Schwierigkeit, den schwersten zuerst. Der Verschleißclub ist der schwere: Ich muss wissen, welches Gateway die Mandate hält und ob es die gespeicherten Token umziehen lässt, denn wenn nicht, müssten Mitglieder ihre Karten neu eingeben, und das ist ein Gespräch, das man vor dem Bauen führt, nicht danach. Die gespeicherten Karten der gewöhnlichen Kundschaft sind dieselbe Frage in sanfterer Form. Diese zwei flagge ich am ersten Tag.

Alles andere ist beruhigend gewöhnlich. Die 9.000 Produkte und ihre Kombinationen kommen direkt aus MySQL, weit verlässlicher als über den Webservice, und bilden auf Solidus Produkte und Varianten ab. Kundschaft, Adressen und ein paar Jahre Bestellhistorie kommen als Datensätze mit, die Passwörter werden beim ersten Login mit einer vorbereiteten Nachricht neu gesetzt. Das Jahrzehnt an Platzierungen schützt eine Weiterleitungskarte, jede alte PrestaShop URL auf ihr neues Gegenstück gezeigt, was bei dieser Größe ein paar tausend Zeilen und zwei sorgfältige Tage sind. Die elf kostenpflichtigen Module werden auf die Logik gelesen, die zählt, die Clubpreise und ein Laufradkonfigurator darunter, und diese Logik wird als getesteter Code neu gebaut, der ihr allein gehört.

Das Ergebnis ist ein Solidus Shop, der wie ihre Marke aussieht, keine Modullizenzen trägt, den Verschleißclub als echtes Merkmal statt als gekauften Aufsatz hat, und morgen an jede Rails Entwicklerin übergeben werden kann. Der Aufbau kostet in ihrem ersten Jahr mehr als ein weiteres Jahr PrestaShop Pflege. Ab dem zweiten Jahr kostet er weit weniger, und die Angst vor dem Upgrade ist weg, weil eine getestete Rails Anwendung gepflegt und nicht in Abständen neu gebaut wird.

Wann du auf PrestaShop bleiben solltest

Mehreren Shops würde ich sagen, sie sollen bleiben. Wenn dein PrestaShop schlank ist, wenn es eine Handvoll Module fährt, die du verstehst und gepatcht hältst, wenn eine Entwicklerin, der du vertraust, es aktuell hält, und wenn Katalog und Checkout gewöhnlich sind, dann tut PrestaShop seine Arbeit und ein maßgeschneiderter Aufbau ist Geld, das ein Problem löst, das du nicht hast. Die Plattform ist wirklich gut darin, ein selbst gehosteter, eigener Shop für ein Unternehmen zu sein, dem die Pflege eines solchen behagt. Der ehrliche Auslöser für einen Wechsel ist nicht die Abneigung gegen PrestaShop. Es ist das Gewicht aus Modulen und Upgrades, das den Wert übersteigt, den sie zurückgeben, dazu ein echter Bedarf an Verhalten, das ein Modulturm nur annähert.

Wenn du der Shop bist, der herausgewachsen ist, dann halte dich an eines: Dein Datenzugriff ist schon gut. Du bist nicht gefangen. Du bist beschwert, und das ist eine weit bessere Lage, aus der man umzieht.

Wie ich deinen Umzug führe

Ich baue den maßgeschneiderten Solidus Shop und führe die Migration. Das Ergebnis gehört dir, Code und Daten, sobald es bezahlt ist. Ich beginne mit den zwei Fragen, die einen Zeitplan versenken können, den gespeicherten Karten und den laufenden Abos, und ich hole mir schriftliche Antworten von den Gateways, bevor eine Zeile Migrationscode geschrieben ist. Dann die gewöhnlichen Stränge: Katalog aus der Datenbank, Kundschaft und Bestellungen hinüber, die Weiterleitungskarte gebaut und getestet, die Modullogik mit Tests neu gebaut, und ein geprobter Umstieg, bei dem der alte Shop einen Monat lang unberührt als Rückfalllösung bleibt.

Wenn dich ein PrestaShop beschwert, das seine Pflege nicht mehr wert ist, bring es in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, welche Stränge für deinen Shop leicht und welche schwer sind, und wenn die ehrliche Antwort ist, dass dir ein schlankes PrestaShop weiterhin gute Dienste leistet, dann sage ich dir auch das.

Footnotes

1. PrestaShop Developer Documentation, Systemanforderungen (MySQL 5.7 mindestens oder MariaDB 10.2 mindestens), abgerufen am 14. November 2026, https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/ ↩

2. PrestaShop Project, Lizenz und Lizenzkompatibilität (Kern unter OSL 3.0, mitgelieferte Module und das Classic Theme unter AFL 3.0), abgerufen am 14. November 2026, https://www.prestashop-project.org/maintainers-guide/general-guidelines/license/ ↩

3. PrestaShop Project build blog, An update on the 1.7 architecture (der Wechsel auf das Symfony Framework und Twig, und das neue Theme nicht kompatibel mit 1.6), abgerufen am 14. November 2026, https://build.prestashop-project.org/news/2015/prestashop-1-7-and-symfony/ ↩

4. PrestaShop Project build blog, PrestaShop 9 is available (veröffentlicht am 10. Juni 2025, Symfony 4.4 auf 6.4, PHP 8.1 bis 8.4, neue Admin API, Update Assistant, alte Produktseite entfernt, Produkt URLs enthalten die Kategorie standardmäßig nicht mehr), abgerufen am 14. November 2026, https://build.prestashop-project.org/news/2025/prestashop-9-0-available/ ↩ ↩²

5. PrestaShop Benutzerhandbuch, Erweiterte Parameter, das CSV Importwerkzeug (importierbare Entitäten und Formatregeln), abgerufen am 14. November 2026, https://docs.prestashop-project.org/v.8-documentation/user-guide/configuring-shop/advanced-parameters/import ↩ ↩²

6. PrestaShop Developer Documentation, Creating access to the Webservice (Aktivierung unter den erweiterten Parametern, Schlüssel anlegen, Rechte je Ressource und je Methode), abgerufen am 14. November 2026, https://devdocs.prestashop-project.org/9/webservice/tutorials/creating-access/ ↩

7. PrestaShop Developer Documentation, Webservice getting started (der Endpunkt /api/, Basic Authentifizierung mit dem Schlüssel als Benutzernamen, XML Ausgabe mit JSON über output_format, und nur noch JSON Ausgabe seit 8.1), abgerufen am 14. November 2026, https://devdocs.prestashop-project.org/9/webservice/getting-started/ ↩ ↩² ↩³

8. PrestaShop Developer Documentation, Admin API (PrestaShop 9, OAuth2, auf Basis von API Platform), abgerufen am 14. November 2026, https://devdocs.prestashop-project.org/9/admin-api/ ↩

9. PrestaShop Quellcode, src/Core/Crypto/Hashing.php (bcrypt über password_hash mit PASSWORD_BCRYPT, älteres md5 wird beim Prüfen weiterhin akzeptiert), abgerufen am 14. November 2026, https://github.com/PrestaShop/PrestaShop/blob/develop/src/Core/Crypto/Hashing.php ↩

10. PrestaShop Developer Documentation, New password policy introduced in 8.0.x (Stärkeschätzung mit zxcvbn für Kunden und Mitarbeiter), abgerufen am 14. November 2026, https://devdocs.prestashop-project.org/9/modules/core-updates/new-password-policy/ ↩

11. PrestaShop Addons, der offizielle PrestaShop Marktplatz für kommerzielle Module und Themes, abgerufen am 14. November 2026, https://addons.prestashop.com/en/ ↩