Writing your own PrestaShop Module – Part 1

So you want to write a module?


There has always been a little bit of Voodoo associated Prestashop modules. This has been mainly down to a lack of documentation available, but never fear — this series of tutorials aim to introduce module writing to the PHP programming masses. This series will look at building our very own fully functional module which will provide all the standard functionality that is the basis for many of the most common modules. It will also provide a basic framework that you can use as a  template for your own code. Later articles will look at creating Payment Modules and extending the Administration interface, but initially we’ll look at the class of modules which deal mainly with inserting content into your pages, as this best demonstrates the fundamental basic concepts of developing for PrestaShop.

Before we start

These articles assume at least a basic knowledge of PHP 5.x.x and its object oriented programming concepts. It is highly recommended, due to the way Prestashop renders pages, that you build yourself a development Prestashop store if you haven’t done so already (and if you haven’t then why not?). For the purposes of these articles we will be building the examples based on the current development release (at the time of writing but the code will be sufficiently generic that it should work with any version of Prestashop, certainly from version 1.1 onwards. You may find it useful to also familiarise yourself with the main third-party tools and libraries that Prestashop uses, and I particularly suggest familiarising yourself with the basics of the smarty template engine. Note that the Prestashop core handles the initialisation of the template class, so the specific areas to familiarise yourself with are the assigning of template variables, the creation (and display) of template files,  modifiers and template functions.

PrestaShop Architecture

Fundamental to understanding how Prestashop modules operate  is to be aware of how the shopping cart builds pages for output. The overall architecture is loosly based on the MVC principle of a “Model”, a “View” and a “Controller”.  While Prestashop doesn’t strictly stick to this philosophy, it is a useful to use it to visualise how the application works.


Models in Prestashop are provided via a set of objects extended from a base class “ObjectModel”. The ObjectModel class defines the common behaviour required to encapsulate the database tables which make up the store. It provides CRUD (Create, Read, Update and Delete) functionality as well as implementing the basis for data validation and multi-lingual support. By extended this basic functionality, specific classes are created to manage the data used by the store. The models for prestashop are defined in the /classes folder and manage all of the data held within the database (e.g. Category, Product, Order, Configuration etc.). The convention is that each class is stored in a php file whose name matches the contained class name, so Order.php for example contains the Order class.


The presentation of data from our shopping cart application is handled by the smarty template engine. Using a view allows us to separate out the business logic from the presentation. In a strict MVC environment there should be no processing of data by the view, only the display of data passed to it from a controller — and in the majority of cases this is true for Prestashop, although some Ajax/javascipt is employed by default to perform additional data processing. The view files for Prestashop are in general stored in the /themes folder, with the specific set of template files to be used being selectable from the Administration interface. Many modules also store their own specific template files within their own directory structure.


The controller is the main business logic for a “page” or collection of related pages to be displayed. They are responsible for interacting with the “Models” to retrieve data, apply business logic to the data and then output the results via one or more “Views”. In Prestashop these are contained in the root directory of the store installation, and correspond to the main “pages” that make up the web store.

OK, So where do modules fit in?

While the above describes the core functionality of Prestashop, and is sufficient to produce a working shopping cart, it is a little inflexible in terms of adding new functionality. If, for example, you wanted to modify the home page of your store with only the above architecture, you would have to modify the controller page directly to implement your change. Not only would this be bad in terms of code maintenance (you would have to apply changes and bug fixes manually to all of your modified controller pages when a new version is released) it also requires fairly detailed knowledge of programming to implement the changes.

In order to create a shopping cart system that is both easily extensible and maintainable by a non-technical store owner, additional functionality is inserted — “hooked” — into the above architecture by means of specially inserted “hook” points in the controller code, which can be exploited by user-installable “plugins”  (which Prestashop refer to as “modules”). In this case, these modules have the ability to output additional or modified content, add new functionality (business logic) to the controllers and gather information.

Payment modules are a specific class of module, but even they too hook into the standard controllers in order to provide alternative code execution paths. Administration panel extensions, operate in an entirely different way and the process is much more akin to adding additional controllers, so must be discussed separately. Thankfully the module architecture in Prestashop provides us with a fairly simple way of adding an administrative interface to modules, and in all but the most complex of cases this is the best method to use.


Having read this article you should now be familiar with the basic building blocks that go together to make up the Prestashop shopping cart. In the next part of this tutorial we will look at coding our first module using these concepts and begin extending Prestashop.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.