Online shops

Two PrestaShop shops make up this project: the first, which sells a monthly box by subscription, is in service; the second, an online grocery, was not published.

Role: Sole author
Period: June and September 2025
Status: In service. One shop in service, a second stopped before publication
Technologies: PrestaShop 8, PHP, MySQL, Docker Compose
Repositories: Two

Figure 1. What was written for the shop in service: a child theme and a module, with no modification of the PrestaShop core.

Context

These are two modest pieces of work: a standard PrestaShop, a child theme and a small module for each. The first shop presents three subscription plans for a monthly box. The second was to offer a grocery catalogue divided into three families, and its development stopped after two days.

The shop in service is Adanora; the name of the second one does not appear in this study.

Home page of adanora.ch: the menu of boxes on a green band, then a photograph of a towel, a bottle and a candle with the motto “Le beau et le bon, réunis dans un même geste”. — Figure 2. Home page of Adanora, the shop in service.

Problem

PrestaShop updates itself by replacing its files, so that any modification made to the core or to the provided theme is lost at the next update. The home page of the first shop also required a block that no standard module provides, namely three variants of one product presented as three plans. Finally, it had to be decided what gets versioned when the repository contains the entire tree of a CMS.

Answer

A child theme, no modification of the core

The child theme inherits the assets of the Classic theme and copies only the templates it modifies: the header, the footer, the product page, the product list and a few blocks of the home page. The templates of the modules are overridden from the theme’s directory, so that an update of a module does not erase them.

A module where the theme was not enough

The plans block is a module of about a hundred lines, which queries the database to obtain the three variants of the product and passes them to a template, which the theme in turn overrides to present them as three cards. The theme declares this module as a dependency, so that it is installed with it.

Plans block on a phone: the presentation text of the box, then the card of the three-month subscription — Figure 3. On a phone, the plans block of the home page, then the product page of the box.

Product page of the subscription box on a phone: the photograph of the box and the start of its description — Figure 3. On a phone, the plans block of the home page, then the product page of the box.

Knowing what to version

The first shop began by versioning the entire tree, that is more than thirty thousand files added in one commit, which then had to be removed by listing one by one the core directories to ignore. The second starts from the opposite rule: ignore everything, then bring back the themes and the module. This rule is safer, since a directory added by an update stays ignored, but getting it right still took four commits.

Limits and outlook

The repository of the first shop does not contain what is in service: the templates, the fonts and the module are for the most part outside version control there, and two delivery paths coexist without any document saying which one is authoritative. This code should be brought back under version control before any other change. The product identifier is moreover written into the module’s code, and the texts of the plans sit in the templates, outside the translation system.

The second shop never got beyond a draft: its module does not pass its data to its template, its child theme amounts to its declaration, and its catalogue stayed in files that were not imported. Neither of the two has a test or a scripted backup.

Back to the work