Unsere Eröffnung: Ein Jahrzehnt PrestaShop-Erfahrung wird öffentlich

Die meisten PrestaShop-Modulshops entstehen ähnlich: Jemand hat eine Idee, baut sie einmal und stellt sie zum Verkauf. mypresta.rocks ist den umgekehrten Weg gegangen. Mehr als ein Jahrzehnt lang liefen die Module, die Sie hier heute kaufen können, in einzelnen Kundenshops — geschrieben, um ein echtes Problem eines Händlers zu lösen, durch echten Traffic gehärtet und nie an jemand anderen verkauft. Die Eröffnung ist also kein Launch von neuem Code. Es ist der Moment, in dem ein privates Toolkit, das sich längst in Produktion bewährt hat, zu etwas wurde, das jeder Shopbetreiber installieren kann. Genau darum geht es in diesem Beitrag: Was Ihnen dieser Unterschied konkret bringt, denn „battle-tested, bevor es je verkauft wurde“ ist ein anderes Versprechen als „Version 1.0, hoffen wir, dass es läuft“.

Warum diese Module zehn Jahre lang privat waren

Jedes dieser Tools begann als bezahlte Kundenarbeit. Ein Händler auf PrestaShop 1.5 brauchte Versandlogik, die der Core nicht abbilden konnte; ein Shop auf 1.6 brauchte eine SEO-Sitemap, die den Kategoriebaum verstand; ein Katalog mit 40.000 Produkten brauchte interne Verlinkung, ohne die Datenbank abzuwürgen. Jede Lösung entstand gegen ein konkretes Theme, eine PHP-Version, einen Satz Overrides — und genau diese Spezifität war der Grund, warum sie privat blieb. Ein Modul, das mit themes/yourtheme/-Templates und einem bestimmten override/-Ordner verschweißt ist, ist kein Produkt, sondern eine Maßanfertigung.

Geändert hat sich, dass dieselben Anfragen immer wieder kamen. „Ich habe den SEO-Generator gesehen, den ihr für diesen Shop gebaut habt — kann ich ihn für meinen kaufen?“ Wenn der zehnte Händler dieselbe Funktion will, ist es ehrlicher, sie nicht jedes Mal neu als Einzelstück zu bauen, sondern daraus ein allgemeines Produkt zu machen. Genau diese Arbeit steckt hinter der Eröffnung: nicht neue Ideen, sondern das Refactoring, das eine gute Idee aus dem einen Shop befreit, in dem sie entstanden ist.

Was „privaten Code in ein Produkt refactoren“ wirklich bedeutet

Öffentlich verkaufen heißt nicht, alte Dateien zu zippen und einen Preis daneben zu schreiben. Ein Modul, das in einem Shop sauber lief, scheitert oft in dem Moment, in dem es den zweiten Shop sieht. Diese Lücke zu schließen ist der größte Teil der Arbeit. Die wiederkehrenden Aufgaben:

• Shop-spezifische Annahmen entfernen. Hart codierte Kategorie-IDs, ein bestimmter Carrier, eine Custom-DB-Spalte, die nur in einem Shop existierte — all das muss im Back Office konfigurierbar werden, statt im Quellcode geändert zu werden.
• Theme-Eingriffe durch Hooks ersetzen. Privater Code änderte oft Theme-Templates direkt. Ein Produkt muss über PrestaShop-Hooks wie displayHeader, displayProductActions, actionFrontControllerSetMedia und ähnliche einhängen, damit es Themewechsel und Core-Upgrades ohne Fork überlebt.
• Installieren und Deinstallieren sauber überstehen. Einmal-Code wird nie deinstalliert. Ein Produkt braucht ein sauberes install() / uninstall(), das Hooks registriert, Tabellen anlegt und — entscheidend — alles wieder entfernt, ohne verwaiste Zeilen in ps_configuration oder tote ps_hook_module-Einträge zu hinterlassen.
• Eine echte Konfigurationsseite hinzufügen. Einstellungen, die früher als Konstante oben in einer Datei standen, werden zu einem ordentlichen getContent()-Adminformular, damit ein Shopbetreiber das Verhalten unter Modules → Module Manager ändert, statt einen Codeeditor zu öffnen.
• Ein Debug mode, den man einschalten kann. Mehrere Module liefern einen Schalter mit, der auf einer Staging-Kopie sichtbar macht, was das Modul tut. So können Sie Verhalten prüfen, bevor es einen Live-Warenkorb berührt — eine Gewohnheit direkt aus zehn Jahren Troubleshooting in fremden Produktionsshops.

Was heißt das für Sie? Das Modul, das Sie herunterladen, wurde nicht nur theoretisch entworfen — es wurde im Alltag benutzt. Die Edge Cases, die sonst als Ihre ersten drei Supporttickets auftauchen, wurden schon Jahre vor Ihrem Klick auf „Installieren“ in einem zahlenden Kundenshop gefunden und behoben.

Backward compatibility, der unspektakuläre Teil

