PrestaShop developer documentation: a 2026 reading guide
The PrestaShop official developer documentation presents an architecture in transition, where modules extend the shop through hooks, overrides replace core classes as a riskier option, and a webservice exposes shop data to other tools. For a buyer in 2026, its key message is that the safest extensions are the shallowest. The deeper a module changes the core, the more upgrades may cost. This guide reads the PrestaShop 9 documentation as it stood on 1 November 2026.
My interest, stated once: I build custom online stores, notably on Sylius, a competitor of PrestaShop. So I rely on PrestaShop's own text here, and I say where PrestaShop is the sensible choice.
PrestaShop architecture: four layers living together
The architecture introduction names four PHP subsystems. Legacy is the older code in the classes and controllers folders, being progressively replaced since version 1.6.1. Core is the newer code designed around SOLID principles, a set of rules for maintainable code. Adapter wraps legacy classes so the newer code can use them. The PrestaShop Bundle holds the Symfony parts, including controllers, forms and views. The same page expects these four stacks to remain for the whole lifetime of PrestaShop 9.
That is neither a scandal nor a detail. It means a developer works with several generations of code. The storefront still uses Smarty, with the default Classic theme built on Bootstrap 4 alpha 5, which the page says cannot be updated to newer Bootstrap versions. Admin pages mix Smarty and Twig. When a quote seems high for a change that looks small, this can be one honest reason.
Modules and hooks: the normal way to extend
A hook is a named point in the software where a module can add something. The hooks documentation separates display hooks, which output content, from action hooks, which react to an event such as an order being created. A module registers the hooks it needs during installation, then implements a matching method.
This is PrestaShop's real strength for a merchant: many needs can become small, separate modules, and the ecosystem already covers common ones. If your need fits a hook, the risk stays moderate. Before accepting a custom module, ask which hooks it uses and what happens to it during an upgrade.
Overrides: what the documentation warns about
An override replaces behaviour of a core class or controller from a file in the module. The overrides page is direct: there are limitations and risks, so keep them for your own shop. It adds that overrides are exclusive, which can stop another module from using the same behaviour predictably. It advises against them in distributed modules and says they are forbidden in partner modules. It also recommends checking hooks, classes, controllers and Symfony service overrides first, and creating a custom table rather than overriding to store data.
For a buyer, this gives a very concrete test. Ask your provider for the list of files in the shop's override folder and the reason for each one. An empty list tells you little on its own, and a long list without explanations tells you where your upgrade budget will go. The architecture page confirms the logic when it warns that deeper integration increases upgrade and interoperability risk.
| Extension method | Typical use | Risk at upgrade | Question to ask |
|---|---|---|---|
| Display or action hook | Add a block, react to an event | Lower | Which hooks, and are they still present in the target version? |
| Custom table and ObjectModel | Store extra data | Lower to moderate | How is the data migrated? |
| Symfony service override | Replace a modern component | Moderate | Is the decorated interface stable? |
| Class or controller override | Change core behaviour | Higher | Why was no hook usable? |
The risk levels in this table are my own assessment, based on the warnings cited above. They are not a PrestaShop rating.
Webservice and Admin API: two ways to connect other tools
The Webservice is described as a CRUD API, meaning it can create, read, update and delete, that gives third party tools access to the shop's database. The Admin API is the newer option, based on API Platform 3 and using OAuth for authorization. Its endpoints are organised around business operations rather than data tables, a difference the documentation draws explicitly.
The choice affects your data. An ERP integration that writes directly to objects may bypass business logic if it is badly designed, whereas an operation that expresses a business action keeps those rules closer. Ask which interface will be used for each exchange, how credentials are limited, and how failures are retried.
Requirements to check before budgeting
The system requirements page recommends PHP 8.5 and shows a compatibility chart that varies across 9.x releases, with MySQL 5.7 or MariaDB 10.2 as minimums. If your shop runs an older PrestaShop, the real question is whether your custom modules and overrides survive this jump. Have them inventoried before you accept a migration quote.
When PrestaShop is the right choice, and when it is not
PrestaShop makes sense when your need is mostly standard, when modules cover the gaps, and when you want to adapt your processes rather than rewrite them. Moving away just to have newer technology is rarely justified. Conversely, if your margin depends on rules that keep fighting the core, such as unusual pricing or complex order flows, a framework may cost less over several years. My reading of the Sylius documentation covers that alternative.
A good first step costs nothing: list your overrides and the changes you have postponed because they seemed too risky. If you would like a second opinion, you can describe your situation through my online store page. If your shop only needs a careful update, I will say so.