Prestashop Development

PrestaShop was conceived so that third-party modules could easily build upon its foundations, making it an extremely customizable e-commerce software.

PrestaShop’s customization is based on three possibilities:

  • Themes,
  • Modules,
  • Overriding.

Themes are explored in full in the Designer Guide.

PrestaShop’s technical architecture

PrestaShop is based on a 3-tier architecture:

  • Object/data. Database access is controlled through files in the “classes” folder.
  • Data control. User-provided content is controlled by files in the root folder.
  • Design. All of the theme’s files are in the “themes” folder.

This is the same principle as the Model>View>Controller (MVC) architecture, only in a simpler and more accessible way.

While all versions of PrestaShop up to 1.6 took pride in only using a custom architecture, it was decided to incorporate the Symfony PHP framework starting with PrestaShop 1.7.

The driving idea is that we want our code to be more robust, more modular, and fully testable. The 1.6 architecture, inherited from version 1.5 and years of PrestaShop development, is not getting any younger, and its age is really starting to show.

Using a proven and popular open-source framework will allow us to focus on our core business code (managing a cart, handling orders, calculating prices and taxes, generating invoices, etc.) with greater efficiency, while enjoying the stability of a globally recognized framework.

A 3-tier architecture has many advantages:

  • It’s easier to read the software’s code.
  • Developers can add and edit code faster.
  • Graphic designer and HTML integrators can work with the confines of the /themes folder without having to understand or even read a single line of PHP code.
  • Developers can work on additional data and modules that the HTML integrators can make use of.


A model represents the application’s behavior: data processing, database interaction, etc.

It describes or contains the data that have been processed by the application. It manages this data and guarantees its integrity.


A view is the interface with which the user interacts.

Its first role is to display the data that is been provided by the model. Its second role is to handle all the actions from the user (mouse click, element selection, buttons, etc.), and send these events to the controller.

The view does not do any processing; it only displays the result of the processing performed by the model, and interacts with the user.


The Controller manages synchronization events between the Model and the View, and updates both as needed. It receives all the user events and triggers the actions to perform.

If an action needs data to be changed, the Controller will “ask” the Model to change the data, and in turn the Model will notify the View that the data has been changed, so that the View can update itself.