Writing your own Prestashop Module – Part 2

Creating a basic module


In this second part of the series we will look at creating our first basic Prestashop module that can be controlled from the Back Office.

The Module class

Similar to the ObjectModel base class, all Prestashop modules are extended from a common base class used to define their basic functionality. The “Module” class provides the interface between the administration screens and your module as well as providing internationalisation and “hook” management functionality.

Coding conventions

Before we can write our first code there is one more element that needs to be considered — that of module class, directory and file naming.

In Prestashop, modules must be located within the /modules directory below your base store installation directory. In addition the module directory and class source file must be named in lower case, with the same name as the module class we choose. Note that the module class name itself does not have to be lowercase (by convention class names use “Camel case”), but it is essential that the folder it resides in and the source file follow this convention.

An “empty” module

In this part of the tutorial we will create a module “TutorialFirst” which demonstrates the mandatory code required to create our very first module. The first step is to create our directory on the server and name it “tutorialfirst”. We then need to create the main module class file within this directory and insert the following code:

class TutorialFirst extends Module
function __construct()
$this->name = 'tutorialfirst';

$this->tab = 'eCartService.net Tutorials';
$this->version = '0.1.0';
$this->displayName = $this->l('First Tutorial Module');
$this->description = $this->l('Our very first module - it does absolutely nothing at all.');
// End of: tutorialfirst.php

We save this file as “tutorialfirst.php” in our module directory and upload to our server. Although the above code doesn’t look like very much, it is actually packed with functionality thanks to the base class it extends. Once you’ve uploaded to your development site you will be able the see the module listed under the group heading “eCartService.net Tutorials” and you can now install and uninstall it.

Let’s look at what we’re doing in this code, and why.

$this->name = 'tutorialfirst';

These first two lines in the class constructor are concerned with setting up the basic properties of the module and ensuring that we properly inherit required functionality from the base class. First we need to set up the “internal” name of the module — note that this again follows the naming convention for the module directory and main class definition file, and again is the class name in lower case. Once this is done we can safely call the parent constructor to allow it to set up the other necessary internal module properties for us.

Next we define the properties that will be used when displaying our module in the Back Office.

$this->tab = 'eCartService.net Tutorials';
$this->version = '0.1.0';
$this->displayName = $this->l('First Tutorial Module');
$this->description = $this->l('Our very first module - it does absolutely nothing at all.');

The $this->tab member variable defines how we wish our module to be classified by the Back Office in the modules list. In general we would choose one the the standard categories (e.g. ‘Advertisement’, ‘Products’, ‘Tools’, ‘Blocks’ etc.) however it is entirely up to you how you wish to use this property, and in the case of these examples I’ve chosen to group them under the heading “eCartservice.net Tutorials”.

The $this->version member variable allows us to display the current module version in the modules list, which will allow users to identify visually which version of our module they are using. This may also be useful in allowing us to identify old and outdated module versions later, using an external module distribution site.

The final two member variables are used to display information regarding our module in the modules list, and are fairly self-explanatory. Note however that these are being set using the $this->l() Module class function however, rather than just being assigned as the static strings directly.

The l() (base class) member function implements language support, and enables the store owner to provide translations. The English language version of the text we wish to display is passed to this function, and when defined in this way the store owner can use the Tools->Translations Back Office screens to translate them into the language of their choice. Wrapping any static text used in our module with this function enables the translation functionality and should be use for all static text within modules which isn’t language dependent.


Having read this article you should now be able to create a new module which can be listed and controlled from the Prestashop Back Office and optionally displaying this information in the store owner’s own language. In the next part of this tutorial we will look at extending our first module to allow configuration, and based on this configuration display output in a specified area of a page.

Writing your own PrestaShop Module – Part 1

So you want to write a module?


There has always been a little bit of Voodoo associated Prestashop modules. This has been mainly down to a lack of documentation available, but never fear — this series of tutorials aim to introduce module writing to the PHP programming masses. This series will look at building our very own fully functional module which will provide all the standard functionality that is the basis for many of the most common modules. It will also provide a basic framework that you can use as a  template for your own code. Later articles will look at creating Payment Modules and extending the Administration interface, but initially we’ll look at the class of modules which deal mainly with inserting content into your pages, as this best demonstrates the fundamental basic concepts of developing for PrestaShop.

Before we start

