# A PrestaShop module refuses to install or disappears from the back office

> "The install action is unavailable", a module that no longer appears after an update, or worse, a back office that becomes inaccessible right after installing a module: these three symptoms have specific causes, almost always among a handful of usual suspects.

- Source canonique : [https://allaux.fr/en/prestashop/problemes/module-refuse-installation](https://allaux.fr/en/prestashop/problemes/module-refuse-installation)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Start with the write permissions on modules/: without them the file copy fails behind a generic message. If the module sits on disk but never appears in Modules > Module Manager, empty var/cache/ to force the class cache to rebuild. A module written for 1.6 will fail to attach to a hook that no longer exists.

## Why an install fails silently

Installing a module copies files into the server’s /modules folder. Without sufficient write permission on that folder, the copy fails, often with a generic error message that doesn’t clearly point to a permissions issue. That’s the first thing to check when "the install action is unavailable".

Another common cause: a name conflict between two modules, when one declares a PHP class or a database table already used by another installed module. The install() method then fails without always clearly indicating which of the two modules is at fault.

## A module written for a different PrestaShop version

A module’s install() method generally tries to hook into one or more hooks. If the module was written for PrestaShop 1.6 and installed on a 1.7 or 8 without adaptation, installation fails if it targets a hook that no longer exists in the installed version. That’s a common cause for older or poorly maintained modules.

A module installed manually via FTP rather than from the back office can also remain invisible until PrestaShop’s core class cache has been regenerated: the file exists on the server, but PrestaShop doesn’t see it yet.

## Back office inaccessible right after installing a module

> This is the most serious case: a badly installed module triggers a fatal PHP error on load, and because it runs on every admin page, the entire back office becomes inaccessible. The immediate fix is to disable or remove the module’s folder via FTP to regain access, before even looking for the exact cause of its failure.

## Configuration or development?

Fixing write permissions or regenerating a class cache after a manual FTP drop is a quick clean-up. It becomes development when the third-party module itself is broken: an outdated hook to adapt, a class conflict to rename, or code written for one PrestaShop version that needs rewriting for the currently installed one.

## Related pages

- **PrestaShop back office inaccessible** — For every case where admin access is blocked, not just after installing a module. ([/prestashop/back-office-inaccessible](/prestashop/back-office-inaccessible))
- **500 error or blank page on PrestaShop** — When the fatal error triggered by a module affects the whole site, not just admin. ([/prestashop/erreur-500](/prestashop/erreur-500))
- **Bespoke PrestaShop module development** — For adapting a broken third-party module to the currently installed PrestaShop version. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### The back office became inaccessible right after installing a module, what do I do first?

Connect to the server via FTP and disable or remove the module’s folder in /modules. That’s what restores back-office access fastest, before investigating why the module failed.

### The "install" button is greyed out or the action is unavailable, why?

Usually a write permission issue on the server’s /modules folder, sometimes combined with a conflict with a module of the same name already present but disabled.

### I installed a module via FTP but it doesn’t show up in the back office, why?

PrestaShop keeps a class cache that needs regenerating to detect a manually added module. Without that, the file exists on the server but stays invisible on the back-office side.

### A module I’d used for a long time disappeared after a PrestaShop update, is that related?

Yes, that’s common: a module written for an older version can stop working if the hooks it uses have changed between versions. That needs the module adapting, not a simple reinstall.

### How do I tell if the conflict comes from my module or another one already installed?

I temporarily disable recently installed modules one by one and retest the installation at each step, which isolates the conflicting module before digging further into the code.