# The module works, but its publisher is gone

> The module runs, the store sells, and yet the publisher no longer answers. No new version for a long time, support that returns nothing, sometimes a commercial site that no longer exists. It isn’t an emergency, but it is a decision to take before it is taken for you.

- Source canonique : [https://allaux.fr/en/modules/module-dont-l-editeur-a-disparu](https://allaux.fr/en/modules/module-dont-l-editeur-a-disparu)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> First check whether the feature is still used: a module installed for a campaign that ended gets removed, not replaced. Otherwise open its config.xml to read the declared compatibility range, and see whether the main PHP file is readable or encoded with ionCube. Those two points decide between taking over the code, rewriting it, or replacing it.

## What will actually happen, and when

An abandoned module doesn’t stop overnight. It keeps working as long as its environment stands still, and that is exactly what misleads: the problem appears at the first PHP or platform upgrade, often decided by your host rather than by you. On that day, nobody will publish a compatible version.

The real timetable depends on what the module does. A display module can survive for years. A module talking to an outside service will stop at that service’s first interface change, and you won’t be warned. A payment module is the most constrained case: providers’ security requirements evolve, and an unmaintained module eventually gets rejected on the provider’s side, not the store’s.

Alongside operation there is security: a module that no longer receives fixes keeps any flaws it has indefinitely. That is a distinct and serious subject, covered separately.

## The outcomes, in the order I examine them

1. **Do without the module** — The first question, and rarely asked: is the function still used? A module installed for a promotion that ended two years ago gets removed, not replaced.
2. **Replace it with a maintained equivalent** — The fastest route when the function is standard. The real work isn’t installing the replacement but recovering the data the old module accumulated, which is almost never in a compatible format.
3. **Take over its code** — Possible only if the code is readable and the licence allows it. The module then becomes yours, with its maintenance on you. That is defensible for a specific function you depend on and that no other module covers.
4. **Rewrite it** — When the code is encoded or too degraded to take over, and the function remains essential. The original module then serves as the specification: it shows exactly what is expected, edge cases included.

## The point that decides everything: is the code readable

> A module shipped in encoded form can be neither taken over nor fixed, by anyone. If its publisher has vanished, the only path is replacement or a rewrite. That check comes first, because it removes two of the four options before budget is even discussed.

## What I look at before advising anything

I start by measuring the real dependency. How many orders go through this function each month, what data the module holds of its own, and what would concretely happen if it stopped tomorrow morning. That measurement often changes the decision: a function used twice a month doesn’t justify a rewrite, whereas one present on every order justifies it without discussion.

Then I look at the data. An abandoned module has often created its own tables, and those tables sometimes hold years of history. Recovering them before any removal is the only truly irreversible step in the whole matter: a module can be reinstalled, deleted data cannot be reinvented.

Finally I check whether there is a way to buy time without committing: freezing the PHP version for a few months, isolating the module behind a fallback, or simply documenting precisely what it does so the decision can be taken calmly later.

## Related pages

- **Abandoned modules and extensions** — The same subject seen from the intrusion-risk angle. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Vendor module, third-party module or custom build** — How to avoid ending up in this position next time. ([/modules/module-officiel-tiers-ou-developpement](/modules/module-officiel-tiers-ou-developpement))
- **End-of-life PHP versions** — The deadline that most often triggers an abandoned module’s failure. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Auditing a store’s module estate** — To know how many modules are in this position before one of them breaks. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### The module still works, do I really need to act now?

Not urgently, but before the next PHP or platform upgrade. Acting calmly costs less than acting on the day the store stops taking orders.

### Can I keep using a module whose publisher has closed?

Technically yes, while it works. What you need to know is that no security fix will come, and nobody can make it compatible with a future version if its code isn’t readable.

### How do I recover a module’s data before removing it?

By identifying the tables it created and exporting them before any uninstall. A well-written module’s uninstall deletes precisely those tables: the export happens before, never after.

### Can an abandoned module be taken over by another developer?

Yes if the code is readable and the licence allows it. It is standard takeover work: reading, bringing it up to the current platform version, then maintenance. On encoded code it isn’t possible.