These articles assume at least a basic knowledge of PHP 5.x.x and its object oriented programming concepts. It is highly recommended, due to the way Prestashop renders pages, that you build yourself a development Prestashop store if you haven’t done so already (and if you haven’t then why not?). For the purposes of these articles we will be building the examples based on the current development release (at the time of writing but the code will be sufficiently generic that it should work with any version of Prestashop, certainly from version 1.1 onwards. You may find it useful to also familiarise yourself with the main third-party tools and libraries that Prestashop uses, and I particularly suggest familiarising yourself with the basics of the smarty template engine. Note that the Prestashop core handles the initialisation of the template class, so the specific areas to familiarise yourself with are the assigning of template variables, the creation (and display) of template files,  modifiers and template functions.

PrestaShop Architecture

Fundamental to understanding how Prestashop modules operate  is to be aware of how the shopping cart builds pages for output. The overall architecture is loosly based on the MVC principle of a “Model”, a “View” and a “Controller”.  While Prestashop doesn’t strictly stick to this philosophy, it is a useful to use it to visualise how the application works.


Models in Prestashop are provided via a set of objects extended from a base class “ObjectModel”. The ObjectModel class defines the common behaviour required to encapsulate the database tables which make up the store. It provides CRUD (Create, Read, Update and Delete) functionality as well as implementing the basis for data validation and multi-lingual support. By extended this basic functionality, specific classes are created to manage the data used by the store. The models for prestashop are defined in the /classes folder and manage all of the data held within the database (e.g. Category, Product, Order, Configuration etc.). The convention is that each class is stored in a php file whose name matches the contained class name, so Order.php for example contains the Order class.


The presentation of data from our shopping cart application is handled by the smarty template engine. Using a view allows us to separate out the business logic from the presentation. In a strict MVC environment there should be no processing of data by the view, only the display of data passed to it from a controller — and in the majority of cases this is true for Prestashop, although some Ajax/javascipt is employed by default to perform additional data processing. The view files for Prestashop are in general stored in the /themes folder, with the specific set of template files to be used being selectable from the Administration interface. Many modules also store their own specific template files within their own directory structure.


The controller is the main business logic for a “page” or collection of related pages to be displayed. They are responsible for interacting with the “Models” to retrieve data, apply business logic to the data and then output the results via one or more “Views”. In Prestashop these are contained in the root directory of the store installation, and correspond to the main “pages” that make up the web store.

OK, So where do modules fit in?

While the above describes the core functionality of Prestashop, and is sufficient to produce a working shopping cart, it is a little inflexible in terms of adding new functionality. If, for example, you wanted to modify the home page of your store with only the above architecture, you would have to modify the controller page directly to implement your change. Not only would this be bad in terms of code maintenance (you would have to apply changes and bug fixes manually to all of your modified controller pages when a new version is released) it also requires fairly detailed knowledge of programming to implement the changes.

In order to create a shopping cart system that is both easily extensible and maintainable by a non-technical store owner, additional functionality is inserted — “hooked” — into the above architecture by means of specially inserted “hook” points in the controller code, which can be exploited by user-installable “plugins”  (which Prestashop refer to as “modules”). In this case, these modules have the ability to output additional or modified content, add new functionality (business logic) to the controllers and gather information.

Payment modules are a specific class of module, but even they too hook into the standard controllers in order to provide alternative code execution paths. Administration panel extensions, operate in an entirely different way and the process is much more akin to adding additional controllers, so must be discussed separately. Thankfully the module architecture in Prestashop provides us with a fairly simple way of adding an administrative interface to modules, and in all but the most complex of cases this is the best method to use.


Having read this article you should now be familiar with the basic building blocks that go together to make up the Prestashop shopping cart. In the next part of this tutorial we will look at coding our first module using these concepts and begin extending Prestashop.

Difference between the iPhone 3G and iPhone 3GS Glass Digitizer Touch Screen and LCD

If you’ve broken your iPhone 3G or 3GS and contemplating on one the following scenarios think again:

“Why can’t I replace my broken iPhone 3G Digitizer and/or iPhone 3G LCD with a newer iPhone 3GS Digitizer and/or iPhone 3GS LCD, it has to be better, right?”


“Why can’t I replace my broken iPhone 3GS Digitizer and/or iPhone 3G LCD with an older and cheaper iPhone 3G Digitizer and/or iPhone 3GS LCD?”

The answer to all these is simple. Apple slightly changed the connectors on the mainboard of the iPhone 3GS.

difference between iphone 3g and iphone 3gs digitizer and LCD connections

iPhone Apps: Tips and Tricks to Building the next killer app

What are the elements to building a successful app on the iPhone? The talk will describe multiple paths to both building and marketing an iPhone app and describe pros and cons of each approach. We will use our own app as a case study of both what to do, and what not to do, with the hope that our experience with the iPhone will save time and energy of others who are considering building their own application, whether it be for the consumer market, enterprise, or internal use.

iPhone Apps: Tips and Tricks to Building the next killer app from Lee Waterman on Vimeo.

Beginning iPhone Development

Beginning iPhone Development is a pretty good book for those wanting to get into iPhone development. The book does a good job of explaining all the details of all you’ll be learning and exploring in the book. The first few chapters take you through the basics, and each chapter builds up to the next. I definitely recommend it for those new to the iPhone SDK.

DIY iPhone 3G Glass Repair

If you have dropped your iPhone 3G or iPhone 3GS and have broken the glass or severely scratched the screen then this Video is for you. This is a complete tutorial on to replace the glass and digitizer on your iPhone 3G or iPhone 3GS. Replacement parts can be purchased here @ http://iphoneshopusa.com




How To Fix Replace Repair iPhone 3G / 3GS Broken Glass DIY from Lee Waterman on Vimeo.


Watch my how-to video, How to replace the glass & digitizer on your iPhone 3G on WonderHowTo.

Don’t Make Squirrel Burgers

Your manager comes to you and says “Hey, Joe.  Let’s talk.  I need to get a new system developed to keep track of our help desk calls.  It needs to have a slick user-interface that is easy to navigate, it needs to be fast, and also we need integration with SAP.”  You ponder what the system architecture might be like.  He continues.  “So how long do you think this will take?”

Of course, your first instinct is to tell your manager that you’ll get back to him later with a rough estimate, but he is in a hurry and persistent.  You cave in and tell him, “I think it would take 6 weeks.”

“Hrm, 6 weeks?  I really need it in 5 weeks, no later.”

Your manager is already negotiating your rough estimate.  Be afraid.  You start to figure out how you can accomplish all of this in 5 weeks and you are realizing that you really needed eight weeks, not six.  Let me put this story on pause while I tell you another story…

Bob is the new night manager at FatBurger.  One night a man walks in and requests a double Fat-burger with cheese, a large order of Fat Fries, and a chocolate shake.  He pulls out the change in his pocket and Bob finds out that he only has $1.20.  The entire meal costs $7.50.

What would you do in this situation?  Turn away your only customer in the 11:00pm hour?  Offer something that he can afford?  Give it to him for $1.20 this time only?

Bob, being a proud night manager, wants to satisfy his customer.  He cannot give away the food cheaply because then the guy will return again, expecting another discount.  So Bob decides to get creative.  He goes around back and finds a dead squirrel on the pavement.  He scrapes it up with a shovel and brings it inside, grills it up and gives it to the man.

In this story, Bob sacrified quality to give the gentleman what he wanted for only $1.20.

Stop me if this scenario sounds familiar.

Back at your desk, you are realizing that you are about to deliver to your manager a squirrel-burger.  He wants X features, but you can’t deliver them on time.  The first thing you are going to throw out are automated tests.  Then you’ll stop refactoring.  Pretty soon you are just heads-down coding like you did in high school and you are making a huge mess.

Two things are likely to happen.  The system will buckle under its own weight because the code reaks of dead squirrels.  The other thing that is likely to happen is that your system becomes useful, and now management has another request.

“Hey Joe.  The new system rocks!  I just got off the phone with marketing and they want to start selling this to our larger clients.”

Now you’re in a pickle.  You have a spaghetti-mess of a system and now you need to extend it and polish it for redistribution. 

This sad state of affairs is all too common.  Your manager might want a double Fat burger with cheese in 5–weeks, but what he’s getting is a squirrel burger.  Don’t deliver squirrel burgers.  Be careful with off-the-cuff estimates that end up turning into negotiations.  Joe should have negotiated features instead of quality to meet his 5–week deadline.  Estimates should include time for automated tests and refactoring because it is part of your daily coding activity and it helps maintain quality.

I first heard the term “squirrel burgers” and the above story from Mark Pushinsky.