Die meisten PrestaShop-Modulshops beginnen ähnlich: Jemand hat eine Idee, baut sie einmal und stellt sie zum Verkauf ein. mypresta.rocks ist den umgekehrten Weg gegangen. Mehr als ein Jahrzehnt lang liefen die Module, die Sie hier jetzt kaufen können, in einzelnen Kundenshops, entwickelt, um ein echtes Problem eines Händlers zu lösen, durch den realen Traffic dieses Händlers gehärtet und nie an jemand anderen verkauft. Die Eröffnung ist nicht der Start von neuem Code. Sie ist der Moment, in dem ein privater Werkzeugkasten, der sich längst im Produktivbetrieb bewährt hat, zu etwas wurde, das jeder Shopbetreiber installieren kann. In diesem Beitrag geht es darum, was Ihnen dieser Unterschied konkret bringt, denn „im Alltag getestet, bevor es überhaupt zum Verkauf stand“ ist ein anderes Versprechen als „Version 1.0, hoffen wir, dass es funktioniert“.
Warum diese Module zehn Jahre lang privat blieben
Jedes dieser Werkzeuge begann als bezahlte Kundenarbeit. Ein Händler mit PrestaShop 1.5 brauchte eine Versandlogik, die der Core nicht abbilden konnte; ein Shop auf 1.6 benötigte eine SEO-Sitemap, die seine Kategoriestruktur verstand; ein Katalog mit 40.000 Produkten brauchte interne Verlinkung, ohne dass die Datenbank in die Knie ging. Jede Lösung wurde gegen ein konkretes Shop-Theme, eine bestimmte PHP-Version und einen bestimmten Satz an Overrides gebaut, und genau diese Spezialisierung war der Grund, warum sie privat blieb. Ein Modul, das mit Templates in themes/yourtheme/ und einem bestimmten override/-Ordner verschweißt ist, ist kein Produkt; es ist eine Individualentwicklung.
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 nach derselben Funktion fragt, ist der ehrliche Schritt, sie nicht erneut maßgeschneidert zu bauen, sondern daraus etwas Allgemeines zu machen. Genau dafür steht diese Eröffnung: nicht für neue Ideen, sondern für das Refactoring, das eine gute Idee aus dem einen Shop befreit, in dem sie entstanden ist.
Was „privaten Code in ein Produkt umwandeln“ tatsächlich bedeutet
Öffentlich zu werden heißt nicht, alte Dateien zu zippen und einen Preis daranzuschreiben. Ein Modul, das in einem Shop problemlos lief, scheitert oft in dem Moment, in dem es auf den zweiten trifft, und diese Lücke zu schließen, ist der größte Teil der Arbeit. Die wiederkehrenden Aufgaben:
- Shopspezifische Annahmen entfernen. Fest verdrahtete Kategorie-IDs, ein bestimmter Versanddienstleister, eine individuelle Datenbankspalte, die nur in einem Shop existierte: all das muss im Backoffice konfigurierbar werden, statt im Quellcode geändert zu werden.
- Theme-Eingriffe durch Hooks ersetzen. Privater Code änderte häufig Theme-Templates direkt. Ein Produkt muss sich über das Hook-System von PrestaShop einklinken (displayHeader, displayProductActions, actionFrontControllerSetMedia und ähnliche), damit es einen Theme-Wechsel und ein Core-Upgrade übersteht, ohne irgendetwas zu forken.
- Den Installations- und Deinstallationszyklus überstehen. Einmaliger Code wird nie deinstalliert. Ein Produkt braucht saubere install()- und uninstall()-Routinen, die Hooks registrieren, Tabellen anlegen und, entscheidend, sie wieder entfernen, ohne verwaiste Zeilen in ps_configuration oder tote Einträge in ps_hook_module zurückzulassen.
- Eine echte Konfigurationsoberfläche hinzufügen. Einstellungen, die früher als Konstante am Anfang einer Datei standen, werden zu einem ordentlichen getContent()-Adminformular, damit ein Shopbetreiber das Verhalten über Modules → Module Manager ändert, statt einen Code-Editor zu öffnen.
- Einen Debug-Modus, den Sie einschalten können. Mehrere Module bringen einen Schalter mit, der auf einer Staging-Kopie sichtbar macht, was das Modul tut. So können Sie das Verhalten prüfen, bevor es einen Live-Warenkorb berührt, eine Arbeitsweise, die direkt aus einem Jahrzehnt Fehlersuche in Produktivshops anderer Händler stammt.
Was bedeutet das also für Sie? Das Modul, das Sie herunterladen, wurde nicht am Reißbrett erdacht. Es wurde im Alltag genutzt. Die Randfälle, die sonst als Ihre ersten drei Supporttickets auftauchen würden, sind Jahre bevor Sie auf Installieren klicken bereits im Shop eines zahlenden Kunden aufgetreten und behoben worden.
Abwärtskompatibilität, der wenig glamouröse 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, den ein Händler betreibt, und zugleich der riskanteste, den man anfasst. Weil diese Module über die ganze Bandbreite realer Kundenumgebungen gewachsen sind (ältere 1.6-Shops neben neueren 1.7- und 8.x-Installationen), ist die Unterstützung dieses Spektrums keine Marketingzeile, sondern schlicht der Bereich, in dem der Code ohnehin laufen musste.
Trotzdem ist Kompatibilität eine Tatsache pro Modul, kein pauschales Versprechen, und wir tun nicht so, als wäre es anders: PHP hat zwischen Hauptversionen den Umgang mit Strings und Arrays geändert, manche Bibliotheken, auf die wir uns stützten, wurden umbenannt oder entfernt, und ein Modul, das von einer Funktion abhängt, die ein 1.6-Shop nie hatte, ist schlicht kein 1.6-Modul. Deshalb nennt jede Produktseite die Versionen, die dieses Modul tatsächlich unterstützt, geprüft anhand seines eigenen Headers, statt ein einziges Kompatibilitätsabzeichen über den gesamten Katalog zu kleben. Wenn Sie mehrere Shopversionen betreiben, ist genau diese Ehrlichkeit der Punkt: Sie sehen auf einen Blick, welches Werkzeug zu welchem Shop passt.
Warum ein öffentlich erhältliches Modul kaufen, statt die individuelle Version zu beauftragen
Wenn all das als maßgeschneiderte Kundenarbeit begonnen hat, ist die faire Frage, ob Sie nicht einfach Ihre eigene Lösung beauftragen sollten. Hier ist die Abwägung, ohne Ausschmückung:
| Produktisiertes Modul (hier) | Individuelle Entwicklung | |
|---|---|---|
| Anfangskosten | Eine Lizenz | Tagessatz eines Entwicklers, oft über Wochen |
| Zeit bis zum Livebetrieb | Installieren & im Backoffice konfigurieren | Spezifizieren, bauen, testen, bereitstellen |
| Übersteht Core-Upgrades | Auf Hooks gebaut, zentral gepflegt, Updates gehen an alle | Sie müssen jede PrestaShop-Version erneut testen und reparieren |
| Randfälle bereits gefunden | Ja. Jahre anderer Shops haben sie zuerst getroffen | Ihr Shop ist der erste; Sie finden sie |
| Passt zu einer wirklich einzigartigen Anforderung | Innerhalb der Konfiguration des Moduls | Vollständig, nach Ihrer exakten Spezifikation gebaut |
Der individuelle Weg gewinnt weiterhin, wenn Ihre Anforderung wirklich einzigartig ist. Für den weit häufigeren Fall, „Ich brauche das, was dieser Shop hat“, bringt Sie ein produktisiertes Modul heute dorthin, auf Ihrer aktuellen Version, ohne dass Sie die Wartung für immer selbst tragen. Dass diese Wartung bei uns bleibt, ist der stille Vorteil des öffentlichen Verkaufs: Eine Korrektur, die in einem Händler-Shop gefunden wird, geht nun an jeden Shop, der das Modul nutzt, statt in einem privaten Repository zu verschwinden.
Was sich durch den öffentlichen Start auf unserer Seite geändert hat
Vor dem Shop lief alles über E-Mail-Threads: Lizenzen wurden aus dem Gedächtnis verfolgt, Updates als Anhänge verschickt, Support lag verstreut in Postfächern. Ein öffentlicher Shop bedeutete, die wenig glamouröse Infrastruktur um den Code herum aufzubauen, zentrale Lizenzierung, Versionsverfolgung, Bestellhistorie und einen einzigen Ort, an dem Sie den aktuellen Build herunterladen können, statt nach der letzten E-Mail zu suchen. Support läuft über strukturierte Tickets statt über „wer erinnert sich noch an den Thread“, und Sie kaufen und aktualisieren direkt beim Entwickler, der das Modul geschrieben hat, ohne Wiederverkäufer dazwischen.
Der Katalog ist außerdem vollständig lokalisiert, Englisch, Polnisch, Italienisch, Deutsch, Französisch und Spanisch, bis hin zu den Konfigurationstexten im Modul, damit die Backoffice-Oberflächen in Ihrer Sprache erscheinen und nicht wie maschinell übersetzte Annäherungen klingen. Englisch wird zuerst geschrieben und ist die Qualitätsreferenz; Polnisch wird von einem Muttersprachler geprüft, denn halb übersetzte Admintexte sind eine eigene Art von Fehler.
FAQ
Sind das brandneue Module oder wiederverwerteter Kundencode?
Keines von beidem, jedenfalls nicht genau. Die Funktion ist alt, jedes Werkzeug lief jahrelang im Shop eines zahlenden Kunden, aber die Version, die Sie installieren, ist ein Refactoring: shopspezifische Annahmen entfernt, Theme-Änderungen durch Hooks ersetzt, ein sauberer Installations-/Deinstallationszyklus und eine Backoffice-Konfigurationsoberfläche ergänzt. Sie erhalten also eine Funktion, die echten Produktivbetrieb bereits kennt, verpackt so, dass sie in Ihren Shop passt statt in den, in dem sie entstanden ist.
Welche PrestaShop-Versionen unterstützt ein Modul?
Das hängt vom Modul ab, und jede Produktseite sagt es offen, statt ein pauschales Abzeichen zu tragen. Weil diese Werkzeuge über eine Bandbreite realer Kundenumgebungen gewachsen sind (ältere 1.6-Shops neben 1.7- und 8.x-Installationen), wird der unterstützte Bereich anhand des jeweiligen Modul-Headers geprüft, nicht als Marketingbehauptung gesetzt. Wenn ein Modul auf etwas angewiesen ist, das ein 1.6-Shop nie hatte, ist es schlicht kein 1.6-Modul, und die Produktseite sagt Ihnen das von Anfang an.
Sollte ich ein öffentlich erhältliches Modul kaufen oder stattdessen eine individuelle Entwicklung beauftragen?
Beauftragen Sie individuelle Entwicklung nur dann, wenn Ihre Anforderung wirklich einzigartig ist. Für das deutlich häufigere „Ich brauche das, was der andere Shop hat“ lässt sich ein produktisiertes Modul heute im Backoffice installieren und konfigurieren, auf Ihrer aktuellen Version, und die Wartung bleibt bei uns. Eine Korrektur, die in einem Händler-Shop gefunden wird, geht an jeden Shop, der das Modul nutzt. Die Vergleichstabelle oben zeigt die vollständige Abwägung.
Wer kümmert sich um Support und Updates, seit der öffentliche Verkauf gestartet ist?
Sie kaufen und aktualisieren direkt beim Entwickler, der das Modul geschrieben hat, ohne Wiederverkäufer dazwischen. Support läuft über strukturierte Tickets statt über verstreute E-Mail-Threads, Lizenzen und Versionshistorie liegen an einem Ort, und Sie laden den aktuellen Build aus Ihrem Konto herunter, statt nach dem letzten Anhang zu suchen.
Ist der Katalog in meiner Sprache verfügbar?
Der Shop und die Backoffice-Texte in den Modulen sind auf Englisch, Polnisch, Italienisch, Deutsch, Französisch und Spanisch lokalisiert. Englisch wird zuerst geschrieben und ist die Qualitätsreferenz; Polnisch wird von einem Muttersprachler geprüft, denn halb übersetzte Admintexte sind eine eigene Art von Fehler.
Wohin es von hier aus geht
Die Eröffnung ist der Beginn einer laufenden öffentlichen Dokumentation, keine einmalige Ankündigung. Ein paar Themenstränge, denen es sich zu folgen lohnt:
- Der Shop hat jetzt einen Blog mit PrestaShop-Anleitungen, Tipps und Brancheneinblicken, die technische Dokumentation, die früher nur in Kunden-E-Mails stand, nun öffentlich zugänglich.
- Versionshinweise, kurze Fragen und Einblicke hinter die Kulissen laufen außerdem über unsere Kanäle auf Facebook, Instagram und X.
- Für den größeren Kontext, in dem sich das gesamte Ökosystem bewegt, unsere Einschätzung zu der Übernahme durch cyber_Folks und was sie wirklich bedeutet für Händler.
- Und dazu, wie die Arbeit selbst heute erledigt wird, der ehrliche Bericht darüber, welche KI-Werkzeuge 2026 tatsächlich bei der PrestaShop-Entwicklung helfen.
Das ist die ganze Idee hinter mypresta.rocks: tief technisch unter der Haube, aber verkauft über das, was es für Ihren Shop leistet, nicht darüber, wie clever der Code ist. Die Module hier haben sich ihren Platz auf die harte Art verdient, im Produktivbetrieb, in echten Shops, lange bevor sie einen Preis hatten. Öffentlich zu werden heißt nur, dass der Rest der PrestaShop-Welt sie endlich ebenfalls installieren kann.
