Writing your own PrestaShop Module

Introduction 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 1.2.0.6) 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 thirdparty 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 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.

Source: www.ecartservice.net/tag/development/

Summary Having read this article you should now be familiar with the basic building blocks that go together to make up the Prestashop shopping cart. and is sufficient to produce a working shopping cart.Views The presentation of data from our shopping cart application is handled by the smarty template engine. apply business logic to the data and then output the results via one or more “Views”. which can be exploited by user-installable “plugins” (which Prestashop refer to as “modules”). but even they too hook into the standard controllers in order to provide alternative code execution paths. Thankfully the module architecture in Prestashop provides us with a fairly simple way of adding an administrative interface to modules. it is a little inflexible in terms of adding new functionality. In a strict MVC environment there should be no processing of data by the view. Source: www. Administration panel extensions.net/tag/development/ . Payment modules are a specific class of module. In order to create a shopping cart system that is both easily extensible and maintainable by a non-technical store owner.ecartservice. Using a view allows us to separate out the business logic from the presentation. additional functionality is inserted — “hooked” — into the above architecture by means of specially inserted “hook” points in the controller code. and correspond to the main “pages” that make up the web store. operate in an entirely different way and the process is much more akin to adding additional controllers. you would have to modify the controller page directly to implement your change. In this case. In Prestashop these are contained in the root directory of the store installation. 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. and in all but the most complex of cases this is the best method to use. these modules have the ability to output additional or modified content. If. you wanted to modify the home page of your store with only the above architecture. In the next part of this tutorial we will look at coding our first module using these concepts and begin extending Prestashop. So where do modules fit in? While the above describes the core functionality of Prestashop. with the specific set of template files to be used being selectable from the Administration interface. The view files for Prestashop are in general stored in the /themes folder. only the display of data passed to it from a controller — and in the majority of cases this is true for Prestashop. They are responsible for interacting with the “Models” to retrieve data. although some Ajax/javascipt is employed by default to perform additional data processing. for example. Controller The controller is the main business logic for a “page” or collection of related pages to be displayed. so must be discussed separately. add new functionality (business logic) to the controllers and gather information. OK. Many modules also store their own specific template files within their own directory structure.

10 $this->version = '0.Creating a basic module Introduction 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. 08 09 $this->tab = 'eCartService. The Module class Similar to the ObjectModel base class.1. Coding conventions Before we can write our first code there is one more element that needs to be considered — that of module class. 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. 07 parent::__construct(). Although the above code doesn’t look like very much. In addition the module directory and class source file must be named in lower case. but it is essential that the folder it resides in and the source file follow this convention.net/tag/development/ . modules must be located within the /modules directory below your base store installation directory.it does absolutely nothing at all.net Tutorials'.ecartservice. We then need to create the main module class file within this directory and insert the following code: 01 <?php 02 class TutorialFirst extends Module 03 { 04 function __construct() 05 { 06 $this->name = 'tutorialfirst'. it is actually packed with functionality thanks to the base class it extends.').php” in our module directory and upload to our server. directory and file naming. with the same name as the module class we choose. 13 } 14 } 15 // End of: tutorialfirst. Note that the module class name itself does not have to be lowercase (by convention class names use “Camel case”).php We save this file as “tutorialfirst. 12 $this->description = $this->l('Our very first module . 11 $this->displayName = $this->l('First Tutorial Module'). The “Module” class provides the interface between the administration screens and your module as well as providing internationalisation and “hook” management functionality. all Prestashop modules are extended from a common base class used to define their basic functionality. Source: www. The first step is to create our directory on the server and name it “tutorialfirst”.0'. In Prestashop.

