Launching mypresta.rocks: a decade with PrestaShop goes public

Last updated: June 2026.

Most PrestaShop module shops start the same way: someone has an idea, builds it once, and lists it. mypresta.rocks ran the opposite direction. For more than a decade the modules you can now buy here lived inside individual client stores, written to fix one merchant's real problem, hardened by that merchant's real traffic, and never sold to anyone else. The grand opening isn't the launch of new code. It's the moment a private toolkit, already proven in production, became something any store owner can install. This post is about what that distinction actually buys you, because "battle-tested before it was ever for sale" is a different promise than "version 1.0, hope it works."

Why these modules were private for ten years

Every one of these tools began as paid client work. A merchant on PrestaShop 1.5 needed shipping logic the core couldn't express; a store on 1.6 needed an SEO sitemap that understood its category tree; a catalog of 40,000 products needed internal linking that didn't choke the database. Each was built against one shop's theme, one PHP version, one set of overrides, and that specificity was exactly why it stayed private. A module welded to themes/yourtheme/ templates and a particular override/ folder isn't a product; it's a custom job.

What changed is that the same requests kept arriving. "I saw the SEO generator you built for that store. Can I buy it for mine?" When the tenth merchant asks for the same capability, the honest move is to stop rebuilding it bespoke and turn it into something general-purpose. That's the work the grand opening represents: not new ideas, but the refactor that frees a good idea from the one shop it was born in.

What "refactoring private code into a product" actually involves

Going public is not zipping up old files and writing a price. A module that ran fine inside one store routinely fails the moment it meets a second one, and closing that gap is the bulk of the effort. The recurring jobs:

• Strip the store-specific assumptions. Hardcoded category IDs, a particular carrier, a custom DB column that only existed in one shop: all of it has to become configurable from the back office instead of edited in the source.
• Replace theme surgery with hooks. Private code often edited theme templates directly. A product has to attach through PrestaShop's hook system (displayHeader, displayProductActions, actionFrontControllerSetMedia and friends) so it survives a theme change and a core upgrade without forking anything.
• Survive the install/uninstall cycle. One-off code never gets uninstalled. A product needs a clean install() / uninstall() that registers hooks, creates its tables, and, critically, removes them again without leaving orphan rows in ps_configuration or dead ps_hook_module entries.
• Add a real configuration screen. Settings that lived in a constant at the top of a file become a proper getContent() admin form, so a store owner changes behavior from Modules → Module Manager instead of opening a code editor.
• A debug mode you can switch on. Several modules ship a toggle that surfaces what the module is doing on a staging copy, so you can confirm behavior before it touches a live cart, a habit carried straight over from a decade of troubleshooting other people's production stores.

So what does that mean for you? The module you download wasn't theorized. It was lived in. The edge cases that normally surface as your first three support tickets were already hit, and fixed, inside a paying client's store years before you clicked install.

Backward compatibility, the unglamorous part

A store that "can't upgrade right now" is the rule, not the exception. A heavily customized PrestaShop on an older line is often the most profitable shop a merchant owns, and the riskiest to touch. Because these modules grew up across that whole spread of real client environments, older 1.6 stores alongside newer 1.7 and 8.x builds, supporting the range isn't a marketing line, it's just where the code already had to run.

That said, compatibility is a per-module fact, not a blanket claim, and we won't pretend otherwise: PHP changed its string and array handling between major versions, some libraries we relied on were renamed or dropped, and a module that depends on a feature a 1.6 store never had simply isn't a 1.6 module. So each listing states the versions that module actually supports, verified against its own header, rather than spraying one compatibility badge across the whole catalog. If you run a mixed estate, that honesty is the point: you can tell at a glance which tool fits which shop.

Why buy a public module instead of commissioning the custom version

If these started as bespoke client work, the fair question is whether you should just commission your own. Here's the trade-off, plainly:

The custom route still wins when your requirement is genuinely one-of-a-kind. For the far more common case, "I need the thing that store has", a productized module gets you there today, on your current version, without owning the maintenance forever. That maintenance staying ours is the quiet benefit of going public: a fix found in one merchant's store now ships to every store running the module, instead of dying in a private repo.

What going public changed on our side

Before the storefront, everything was an email thread: licences tracked by memory, updates sent as attachments, support scattered across inboxes. A public store meant building the unglamorous infrastructure around the code, centralized licensing, version tracking, order history, and a single place to download the current build instead of hunting for the last email. Support runs through structured tickets rather than whoever-remembers-the-thread, and you buy and update direct from the developer who wrote the module, with no reseller in between.

The catalog is also fully localized, English, Polish, Italian, German, French and Spanish, down to the in-module configuration text, so the back-office screens read in your language rather than machine-translated approximations. English is written first and is the quality reference; the Polish is reviewed by a native speaker, because half-translated admin copy is its own kind of bug.

FAQ

Are these brand-new modules, or recycled client code?

Neither, exactly. The capability is old, each tool ran for years inside a paying client's store, but the version you install is a refactor: the store-specific assumptions stripped out, theme edits replaced with hooks, a real install/uninstall cycle and a back-office configuration screen added. So you get a feature that has already met real production traffic, packaged so it drops into your shop instead of the one it was born in.

Which PrestaShop versions does a module support?

It depends on the module, and each listing says so rather than carrying one blanket badge. Because these tools grew up across a spread of real client environments, older 1.6 stores alongside 1.7 and 8.x builds. The supported range is verified against each module's own header, not a marketing claim. If a module relies on something a 1.6 store never had, it simply isn't a 1.6 module, and the listing will tell you that up front.

Should I buy a public module or commission a custom build instead?

Commission custom only when your requirement is genuinely one-of-a-kind. For the far more common "I need the thing that other store has," a productized module installs and configures from the back office today, on your current version, and the maintenance stays ours, a fix found in one merchant's shop ships to every store running the module. The comparison table above lays out the full trade-off.

Who handles support and updates now that you've gone public?

You buy and update directly from the developer who wrote the module, with no reseller in between. Support runs through structured tickets rather than scattered email threads, licences and version history live in one place, and you download the current build from your account instead of hunting for the last attachment.

Is the catalogue available in my language?

The shop and the in-module back-office text are localized into English, Polish, Italian, German, French and Spanish. English is written first and is the quality reference; the Polish is reviewed by a native speaker, because half-translated admin copy is its own kind of bug.

Where to go from here

The grand opening is the start of an ongoing public record, not a one-off announcement. A few threads worth following:

• The shop now has a blog of PrestaShop guides, tips and industry insights. The technical writing that used to live only in client emails, now in the open.
• Release notes, quick questions and behind-the-scenes work also run through our Facebook, Instagram and X channels.
• For the wider context the whole ecosystem is moving through, our read on the cyber_Folks acquisition and what it really means for merchants.
• And on how the work itself gets done now, the honest account of which AI tools actually help with PrestaShop development in 2026.

That's the whole idea behind mypresta.rocks: deeply technical under the hood, but sold on what it does for your store, not how clever the code is. The modules here earned their listing the hard way. In production, in real shops, long before they had a price. Going public just means the rest of the PrestaShop world finally gets to install them too.