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

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.

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.