Core concepts
The same words come up all the time in PrestaShop documentation and code: front office, back office, hook, context. This lesson is a vocabulary. Each concept is covered in detail later; here it matters to see what is what.
Front office and back office
| Part | Who uses it | Short name |
|---|---|---|
| Front office (the storefront) | The customer: catalogue, cart, order | FO |
| Back office (the admin panel) | The shop owner: products, orders, settings | BO |
These are two separate parts with different addresses, templates and controllers. A module usually works in both: it prints a block in the front office and offers a settings page in the back office.
Module, hook, theme
| Concept | What it is |
|---|---|
| Module | A folder in modules with a main class. It can be installed, disabled and removed from the back office |
| Hook | A named point in code or in a template where the engine asks modules: "does anyone want to add something?" |
| Theme | The templates, styles and scripts of the front office |
They are connected like this: the theme calls a hook, for example displayHome, at the right place of a page, and a module subscribed to that hook returns HTML. The theme does not know which modules are installed, and the module does not know how the theme is built.
Two cores
PrestaShop is gradually moving to the Symfony framework, so two worlds live in the code.
| Legacy core | New core | |
|---|---|---|
| Folders | classes, controllers | src |
| Templates | Smarty, .tpl files | Twig, .html.twig files |
| Where it works | The whole front office and part of the back office | Most back office pages |
| What the code looks like | Classes without namespaces: Product, Db | Symfony services, routes, controllers |
A module has to deal with both: a front office block is written the legacy way, a back office page the new way. The course always says which world an example belongs to.
Context
The context is an object of the Context class that holds everything about the current request: which shop, language and currency, who the customer is and what cart they have.
$context = Context::getContext();
$languageId = (int) $context->language->id;
$currencyCode = $context->currency->iso_code;
$customerName = $context->customer->firstname;The first line gets the context, the others read the language id, the currency code and the customer's name from it. Inside a module and a controller there is no need to call getContext(): the context is already in $this->context.
What the context holds
| Property | What is in it |
|---|---|
language | The current language |
currency | The current currency |
shop | The current shop |
customer | The customer in the front office |
cart | Their cart |
employee | The employee in the back office |
link | The builder of page addresses |
smarty | The template engine |
controller | The controller of the current page |
Several shops and languages
One installation can serve several shops and languages. That is why a product has no single name: it has one per language. That is also why many core methods take a language id and a shop id, which are usually taken from the context.
Common mistake
Code in the back office reads $this->context->customer or $this->context->cart and gets an empty object: there is no customer or cart there, there is an employee in $this->context->employee. In the front office it is the other way round. Before reading a context property, think about which side the code runs on.