Diving into PrestaShop Core development

Fundamentals

Concepts

A module is an extension to PrestaShop that enables any developer to add the following:

• Provide additional functionality to PrestaShop.
• View additional items on the site (product selection, etc.).
• Communicate with other e-commerce services (buying guides, payment platforms, logistics...)
• etc.

The company behind PrestaShop provides more than 100 modules for free with the tool itself, enabling you to launch your business quickly and for free.

More than 1600 add-ons are also available at the official add-ons site.
These additional modules were built by the PrestaShop company or members of the PrestaShop community, and are sold at affordable prices.
As a developer, you can also share your modules on this site, and receive 70% of the amounts associated with the sale of your creations. Sign up now!

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.

Our developer team chose not to use a PHP framework, such as Zend Framework, Symfony or CakePHP, so as to allow for better readability, and thus faster editing.

This also makes for better performances, since the software is only made of the lines of code it requires, and does not contain a bunch of supplemental generic libraries.

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.

Model

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.

View

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.

Controller

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.

The PrestaShop file structure

The PrestaShop developers have done their best to clearly and intuitively separate the various parts of the software.

Here is how the files are organized:

• /admin: contains all the PrestaShop files pertaining to the back-office. When accessing this folder with your browser, you will be asked to provide proper identification, for security reasons. Important: you should make sure to protect that folder with a .htaccess or .htpasswd file!
• /cache: contains temporary folders that are generated and re-used in order to alleviate the server's load.
• /classes: contains all the files pertaining to PrestaShop's object model. Each file represents (and contains) a PHP class, and its methods/properties.
• /config: contains all of PrestaShop's configuration files. Unless asked to, you should never edit them, as they are directly handled by PrestaShop's installer and back-office.
• /controllers: contains all the files pertaining to PrestaShop controllers – as in Model-View-Controller (or MVC), the software architecture used by PrestaShop. Each file controls a specific part of PrestaShop.
• /css: contains all CSS files that are not attached to themes – hence, these are mostly used by the PrestaShop back-office.
• /docs: contains some documentation. Note: it should be deleted in a production environment.
• /download: contains your digital products, which can be downloaded: PDFs, MP3s, etc.
• /img: contains all of PrestaShop's default images, icons and picture files – that, those that do not belong to the theme. This is where you can find the pictures for product categories (/c sub-folder, those for the products (/p sub-folder) and those for the back-office itself (/admin sub-folder).
• /install: contains all the files related to PrestaShop's installer. You will be required to delete it after installation, in order to increase security.
• /js: contains all JavaScript files that are not attached to themes. Most of them belong to the back-office. This is also where you will find the jQuery framework.
• /localization: contains all of PrestaShop's localization files – that is, files that contain local information, such as currency, language, tax rules and tax rules groups, states and the various units in use in the chosen country (i.e., volume in liter, weight in kilograms, etc.).
• /log: contains the log files generated by PrestaShop at various stages, for instance during the installation process.
• /mails: contains all HTML and text files related to e-mails sent by PrestaShop. Each language has its specific folder, where you can manually edit their content if you wish.
• /modules: contains all of PrestaShop's modules, each in its own folder. If you wish to definitely remove a module, first uninstall it from the back-office, then only can you delete its folder.
• /override: this is a special folder that appeared with PrestaShop 1.4. By using PrestaShop's regular folder/filename convention, it is possible to create files that override PrestaShop's default classes or controllers. This enables you to change PrestaShop core behavior without touching to the original files, keeping them safe for the next update.
• /pdf: contains all the template files (.tpl) pertaining to the PDF file generation (invoice, delivery slips, etc.). Change these files in order to change the look of the PDF files that PrestaShop generates.
• /themes: contains all the currently-installed themes, each in its own folder.
• /tools: contains external tools that were integrated into PrestaShop. For instance, this were you'll find Smarty (template/theme engine), FPDF (PDF file generator), Swift (mail sender), PEAR XML Parser (PHP tool).
• /translations: contains a sub-folder for each available language. However, if you wish to change the translation, you must do so using the PrestaShop internal tool, and not edit them directly in this folder.
• /upload: contains the files that would be uploaded by clients for customizable products (for instance, a picture that a client wants printed on a mug).
• /webservice: contains files that enable third-party applications to access PrestaShop through its API.

About the cache

The /cache/Class_index.php file contains the link between the class and the declaration file. It can be safely deleted.