Ein Shop, der „gerade nicht upgraden kann“, ist die Regel, nicht die Ausnahme. Ein stark angepasster PrestaShop auf einer älteren Linie ist oft der profitabelste Shop eines Händlers — und der riskanteste, wenn man ihn anfasst. Weil diese Module in genau dieser Spannweite realer Kundenumgebungen gewachsen sind — ältere 1.6-Shops neben neueren 1.7- und 8.x-Installationen — ist die Unterstützung verschiedener Versionen keine Marketingzeile. Es ist schlicht der Bereich, in dem der Code ohnehin laufen musste.

Gleichzeitig ist Kompatibilität eine Tatsache pro Modul, kein pauschales Versprechen. Wir tun nicht so, als wäre es anders: PHP hat String- und Array-Verhalten zwischen Major-Versionen geändert, einige Libraries wurden umbenannt oder entfernt, und ein Modul, das von einer Funktion abhängt, die ein 1.6-Shop nie hatte, ist eben kein 1.6-Modul. Deshalb nennt jedes Listing die Versionen, die dieses Modul tatsächlich unterstützt, geprüft gegen den eigenen Header — statt ein einziges Compatibility-Badge über den ganzen Katalog zu streuen. Wenn Sie mehrere Shopversionen betreiben, ist genau diese Ehrlichkeit der Punkt: Sie sehen sofort, welches Tool zu welchem Shop passt.

Warum ein öffentliches Modul kaufen statt die Custom-Version beauftragen

Wenn diese Module als individuelle Kundenarbeit entstanden sind, ist die faire Frage, ob Sie nicht einfach Ihre eigene Lösung beauftragen sollten. Der Trade-off, klar gesagt:

Der Custom-Weg gewinnt weiterhin, wenn Ihre Anforderung wirklich einmalig ist. Für den viel häufigeren Fall — „Ich brauche das, was dieser Shop hat“ — bringt Sie ein produktisiertes Modul heute ans Ziel, auf Ihrer aktuellen Version, ohne dass Sie die Wartung für immer besitzen. Dass diese Wartung bei uns bleibt, ist der leise Vorteil der Veröffentlichung: Ein Fix, der in einem Händlershop gefunden wird, geht nun an jeden Shop, der das Modul nutzt, statt in einem privaten Repo zu verschwinden.

Was die Veröffentlichung auf unserer Seite geändert hat

Vor dem Storefront war alles ein E-Mail-Thread: Lizenzen aus dem Gedächtnis, Updates als Anhänge, Support verteilt über Posteingänge. Ein öffentlicher Store bedeutete, die unspektakuläre Infrastruktur um den Code herum zu bauen — zentrale Lizenzierung, Versionsverfolgung, Bestellhistorie und einen einzigen Ort, an dem Sie den aktuellen Build herunterladen, statt die letzte E-Mail zu suchen. Support läuft über strukturierte Tickets statt über „wer erinnert sich an den Thread“, und Sie kaufen und aktualisieren direkt beim Entwickler, der das Modul geschrieben hat, ohne Reseller dazwischen.

Der Katalog ist außerdem vollständig lokalisiert — Englisch, Polnisch, Italienisch, Deutsch, Französisch und Spanisch — bis hin zu den Konfigurationstexten im Modul. Back-Office-Screens lesen sich also in Ihrer Sprache und nicht wie maschinell übersetzte Näherungen. Englisch wird zuerst geschrieben und ist die Qualitätsreferenz; Polnisch wird von einem Native Speaker geprüft, weil halb übersetzter Admintext seine eigene Art Bug ist.

Wohin es von hier aus geht

Die Eröffnung ist der Start eines laufenden öffentlichen Protokolls, keine einmalige Ankündigung. Ein paar Themen lohnen sich:

• Der Shop hat jetzt einen Blog mit PrestaShop-Guides, Tipps und Brancheneinblicken — technisches Schreiben, das früher nur in Kunden-E-Mails lag, jetzt offen zugänglich.
• Release Notes, kurze Fragen und Behind-the-scenes-Arbeit laufen auch über unsere Kanäle auf Facebook, Instagram und X.
• Für den größeren Kontext, durch den sich das ganze Ökosystem bewegt, lesen Sie unsere Einschätzung zur Übernahme durch cyber_Folks und was sie wirklich bedeutet.
• Und dazu, wie die Arbeit heute erledigt wird, gibt es den ehrlichen Blick darauf, welche AI tools 2026 bei PrestaShop-Entwicklung tatsächlich helfen.

Das ist die Idee hinter mypresta.rocks: unter der Haube tief technisch, verkauft aber über das, was es für Ihren Shop tut, nicht darüber, wie clever der Code ist. Die Module hier haben sich ihr Listing auf die harte Art verdient — in Produktion, in echten Shops, lange bevor sie einen Preis hatten. Öffentlich zu werden bedeutet nur, dass der Rest der PrestaShop-Welt sie jetzt ebenfalls installieren kann.