and in the case of these examples I’ve chosen to group them under the heading “eCartservice. Let’s look at what we’re doing in this code. ‘Tools’.net Tutorials'. 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. 1 $this->name = 'tutorialfirst'.) however it is entirely up to you how you wish to use this property.Once you’ve uploaded to your development site you will be able the see the module listed under the group heading “eCartService.'). Next we define the properties that will be used when displaying our module in the Back Office. Summary 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. 2 parent::__construct(). and enables the store owner to provide translations. ‘Products’. 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.net Tutorials”. and are fairly self-explanatory. The l() (base class) member function implements language support. and why. In the next part of this tutorial we will look at extending our first module to allow configuration. The $this->version member variable allows us to display the current module version in the modules list. and again is the class name in lower case. Source: www.net Tutorials” and you can now install and uninstall it.g. This may also be useful in allowing us to identify old and outdated module versions later. The final two member variables are used to display information regarding our module in the modules list. 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. which will allow users to identify visually which version of our module they are using. rather than just being assigned as the static strings directly. and based on this configuration display output in a specified area of a page. The English language version of the text we wish to display is passed to this function. 4 $this->description = $this->l('Our very first module . Note however that these are being set using the $this->l() Module class function however. 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. In general we would choose one the the standard categories (e.it does absolutely nothing at all.net/tag/development/ .ecartservice. ‘Blocks’ etc. 1 $this->tab = 'eCartService. using an external module distribution site. 3 $this->displayName = $this->l('First Tutorial Module'). 2 $this->version = '0.1. 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. ‘Advertisement’. The $this->tab member variable defines how we wish our module to be classified by the Back Office in the modules list.0'.

1.net Tutorials'. 10 11 $this->tab = 'eCartService. 09 parent::__construct().php” respectively. 12 $this->version = '0. The class file (tutorialsecond. 14 $this->description = $this->l('Our second module . 05 06 function __construct() 07 { 08 $this->name = 'tutorialsecond'.A "Hello world" redux').0'.Storing Module Configuration Introduction In the third part of this series we’ll look at how we can store configuration data for our modules in the Prestashop database. and how we can allow users to interact with this data to control the module’s behaviour. 13 $this->displayName = $this->l('Second Tutorial Module').php) should contain the following: 01 <?php 02 class Tutorialsecond extends Module 03 { 04 private $_html = ''.ecartservice.net/tag/development/ . Managing user settings We’re going to call this module “TutorialSecond” so we again need to create a new module directory and class file — which will be named “tutorialsecond” and “tutorialsecond.php Source: www. We will also briefly touch on how we can generate output from our module to provide visual feedback of the configuration changes. 15 } 16 17 public function getContent() 18 { 19 20 } 21 22 private function _displayForm() 23 { 24 25 } 26 27 } 28 // End of: tutorialsecond.