The /cache/xml folder contains the list of all the base modules.

When the store's front-end doesn't quite reflect your changes and emptying the browser's cache is not effective, you should try emptying the following folders:

• /cache/smarty/cache
• /cache/smarty/compile

PrestaShop's context

The Context is a technical feature introduced with version 1.5 of PrestaShop. Its two goals are:

• preventing developers from using global variables.
• enabling them to change the context of some methods.

The Context is a light implementation of the Registry design pattern: it is a class that stores the main PrestaShop information, such as the current cookie, the customer, the employee, the cart, Smarty, etc.

Before version 1.5, you had to rely on the cookie in order to access this data:

$cookie->id_lang;

Now that the Context is available, the same data can be accessed more cleanly:

$this->context->language->id;

You can read more about the Context in the "Using the Context Object" page of the Developer Guide.

Accessing the database

The database structure

PrestaShop's database tables start with the ps_ prefix. Note that this can be customized during installation

All table names are in lowercase, and words are separated with an underscore character ("_").

When a table establishes the links between two entities, the names of both entities are mentioned in the table's name. For instance, ps_category_product links products to their category.

A few details to note:

• Use the id_lang field to store the language associated with a record.
• Use the id_shop field to store the store associated with a record.
• Tables which contain translations must end with the _lang suffix. For instance, ps_product_lang contains all the translations for the ps_product table.
• Tables which contain the records linking to a specific shop must end with the _shop suffix. For instance, ps_category_shop contains the position of each category depending on the store.

The ObjectModel class

This is the main object in PrestaShop object model. It can be overridden with precaution.

Defining the model

You must use the $definition static variable in order to define the model.

For instance:

/**
* Example from the CMS model (CMSCore) 
*/
public static $definition = array(
  'table' => 'cms',
  'primary' => 'id_cms',
  'multilang' => true,
  'fields' => array(
    'id_cms_category'  => array('type' => self::TYPE_INT, 'validate' => 'isUnsignedInt'),
    'position'         => array('type' => self::TYPE_INT),
    'active'           => array('type' => self::TYPE_BOOL),
    // Lang fields
    'meta_description' => 
        array('type'=>self::TYPE_STRING, 'lang'=>true, 'validate'=>'isGenericName', 'size'=>255),
    'meta_keywords'    => 
        array('type'=>self::TYPE_STRING, 'lang'=>true, 'validate'=>'isGenericName', 'size'=>255),
    'meta_title'       => 
        array('type' =>self::TYPE_STRING, 'lang'=>true, 'validate'=>'isGenericName', 'required'=>true, 'size'=>128),
    'link_rewrite'     =>
        array('type' => self::TYPE_STRING, 'lang'=>true, 'validate'=>'isLinkRewrite', 'required'=>true, 'size'=>128),
    'content'          => 
        array('type' => self::TYPE_HTML, 'lang' => true, 'validate' => 'isString', 'size' => 3999999999999),
  ),
);

A model for many stores and/or languages

In order to have an object in many languages:

'multilang' => true

In order to have an object depending on the current store

'multishop' => true

In order to have an object which depend on the current store, and in many languages:

'multilang_shop' => true

The main methods

Any overriding of its methods is bound to influence how all the other classes and methods act. Use with care.

The DBQuery class

The DBQuery class is a query builder, which helps you creation SQL queries. For instance:

