Basics of PrestaShop Development

PrestaShop was imagined so that outsider modules could undoubtedly expand upon its establishments, making it an incredibly adjustable online business programming.


PrestaShop’s customization depends on three prospects:

  • Templates
  • Addons
  • Overriding

Templates are investigated in full in the Designer Guide.

Addons (modules) and the override framework are investigated in this Developer Guide, beginning with the “Concepts” area underneath. You can become familiar with each in the accompanying sections:

Of course, PrestaShop is furnished with in excess of 100 modules, empowering you to dispatch your online business rapidly and for nothing.


In excess of 3000 modules are likewise accessible on the Addons commercial center. These extra modules were worked by the PrestaShop organization or individuals from the PrestaShop people group, and are sold at reasonable costs. As an engineer, you can likewise share your modules on this site, and get 70% of the sums related with the offer of your manifestations. Join now!

PrestaShop White


You ought to be comfortable with PHP and Object-Oriented Programming prior to endeavoring to compose your own module.

You can learn PHP here:

  • Beginning on PHP documentation
  • CodeCademy Learning of PHP

Besides you can check Object-Oriented programming here:

  • Object-oriented skills in programming on Wikipedia
  • PHP with object-oriented approach for amateurs

An addon is an expansion to PrestaShop that empowers any engineer to add the accompanying:

  • Give extra usefulness to PrestaShop
  • View extra things on the site (item determination, and so forth)
  • Speak with other internet business administrations (purchasing guides, installment stages, coordinations, and so forth)

Framework is a system overrides itself. PrestaShop utilizes totally object-situated code. One of the benefits of this is that, with the correct code engineering, you can undoubtedly supplant or expand portions of the center code with your own custom code, without contacting the center code. Your code along these lines abrogates the center code, causing PrestaShop to carry on as you lean toward it to. It isn’t prescribed to utilize an abrogate in a module that you plan to circulate (for example through the PrestaShop Addons commercial center), and they are illegal in accomplice modules. Save them for your own shop.

PrestaShop’s specialized engineering

MVC as the root

Until PrestaShop 1.6, PrestaShop depended on a 3-level design:

  • Item/information. Data set admittance is controlled through documents in the “classes” organizer.
  • Information control. Client gave content is constrained by documents in the root organizer.
  • Plan. The entirety of the topic’s documents are in the “subjects” envelope.

This is a similar standard as the Model>View>Controller (MVC) design, just in a less difficult and more open manner.

A 3-level design has numerous favorable circumstances:

  • It’s simpler to peruse the product’s code.
  • Designers can add and alter code quicker.
  • Visual creator and HTML integrators can work with the bounds of the/topics envelope without understanding or even read a solitary line of PHP code.
  • Engineers can chip away at extra information and modules that the HTML integrators can utilize.


A model addresses the application’s conduct: information handling, data set association, and so forth

It portrays or contains the information that have been prepared by the application. It deals with this information and ensures its respectability.


A view is the interface with which the client connects.

Its first job is to show the information that has been given by the model. Its subsequent job is to deal with all the activities from the client (mouse click, component choice, catches, and so forth), and send these occasions to the regulator.

The view doesn’t do any handling; it just shows the consequence of the preparing performed by the model, and connects with the client.


The Controller oversees synchronization occasions between the Model and the View, and updates both on a case by case basis. It gets all the client occasions and triggers the activities to perform.

In the event that an activity needs information to be changed, the Controller will “ask” the Model to change the information, and thusly the Model will advise the View that the information has been changed, so the View can refresh itself.

Pushing ahead with Symfony

While all variants of PrestaShop up to 1.6 invested heavily in just utilizing a custom design, it was chosen to join the Symfony PHP system beginning with PrestaShop 1.7.

The driving thought is that we need our code to be more strong, more measured, and completely testable. The 1.6 design, acquired from form 1.5 and long periods of PrestaShop advancement, isn’t getting any more youthful, and its age is truly beginning to show.

Utilizing a demonstrated and famous open-source system will permit us to zero in on our center business code (dealing with a truck, taking care of requests, figuring costs and charges, producing solicitations, and so on) with more noteworthy proficiency, while appreciating the steadiness of a universally perceived structure.

In the documentation, we will allude to the 1.6 structure as the “inheritance” system, as this is a famous assignment utilized in the product world.

Leave A Comment

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

ten + 12 =