2 Configuration::get($key. but the two key functions that will be most commonly used are: 1 Configuration::updateValue($key.= ' 04 <form action="'. The Configuration::updateValue() function allows us to store a configuration option in the database (optionally in multiple languages in which case the $values parameter will be an array) and the Configuration::get() function allows us to retrieve configuration data for a selected or store default language. We’ll create a simple form within this function from with which we can capture store owner input. Source: www.net/tag/development/ . If you upload the file to your server and install this module at this stage you should see a new option on the modules list screen for ‘Second Tutorial Module’.'</label> 06 <div class="margin-form"> 07 <input type="text" name="our_message" /> 08 </div> 09 <input type="submit" name="submit" value="'. $html = false). however it is highly recommended that you separate this out for the sake of easier code maintenance. with the form target being $_SERVER['REQUEST_URI'].'" method="post"> 05 <label>'. $id_lang = NULL). The presence of the ::getContent() member function is responsible for this as it provides the interface between our module and the Back Office. In addition to these two new functions we have also added the $_html private member variable. There will now be a “>> Configure” link in the module entry.$_SERVER['REQUEST_URI']. which we will use later in this article to build the required output for display in the Back Office. Prestashop’s Back Office architecture will route this to our ::getContent class member function for us to handle when the form is posted. although clicking it will merely return an empty Back Office page. Implementing the Configure Screen In our source file we created a private member function _displayForm().You will notice that we have implemented two new member functions ::getContent() and ::_displayForm().'" class="button" /> 10 </form>'. This is entirely optional as all of the interface code could be placed in the getContent() member function. 11 } You can see that the ::_displayForm() function simply appends standard html form code to our $_html member variable.ecartservice. We next need to add code to our ::getContent() function to actually display the form and handle the form submission.$this->l('Message to the world'). $values. 01 private function _displayForm() 02 { 03 $this->_html .$this->l('Update'). Storing and Retrieving Configuration Data Prestashop provides a “Configuration” class which offers several member functions to manipulate configuration data. but will revisit the $html parameter in the Configuration::updateValue() function in the next article when we look at the subject of form validation. We will ignore the parameters that have default values for now.

09 10 return $this->_html.net/tag/development/ . ready for more input if required. or whether this function is being called in another way i. to the Back Office for display.ecartservice. 11 } The ::getContent() function first uses another Prestashop class “Tools” to test whether we are handling the post action from the form. If the function is being called as a result of our form being posted. Module Output on a Page We now have a method of capturing input from the store owner and saving it in the database.e. In part 1 of the series we talked about “hooks” in relation to modules adding functionality.'_message'. You can see that I have added the name of our module to the beginning of the configuration item name — this is to ensure that the configuration key is unique as the namespace for these keys is shared for the entire store. Tools::getValue('our_message')). The $hook_name parameter refers to one of the different points that the Prestashop core allows modules to insert output and/or data processing. a click on the “Configure” link in the module list — the parameter is the name we gave to our “update” button in the form. which allows us to add content in the left column of all pages. but for now we will use one in particular — “leftColumn’. so the next obvious step would be to do something with it e. If the function is being called directly by the Back Office (in which case Tools::isSubmit(’submit’) will return false). 06 } 07 08 $this->_displayForm(). Source: www. In order to initialise the hook we need to add the following new override in our own class: 1 public function install() 2{ 3 parent::install().g. In order to utilise this we need to tell PrestaShop that our module would like to hook into the Front office and we do this using the following function (defined in the Module base class): 1 $this->registerHook($hook_name). then we can store our configuration parameter in the database with the value entered on our form. Once we have stored our configuration data the form is again displayed. We again use the Tools class to obtain the value of the form variable using the call to Tools::getValue(‘our_message’) where ‘our_message’ is the name of the input field in our form. then we call the form rendering function we created above and return the output. captured in the $this->_html variable.01 public function getContent() 02 { 03 if (Tools::isSubmit('submit')) 04 { 05 Configuration::updateValue($this->name. display it on a page.

09 parent::__construct().1.0'.g. 20 21 if (!$this->registerHook('leftColumn')) 22 return false. ‘Hello World’. 13 $this->displayName = $this->l('Second Tutorial Module').net/tag/development/ . Source: www.'_message') . 4} In our simple example we are just wrapping our configuration parameter in some standard html markup so that it is displayed correctly on our page.4 5 if (!$this->registerHook('leftColumn')) 6 return false. The convention is to name the function as the Hook name preceded by “hook”: 1 public function hookLeftColumn() 2{ 3 return '<div class="block"><h4>'. '</h4></div>'. 05 06 function __construct() 07 { 08 $this->name = 'tutorialsecond'. Now you can enter a value in the configuration screen for the module — e. We next need to add a function to handle the hook callback. 10 11 $this->tab = 'eCartService.A "Hello world" redux').ecartservice. and it will be output as the heading of a box in the left column of your store. 7} This tells Prestashop to execute our module hook when it is rendering the content for the left column of all pages. 15 } 16 17 public function install() 18 { 19 parent::install(). 12 $this->version = '0. Configuration::get($this->name. 14 $this->description = $this->l('Our second module . The full code for the second example should now look like: 01 <?php 02 class Tutorialsecond extends Module 03 { 04 private $_html = ''. If you have already installed the module you should now uninstall then reinstall to ensure that the hook is correctly registered with the Prestashop core.net Tutorials'.

pre-populating the form fields as appropriate based on the current configuration and displaying module errors and warnings in the Back Office screens.'" method="post"> 41 <label>'.$this->l('Message to the world').'_message') . 47 } 48 49 public function hookLeftColumn() 50 { 51 return '<div class="block"><h4>'. '</h4></div>'. Tools::getValue('our_message')).$_SERVER['REQUEST_URI'].php Summary In this article we have extended our first module to include a basic configuration form and have used a hook function to display output from our module in the left column of our pages. In the next part of this series we will look at improving the configuration facility into something that could be used in a real module implementation. 52 } 53 54 } 55 // End of: tutorialsecond.23 } 24 25 public function getContent() 26 { 27 if (Tools::isSubmit('submit')) 28 { 29 Configuration::updateValue($this->name.'" class="button" /> 46 </form>'. 33 34 return $this->_html.'_message'.ecartservice. 35 } 36 37 private function _displayForm() 38 { 39 $this->_html .$this->l('Update').= ' 40 <form action="'.'</label> 42 <div class="margin-form"> 43 <input type="text" name="our_message" /> 44 </div> 45 <input type="submit" name="submit" value="'. This will include validating user input to the form. Source: www. Configuration::get($this->name. 30 } 31 32 $this->_displayForm().net/tag/development/ .

We could modify the TutorialSecond module to allow input of html in the form. 01 isEmail($email). 02 isFloat($float). 05 isDate($date).net/tag/development/ .Form Validation and Security Introduction While being sufficiently functional for what it does. In Part 3 we ignored the $html parameter and allowed the function to use the default value of “false”.'_message'. true)). If you recall the function has the following form: 1 updateValue($key. but it’s worth reproducing some of them here to illustrate the point — for a complete list you should consult the classes/Validate. In particular the user input we captured with our form was written directly to the configuration entry without any checking to determine whether it was valid. Tools::getValue('our_message'. The Configuration class revisited In Part 3 we touched briefly on an additional parameter that may be passed to the Configuration::updateValue() class method. You should see that any html tags in your input are removed. 04 isCleanHtml($html). 06 isBool($bool). 07 isPhoneNumber($phoneNumber). by changing line 29 in the source file to: 1 Configuration::updateValue($this->name.ecartservice. the module we created in Part 2 does present us with some issues to consider when implementing “real world” modules to extend Prestashop. $values. When set to “false” the updateValue() method actually pre-processes the value to be written using the following code ($string is the input value passed to the function): 1 $string = strip_tags(nl2br2($string)). This illustrates the fundamental principle that we need to employ throughout our own code to ensure that it is secure and operates predictably. The list of member functions is rather large. In this tutorial we will look at the general issue of form input checking and security. $html = false). Thankfully Prestashop provides us with some tools that we can use in our own code to make it more secure and robust. nor did we take account of the type of data being entered. You can test this out by entering some HTML into the configuration screen for the module we created in Part 3. In doing this we actually inadvertently added the first element of security and validation to our code. Validation Prestashop provides us with a class called Validate that we can use to determine whether any user input we accept is valid or not.php file in your Prestashop distribution. Source: www. both for Back Office and Front Office forms and user input as well as looking at improving our code both functionally and aesthetically. 03 isUnsignedFloat($float).

1.08 isPostCode($postcode). 14 $this->description = $this->l('Our third module . 20 21 if (!$this->registerHook('leftColumn')) 22 return false. 12 isNullOrUnsignedId($id).Security and Validation'). 12 $this->version = '0. 09 parent::__construct(). then just expand and copy the code below as appropriate! 01 <?php 02 class Tutorialthird extends Module 03 { 04 private $_html = ''. 10 11 $this->tab = 'eCartService.ecartservice. Why not try modifying the Tutorialsecond class yourself to create the Tutorialthird module? If you’d rather not. 14 isAbsoluteUrl($url). 10 isUnsignedInt($int). 15 isFileName($name). 15 } 16 17 public function install() 18 { 19 parent::install(). As an example we can use the isCleanHtml() function from the list above as a test in our module to prevent XSS (cross site scripting) — that way we can allow html input reasonable safely.net Tutorials'.0'. Validating our form data As before we’re going to create a new module based on the previous version. 13 $this->displayName = $this->l('Third Tutorial Module'). 09 isInt($int).net/tag/development/ . 13 isUrl($url). 11 isUnsignedId($id). 05 06 function __construct() 07 { 08 $this->name = 'tutorialthird'. 23 } 24 25 public function getContent() 26 { 27 if (Tools::isSubmit('submit')) Source: www.

'_message'. true). 10 $this->_html .ecartservice. 06 07 if (!sizeof($this->_postErrors)) 08 { 09 Configuration::updateValue($this->name.'_message'.$_SERVER['REQUEST_URI']. 52 } 53 54 } 55 // End of: tutorialthird. 30 } 31 32 $this->_displayForm(). 47 } 48 49 public function hookLeftColumn() 50 { 51 return '<div class="block"><h4>'. Tools::getValue('our_message')).= '<div class="conf confirm">'. Configuration::get($this->name.php The first stage in the process is to modify our getContent() function to add the validation step: 01 public function getContent() 02 { 03 if (Tools::isSubmit('submit')) 04 { 05 $this->_postValidation().$this->l('Settings updated').'" method="post"> 41 <label>'. 33 34 return $this->_html. '</h4></div>'.$this->l('Update').$this->l('Message to the world').'_message') .28 { 29 Configuration::updateValue($this->name.'" class="button" /> 46 </form>'.= ' 40 <form action="'. 11 } Source: www. 35 } 36 37 private function _displayForm() 38 { 39 $this->_html .'</div>'.net/tag/development/ .'</label> 42 <div class="margin-form"> 43 <input type="text" name="our_message" /> 44 </div> 45 <input type="submit" name="submit" value="'. Tools::getValue('our_message').

We’ll also look at ideas for improving and extending the “template” module we’ve created.g. The logic flow when we post data to getContent() is now to call our _Validation() function to test the fields submitted and to set our $_postErrors array with any error messages. then we display a “success” message to give visual feedback that the configuration has been updated.'</div>'. 4 private $_postErrors = array().net/tag/development/ . 24 } We also need to add a declaration for the $_postErrors member variable we’ve introduced at the beginning of our class definition e. 1 class Tutorialthird extends Module 2{ 3 private $_html = ''.$err. If there are errors we can display them prior to redisplaying the form. Summary In this article we’ve improved on our form handling by adding validation of user input for added security and/or reliability. 5} Obviously you aren’t limited to using the tests supplied by the Validate class. In the final part of this series we’ll add some final cosmetic touches to our form to standardise the interface and improve usability. 22 23 return $this->_html. A simple XSS test in the _Validation() function for our example could be: 1 private function _postValidation() 2{ 3 if (!Validate::isCleanHtml(Tools::getValue('our_message'))) 4 $this->_postErrors[] = $this->l('The message you entered was not allowed. The basic principle is the same in all cases. and you can also apply multiple tests to each field submitted — to test for length etc. sorry'). We’ve also added some visual feedback when the configuration has been updated successfully.12 else 13 { 14 foreach ($this->_postErrors AS $err) 15 { 16 $this->_html .ecartservice.= '<div class="alert error">'. Source: www. If the validation checks are passed. 17 } 18 } 19 } 20 21 $this->_displayForm(). no matter how complex your validation requirements are.

however this is an important element since we want to provide a consistent interface for our users.= ' 04 <form action="'.'" class="button" /> 12 </fieldset> 13 </form>'.ecartservice.$_SERVER['REQUEST_URI'].'" class="button" /> 10 </form>'. but I’ve added a download link at the end of this part so you can grab the final code and use it as the basis for your own projects.'</legend> 07 <label>'./img/admin/cog.$_SERVER['REQUEST_URI']. and we’ll also need to add a nice friendly (translatable) legend complete with icon.$this->l('Update')..'" method="post"> 05 <label>'. Styling the configuration form The first changes we’re going to make are purely cosmetic. 14 } Source: www.= ' 04 <form action="'.gif" alt=""class="middle" />'.$this->l('Message to the world'). We’re going to call this module “Skeleton” – a name that we’ll replace with our own when it comes to producing new modules based on it.'</label> 08 <div class="margin-form"> 09 <input type="text" name="our_message" /> 10 </div> 11 <input type="submit" name="submit" value="'. Rather than republish the same old code again we’ll only discuss the changes.'</label> 06 <div class="margin-form"> 07 <input type="text" name="our_message" /> 08 </div> 09 <input type="submit" name="submit" value="'.$this->l('Update'). Our form code looked like: 01 private function _displayForm() 02 { 03 $this->_html .'" method="post"> 05 <fieldset> 06 <legend><img src=". 11 } The convention for these configuration screens is to wrap the settings in a fieldset.$this->l('Settings'). Our code will now look like: private function _displayForm() 01 02 { 03 $this->_html .The finishing touches Introduction In this final part of our basic module writing tutorial series we’ll look at the final steps to transform our Tutorialthird module class into a base template that we can use to kick start the writing of new modules.$this->l('Message to the world').net/tag/development/ .

