Modules and extensions: buy, build, repair

Who this section is for

People arrive here in two very different states of mind. Either a function is missing: a product configurator, instalment payments, a tracking screen for the team, a notification that does not exist as standard. Or an installed module is causing trouble: it stopped showing after an update, it clashes with another one, it slows every page down, or its vendor has gone quiet.

In both cases the underlying question is the same: how far should you lean on what already exists, and at what point is it better to write code you control. These pages answer by giving the criteria rather than a single recommendation — the right call depends on order volume, on how long the shop is expected to live, and on who will maintain it afterwards.

How the section is organised

The twenty-four pages follow the life of a module. Decision pages first: buy or build, official, third party or bespoke, what actually drives the price, how to scope a need before asking for a quote. Then the most common functional needs: subscriptions and member areas, deposits and instalments, configurators, PDF documents, notifications, an extra field on a product or an order, a business screen in the admin, after-sales handling, background processing.

Then the failures: a module broken by an update, a conflict between two modules, an active module that displays nothing, overwritten changes, a module slowing the shop down, a vendor that disappeared. And finally the life cycle: auditing an existing set of modules, testing before production, uninstalling cleanly, maintaining over time, taking over unfinished work.

What a module actually does to your shop

A module is not a brick sitting beside the site: it fits inside it. On PrestaShop it attaches to hooks, adds its own tables, and may drop a file into override/ to change the behaviour of a core class. That is where most conflicts start: two modules that want to override the same method cannot coexist, and the second simply fails to place its override, often with nothing visible to the merchant.

On WooCommerce the equivalent mechanism runs through actions and filters, and through templates copied into the child theme under woocommerce/. Those copies do not follow the extension's updates: when WooCommerce changes a template, the copy keeps being used as it is, and the page renders from an outdated version. It is the most ordinary reason a checkout loses a legal notice or a field after a version bump.

Keeping those two mechanisms in mind is enough to see why a set of modules degrades over time, and why the question to ask before buying is not only whether it does what you want, but what it touches.