Why I needed to change Prestashop

In this series of articles (4 at the moment, more to come) I’m going to discuss the development of customized code for Prestashop to meet the requirements of a specific project I had to deal with: the FadeurParts.be web shop.

You can have a look at FadeurParts.be (not in production yet, so username/password are prestashop/prestashop).

This includes PHP coding of modules, overrides and search providers as well as some changes in the Smarty templates, some JQuery scripts, some changes in the CSS and the creation of a child theme for the Classic theme. And finally three tables in the database. All the changes have been performed in a Prestashop 1.7.2 and 1.7.4 environment.

I’ve tried as much as possible to follow the Prestashop rules. Therefore, I’ve not touched the core code but always used the mechanisms provided by Prestashop to add functionalities and alter behavior. The good news is… when I upgraded from version 1.7.2 to 1.7.4, nothing was broken!

Using mechanisms such as modules, overrides, search providers and child theme made the task even more complex. As the source code is available, the temptation is great to modify directly the heart of Prestashop. But even the slightest change will forbid any upgrade to newer versions. In a few months or years, you will realize you’re stuck with an old version.

Now, in any case, if you need to alter and enrich Prestashop, you will need to understand how it works internally. At least partially. There is no quick and dirty way to do this, unless you need very tiny changes… It took me some times to get enough knowledge and produce working code. I hope that those articles will allow you to speed up the process.

Now, there are a lot of resources available. But they are scattered over the web. As far as I know, there is no Prestashop developer bible. No exhaustive Prestashop developer reference guide.

Things are made worst by the fact that Prestashop is moving from a legacy architecture to a new one, based on Symfony and Twig. So 1.7 is really a melting pot. Often, you will find documentation related to Prestashop 1.6 or 1.5, facing the challenge to figure out if this is valid for 1.7.

Finally, I couldn’t determine a definitive, logical, pattern used by the Prestashop developer team to decide where a PHP file is going to reside in the directory structure. But this is probably related to the move from one architecture to the other. Partially, at least…

Prestashop front office search mechanisms

In the front-end, Prestashop (1.7) offers several search mechanism to retrieve products.

Categories

The most obvious way to access products is via the categories. These are organized as a tree. There is a root, default category (named « Home », and you cannot delete it). Then you’re free to create any number of child categories in root. You can turn each category you’ve created into a parent… You can then put products in any category (i.e. a given category can contains products, sub-categories or both). Each product can be linked to several categories but must one and only one « default category ».

This way of classifying product is very convenient and most human beings raised in the « occidental culture » will immediately understand the concept. Prestashop, in its default view, will present on the left side a tree view of the categories.

Search by keyword and faceted search

There are other ways to search for products. You can search by keyword searches (which is very disappointing when you compare it to what we’re used to with search engines like Google).

You’ve also the so-called « faceted search » which can be very powerful when you want to emerge with a short list of products selected on several properties (for example clothes selected on type, size, color and price). This is great to answer questions such as « I would like to buy a trouser, size 32, black for no more than 50€). You can add brands, manufacturer and custom attributes…

But, basically, that’s all!

You will find modules to perform any search you want, but their are all based on the native product attributes of Prestashop: categories, description, price, attributes, characteristics, supplier, brand…

Custom search mechanism: filter by tractor

The FadeurParts project goal is to put online a catalogue of tractor spare parts (it would have been the same problem with spare parts for cars, motorbikes, airplanes or dish washers).

A typical customer landing in our webshop is looking for parts to maintain or repair the tractor he has. So, it’s meaningless to show him our >14,000 spare parts catalog when only 300 of these will fit its « John Deere 6920 ». What I need is a « filter by tractor » function. Easy to understand. Not easy to implement.

First of all, strictly speaking, a tractor is an entity by itself. As a spare part is. So it didn’t make sense to create a product attribute named « tractor ». For three reasons:

• Tractor has their own attributes such as years of production, power, maintenance schema…
• They are organized as a tree, exactly as categories. For example: John Deere (the make) > 6×20 (the series) > 6920 (the model) > 2002-2004 (the sub-model).
• There is a many-to-many relationship between tractors and products. One product can fit several tractors and, one tractor can have several products in the catalogue.

Why didn’t we use Prestashop categories ? We tried, but with 10,000 tractors (adding the « natural » categories such as engine, brake or gear box, we ended up with about 11,000 categories), 14,000 products and >300,000 possible combinations, we just killed the performance. It took minutes to retrieve a single product from the database. Yes, Prestashop can handle very large number of products, but not very large number of categories.

In addition, we wanted to preserve the navigation by categories (engine, brake, electrical…) while filtering products on a specific tractor model.

I needed something else. I needed to have a list of tractors, organized much the same way as categories (tree). I needed to relate tractors to products in a many-to-many relationship. I needed to be able to filter products based on a given tractor.

Overview of the solution

We implemented:

• Tractor tables in the database.
• Back-end forms to manage them.
• Front-end mechanisms allowing customer to filter products for a specific tractor.

Technically:

• Three database tables: pd_tractor, pd_tractor_lang (to be multi language compatible) and pd_product_tractor to store the relationship.
• One admin controller to manage the tractors.
• One admin hook to allow products to be linked to tractors.
• Two front-end modules:
  • One to allow the customer to search for tractors.
  • One to filter the categories and products based on the selected tractor.
  • Behind the scene: several hooks, three controller overrides (CategoryController, ProductController and SearchController) and a ProductSearchProvider that replaces the default Prestashop provider (this is also based on hooks).
• Some changes in the templates…

In the next articles, I will discuss the technical details of the implementation.

You can contact me by e-mail if you have comments or questions.
[gdlr_core_social_network email= »#pierre.debras@okai.be »]