'</div>'.= '<div class="conf confirm">'. 6} Source: www.= '<h2>'.'</h2>'. 4 $this->_html . Tools::getValue('our_message').'_message')).$this->displayName. 4 5 $this->_html . and even when the form returns from updating the values the fields are blank. There are two possibilities that we need to handle: 1.net/tag/development/ . 2. Configuration::get($this->name. Initial display of the form should display the current configuration (if any) After a form update we should display the data entered by the user We can use the Configuration::get() function to retrieve the current settings from the database.'"/> Another useful change to make when dealing with several fields in a configuration for is to move the database update code to it’s own private function.'_message'.Tools::getValue('our_message'.'_message'. For this we will replace the line: 1 if (!sizeof($this->_postErrors)) 2 { 3 Configuration::updateValue($this->name. easily identified location: 1 private function _postProcess() 2{ 3 Configuration::updateValue($this->name. The Tools::getValue() function takes a second parameter which is useful in this context. 1 Pre-populating configuration form fields Another missing element from our original tutorial design was the display of the current settings in the module configuration form.ecartservice. We can now set the “value” attribute of our input tag appropriately using these two functions.$this->l('Settings updated').Our final cosmetic change is to add a heading at the top of our settings screen just in case the user has forgotten where they are! We do this by adding the following line at the start of the getContent() function: $this->_html . so our final form input code will be: 1 <input type="text" name="our_message"value="'. 5 } with the following: 1 2 if (!sizeof($this->_postErrors)) $this->_postProcess().= '<div class="conf confirm">'.$this->l('Settings updated'). as this specifies a “default” to use should the field be empty. true).'</div>'. And we add the new private member function to our class to handle the actual updates in a single. and Tools::getValue() to get the field contents. Tools::getValue('our_message'). true). so we need to fix this glitch too.

