How to Vet a PrestaShop Module Before Installing It on a Live Store

You do not need to read PHP to tell whether a PrestaShop module is safe to put on your live store. Most of the damage a bad module does is visible from a browser and your back office — if you know where to look. This is the checklist we use, written so a store owner can run it without a developer.

The idea is simple. A module is unsandboxed code that runs with your store's full privileges: it can load assets on every page, write to your database, change core behaviour, and call out to other servers. So instead of trusting the sales page, you observe what the module actually does on a safe copy of your store, and you score it. Ten green checks out of twelve is a module you can install with confidence. But the score isn't the whole story: some rows are hard stops. A red flag on checkout or customer data, on the reversibility test, on a new external domain, or on undisclosed overrides means the module stays off your live store until the vendor explains it — whatever the other rows say.

Run this on a staging copy first — never on live. Duplicate your shop (most hosts offer a one-click staging clone), or use a throwaway install with your theme and your other modules present. You want the module to meet the same messy reality your real store is: your theme, your language and currency setup, your existing modules, your PrestaShop and PHP versions. A module that only behaves on a blank install is telling you something.

The twelve checks

1. External domains and CDNs

How to run it: open your store's homepage — not the module's settings page — in your browser, press F12 to open Developer Tools, click the Network tab, and reload the page. Sort by Domain. Note every domain that isn't yours. Now install the module and reload again. Did any new third-party domain appear?

Pass: no new external domains on pages that don't use the feature. Failure mode: this is the exact trap from our essay — a module loading a font, script, or tracker from someone else's server on every page, adding DNS lookups, weight, a privacy exposure, and a dependency on a server you don't control. If that server is slow or down one day, your storefront's rendering can stall or degrade with it.

If you'd rather count them exactly than read the list by eye, paste this into the same DevTools Console tab and press Enter — it lists every domain that isn't yours and how many requests each one made:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource';)) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

It counts every host that isn't your main domain — including any CDN subdomains you run yourself, which you can safely ignore. Run it before installing the module, then again after: any genuinely new host is a new third party your storefront now depends on.

This is the single highest-value check on the list, because it catches the exact failure from our essay: a module that quietly adds a third-party domain to every page. If a host appears here that you didn't add on purpose, stop and ask the vendor why before it ever reaches your live store.

2. Global front-office assets

How to run it: in the same Network tab, filter by CSS and JS, and compare the count on your homepage before and after installing. Then check a page the module should affect, and a page it shouldn't.

Pass: the module's stylesheets and scripts load only on the pages that use them. Failure mode: a "small" module that registers its assets on a global header hook adds weight to every page in the store, including checkout, for a feature that lives on one. Multiply that across a dozen careless modules and you have a slow store with no single culprit.

3. Overrides

How to run it: before installing, look in your store's /override folder over FTP or your host's file manager (you're only checking whether files appear — you don't need to read them). Install the module, then look again.

Pass: no new files appeared in /override (a stock folder already holds placeholder index.php files — you are looking for new ones). Failure mode: overrides live in /override and change how core PrestaShop classes and controllers behave. Two modules that override the same class conflict, and — critically — an override left behind after you uninstall is a leading cause of "my store broke and disabling things didn't fix it." Good modules use hooks and services instead of overriding the core.

4. Hooks used

How to run it: in the back office, go to Design › Positions (the hooks screen) and look at where the module registered itself. You can also usually see a module's hooks on its configuration page.

Pass: the hooks match the feature. A shipping module hooks into shipping and checkout; a product-tab module hooks into the product page. Failure mode: a module hooked into every page — displayHeader, displayFooter on everything — "just in case," when its feature only appears in one place. Every one of those hooks is code running on every page load.

5. Database schema changes

How to run it: in your host's database tool (phpMyAdmin or similar), note the number of tables before installing. Install, and look at what was added — you're checking names, not contents.

Pass: new tables are clearly namespaced to the module (a recognisable prefix) and, ideally, documented. A handful of well-named tables is completely normal and fine. Failure mode: a module that scatters unlabelled tables, or writes into PrestaShop's core tables in ways it doesn't disclose, is one you can't cleanly reason about later.

If you have database access (phpMyAdmin or the command line), you can list exactly what a module added. Note the list before installing, then run it again afterwards and compare:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

A short, clearly-prefixed list is healthy. A scatter of unlabelled tables — or undisclosed writes into core tables such as ps_orders or ps_customer — is what you're watching for. (ps_ is the default table prefix; swap in yours if you changed it, and use the module's technical name in place of mymodule.)

6. Uninstall cleanup

How to run it: after your schema check, uninstall the module and look at the database again. What did it remove, and what did it leave?

Pass: the module removes what it created — or clearly states in its documentation what it deliberately keeps and why (keeping your settings for a future reinstall is a legitimate choice, if disclosed). Failure mode: silent leftovers. Orphaned tables, configuration rows, and stale files that accumulate every time you trial a module. This is the row where "I'll just uninstall it" quietly fails.

7. Cron jobs and webhooks

How to run it: check the module's documentation and configuration page for anything that runs on a schedule or calls an external service in the background — syncs, feeds, cleanup tasks, "connect your account" integrations.

Pass: background jobs are disclosed, and you can turn them off. Failure mode: undisclosed background activity — a task hammering your database on a schedule, or a webhook shipping your data somewhere you didn't realise. You can't manage what you don't know is running.