$sql = new DbQuery();
$sql->select('*');
$sql->from('cms', 'c');
$sql->innerJoin('cms_lang', 'l', 'c.id_cms = l.id_cms AND l.id_lang = '.(int)$id_lang);
$sql->where('c.active = 1');
$sql->orderBy('position');
return Db::getInstance()->executeS($sql

The Dispatcher

The Dispatcher is one of the main technical features of v1.5. It handles URL redirections. Instead of using multiple files on the root folder like product.php, order.php or category.php, only one file is used: index.php. From now on, internal URL will look like index.php?controller=category, index.php?controller=product, etc.

Additionally, the Dispatcher is built to support URL rewriting. Therefore, when URL-rewriting is off, PrestaShop will use the following URL form:

http://myprestashop.com/index.php?controller=category&id_category=3&id_lang=1
http://myprestashop.com/index.php?controller=product&id_product=1&id_lang=1

...and URL-rewriting is on (or "Friendly URLs"), PrestaShop's Dispatcher will correctly support this URL form:

http://myprestashop.com/en/3-music-ipods
http://myprestashop.com/en/1-ipod-nano.html

There are several advantages for this system:

• It is easier to add a controller.
• You can use custom routes to change your friendly URLs (which is really better for SEO!)
• There is only one single entry point into the software, which improves PrestaShop's reliability, and facilitates future developments.

The Dispatcher makes use of three new 1.5 abstract classes: Controller, FrontController and AdminController (the last two inheriting from the first one).

New routes can be created by overriding the loadRoutes() method.
The store administrator can change a controller's URL using the "SEO & URLs" page in the back-office's "Preferences" menu.

Controllers

In the MVC architecture, a controller manages the synchronization events between the View and the Model, and keeps them up to date. 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.

All of PrestaShop's controllers actually override the Controller class through another inheriting class, such as AdminController, ModuleAdminController, FrontController or ModuleFrontController.

The FrontController class

Some of the class' properties

Execution order of the controller's functions

1. __contruct(): Sets all the controller's member variables.
2. init(): Initializes the controller.
3. setMedia() or setMobileMedia(): Adds all JavaScript and CSS specifics to the page so that they can be combined, compressed and cached.
4. postProcess(): Handles ajaxProcess.
5. initHeader(): Called before initContent().
6. initContent(): Initialize the content.
7. initFooter(): Called after initContent().
8. display() or displayAjax(): Displays the content.

Existing controllers

Overriding a controller

Thanks to inheritance, you can change a controller's behaviors, or add new ones.

PrestaShop's controllers are all stored in the /controllers folder, and use the Core suffix.

For instance, when working with the category controller:

• File: /controllers/CategoryController.php
• Class: CategoryControllerCore

In order to override a controller, you must first create a new class without the Core suffix, and place its file in the /override/controllers folder.

For instance, when overriding the category controller:

• File: /override/controllers/front/CategoryController.php
• Class: CategoryController

Views

PrestaShop uses the Smarty template engine to generate its views: http://www.smarty.net/

The views are stored in .tpl files.

A view name is generally the same as the name for the code using it. For instance, 404.php uses 404.tpl.

Cookies

PrestaShop uses encrypted cookies to store all the session information, for visitors/clients as well as for employees/administrators.

The Cookie class (/classes/Cookie.php) is used to read and write cookies.

In order to access the cookies from within PrestaShop code, you can use this:

$this->context->cookie;

All the information stored within a cookie is available using this code:

$this->context->cookie->variable;

If you need to access the PrestaShop cookie from non-PrestaShop code, you can use this code:

include_once('path_to_prestashop/config/config.inc.php');
include_once('path_to_prestashop/config/settings.inc.php');
include_once('path_to_prestashop/classes/Cookie.php');
$cookie = new Cookie('ps'); // Use "psAdmin" to read an employee's cookie.

Data stored in a visitor's cookie

Data stored in an employee's cookie

Hooks

Hooks are a way to associate your code to some specific PrestaShop events.

Most of the time, they are used to insert content in a page.

For instance, the PrestaShop default theme's home page has the following hooks:

Hooks can also be used to perform specific actions under certain circumstances (i.e. sending an e-mail to the client).

Using hooks

...in a controller

It is easy to call a hook from within a controller: you simply have to use its name with the hookExec() method: Module::hookExec('NameOfHook');

For instance:

$this->context->smarty->assign('HOOK_LEFT_COLUMN', Module::hookExec('leftColumn'));

...in a module

In order to attach your code to a hook, you must create a non-static public method, starting with the "hook" keyword followed by either "display" or "action", and the name of the hook you want to use.

This method receives one (and only one) argument: a table of the contextual information sent to the hook.

public function hookDisplayNameOfHook($params)
{
    // Your code.
}

In order for a module to respond to a hook call, the hook must be registered within PrestaShop. Hook registration is done using the registerHook() method. Registration is usually done during the module's installation.

public function install()
{
    return parent::install() && $this->registerHook('NameOfHook');
}

Existing hooks: front-office

Home page and general site pages

Product page

Cart page

Search page

Carrier choice page

Payment page

Order page

Existing hooks: back-office

General hooks

Orders and order details

Products

Statistics

Clients

Carriers

Creating your own hook

You can create new PrestaShop hooks by adding a new record in the ps_hook table in your MySQL database.

INSERT INTO `ps_hook` (`name`, `title`, `description`) VALUES ('nameOfHook', 'The name of your hook', 'This is a custom hook!');