textarea and drop-down lists. 19 } Source: www. In the simplest form we will just use the same output in all locations. To produce the same output in all the popular locations. Adding multiple display location hooks Our Tutorialthird module could only display our content in the left column since this was the only hook we implemented. by setting appropriate defaults using the Configuration::updateValue() function.g. radio buttons. Luckily it’s very easy to implement the “Transplant a module” BackOffice functionality in our code. 01 function hookRightColumn($params) 02 { 03 return $this->hookLeftColumn($params). 04 } 05 06 function hookTop($params) 07 { 08 return $this->hookLeftColumn($params). add any validation required to the _postValidation() function and modify the update code in the _postProcess() function appropriately. For mandatory settings you should also test for their presence in the install function and take appropriate action to prevent your module causing errors in the Front Office e. Note that we only actually call registerHook() for the default one in the install() member function. although it is more correct to perform this within install(). Alternatively this can be performed in the module constructor.ecartservice.Handling other field types In the final download of the skeleton module I’ve also added examples of other types of fields that will act as useful shortcuts to creating your module configuration form. 09 } 10 11 function hookHome($params) 12 { 13 return $this->hookLeftColumn($params). and let the Back Office handle the registration of the others. All you need to do is add/rename the fields. This covers checkboxes. but if required all of these additional hooks can produce different results.net/tag/development/ . we merely need to implement the additional hook functions in our module and call the original hook code to generate the output. 14 } 15 16 function hookFooter($params) 17 { 18 return $this->hookLeftColumn($params).

net/tag/development/ . and for performance reasons it is best to avoid its use if at all possible. You may have noticed that at no time have we actually used smarty or its template files in the creation of our module — this is deliberate as they can be seen as a separate entity from the module design itself. Later articles will explore how and when to use smarty to enhance your modules functionality though. Smarty is highly flexible.Summary Over this series of articles you should have learned how the basic module system works in Prestashop and be able to code modules that deliver output to the different presentation areas in the Front Office. You’ll also have a good code framework to base your own modules on. but the choice to use it is based on many factors. Source: www.ecartservice. as it is a fundamental part of the Prestashop architecture.