8. Checkout, order and customer-data touchpoints

How to run it: with the module installed on staging, place a full test order end to end. Search for a product. Open a product page. Open the main back-office screens. Does everything still work exactly as before?

Pass: checkout, search, product pages and admin are unaffected unless that's literally the module's job. Failure mode: a module that touches the order flow or customer records is touching your revenue and your compliance obligations. A checkout that breaks — or silently miscalculates — costs you real money the day it ships, not in a lab.

9. Multishop, language and currency

How to run it: if you run more than one shop, more than one language, or more than one currency, test the module in each. Switch shop, switch language, switch currency, and use the feature.

Pass: the module respects your setup — correct per shop, translated per language, correct amounts per currency. Failure mode: a module built and tested against "shop 1, English, euros" that hard-codes those assumptions. It looks fine in the demo and falls apart on your second storefront or your Polish customers' prices.

10. PrestaShop and PHP compatibility

How to run it: read the compatibility statement on the product page, and match it against your PrestaShop version (1.7, 8.x, or 9.x) and your PHP version.

Pass: the vendor names the exact versions the module supports and keeps that current as PrestaShop releases new versions. Failure mode: "compatible with all versions." No serious module is tested against every PrestaShop and PHP version ever shipped; that claim is marketing, and it's the row most likely to break the day you upgrade your store.

11. Changelog and support trail

How to run it: look for a dated changelog and a real support channel before you buy.

Pass: the module has a visible history of updates and a way to reach a human who maintains it. Failure mode: no changelog and no support means no owner. A module with no maintenance is a module that will eventually stop working on a PrestaShop or PHP upgrade, with nobody to fix it — and you'll find out at the worst possible time.

12. The reversibility test

How to run it: this is the whole checklist in one motion, on staging. Snapshot your store. Install the module. Disable it. Uninstall it. Compare the store to your snapshot.

Pass: install → disable → uninstall leaves the store essentially as it was — no leftover files, no orphaned tables, no broken pages. Failure mode: anything that doesn't come back. If a module can't be cleanly removed on a test copy, it certainly can't be cleanly removed from your live store under pressure.

Red flags, and what each one actually means

You won't always have time for the full twelve. These are the shortcuts — signals that, on their own, justify a much harder look. Each maps to a concrete way things go wrong:

None of these is proof a module is bad. Cheap and simple code can be perfectly good; a small vendor can be excellent. The issue is never the price or the author — it's unmanaged risk. A red flag just means the risk hasn't been managed for you, so you have to manage it yourself before it reaches your live store.

Where the official standards fit

PrestaShop itself publishes the technical rules a well-built module is supposed to follow. You don't need to implement them, but they're useful to point a vendor at, and they line up with much of what's above. PrestaShop publishes the Technical Development Standards a well-built module is expected to follow — override discipline, core-table and asset-performance hygiene, security, and version compatibility — alongside the Quality Standards behind the Verified+ badge on the Addons marketplace. Neither is a guarantee on its own — plenty of good modules live outside the marketplace, and a badge is not a substitute for the observations above — but they're a sensible part of the picture. If you buy through the marketplace, our PrestaShop Addons buyer's guide covers how to read a listing.

A safe install order, start to finish

Put together, the whole thing is one calm sequence:

• Back up your live store — files and database.
• Install on a staging copy that mirrors your real theme, modules and settings.
• Snapshot the staging store, then run the twelve checks above.
• Watch the Network tab on your homepage for new domains and site-wide assets.
• Place a test order and exercise search, product pages and admin.
• Uninstall and compare to your snapshot — confirm it comes back clean.
• Only then install on live, during a quiet window, and check your key pages once more.

Common questions

Do I need a developer to vet a module?

For most of these checks, no. Counting third-party requests, testing checkout, and running the install → disable → uninstall test are all things you can do from a browser and your back office on a staging copy. A couple of checks — looking in /override, listing database tables — need file or database access, which your host or developer can hand you, but you never have to read any code.

If a module is on the official PrestaShop marketplace, is it automatically safe?

Marketplace validation and the Verified+ badge are a real, useful signal — they check many of these things for you. But they are not a substitute for watching the module behave on your own store, with your theme and your other modules. Plenty of good modules also live outside the marketplace. Run the checks either way.

The module is free — is that a red flag on its own?

No. Free and cheap modules can be excellent, and expensive ones can be careless. Price tells you nothing about how the code behaves. The scorecard is about managed risk, not cost: a free module that passes these checks is safer than a paid one that fails them.

If I only have time for one check, which is it?

Open your homepage's Network tab and count new third-party domains after installing. It takes a minute, needs no code, and catches the most common and most damaging kind of careless module — the one that taxes every page for a feature you'll rarely see.

It sounds like a lot written out; in practice it's an afternoon, and it's a great deal cheaper than the afternoon you'd otherwise spend finding out why your storefront got slow, or why a page won't come back after you removed the module that broke it. For the story behind why this matters — and an honest account of a mistake we made ourselves — read what a PrestaShop module can do that uninstall won't undo. And yes: run this checklist against our modules too. That's what it's for. If you'd like it run for you, our free security scan and performance audit are built on exactly these checks — and if you'd rather your store watch these things continuously rather than at install time, that's the job of Performance Revolution and Security Revolution.