Child pages
  • Creating a first module

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Some PSR fixes in code examples

...

File/folder nameDescriptionDetails
name_of_the_module.phpMain file.

The main PHP file should have the same name as the module's root folder.
For instance, for the BlockCMS module:

  • Folder name: /modules/blockcms
  • Main file name: /modules/blockcms/blockcms.php
config.xmlCache configuration file.If it does not exist yet, this file is automatically generated by PrestaShop when the module is first installed.

logo.gif or logo.jpg (up to v1.4)
logo.png (v1.5+)

Icon files representing this module in the back - office.PrestaShop 1.4: 16*16 pixels Gif or Jpeg file.
PrestaShop 1.5: 32*32 pixels PNG file.
If your module works on both PrestaShop 1.4 and PrestaShop 1.5+, you should have both a logo.gif AND a logo.png file.
/viewsThis folder contains the View files. 
/views/templatesThis folder contains your module's template files (.tpl). If the module needs to work with PrestaShop 1.4, the template files should be placed either directly at at the root of the module's folder, or in a /template folder at the root of the module's folder.
/views/templates/adminSub-folder for template files used by the module's administration controllers. 
/views/templates/frontSub-folder for template files used by the module's front - office controllers. 
/views/templates/hookSub-folder for template files used by the module's hooks. 
/views/cssSub-folder for CSS files used.If the module needs to work with PrestaShop 1.4, the CSS files should be placed in a /css folder at the root of the module's folder.
/views/jsSub-folder for JavaScript files.If the module needs to work with PrestaShop 1.4, the JavaScript files should be placed in a /js folder at the root of the module's folder.
/views/imgSub-folder for image files.If the module needs to work with PrestaShop 1.4, the image files should be placed in a /img folder at the root of the module's folder.
/controllersThis folder contains the Controller files.You can use the same sub-folder paths as for the View files.
For instance, /modules/bankwire/controllers/front/payment.php .
/overrideSub-folder for the class-overriding code.This is very useful when you need to change some of the default PrestaShop code. Since you must not do so, you can override the default code.
For instance, /modules/gsitemap/override/classes/Shop.php extends the default ShopCore class.
/translationsSub-folder for the translation files.fr.php, en.php, es.php, etc.
/themes/[theme_name]/modulesSub-folder for overriding .tpl files and languages files, if necessary.This folder is essential during modifications of an existing module, so that you can adapt it without having to touch its original files. Notably, it enables you to handle the module's template files in various ways, depending on the current theme.
/upgradeSub-folder for upgrade filesWhen releasing a new version of the module, the older might need an upgrade of its data or files. This can be done using this folder.

...

Code Block
<?php	
if (!defined('_PS_VERSION_')) {
  exit;
} 

This checks for the existence of an always-existing PrestaShop constant (its version number), and if it does not exist, it stops the module from loading. The sole purpose of this is to prevent malicious visitors to load this file directly.

...

Code Block
titlemymodule.php
borderStylesolid
<?php
if (!defined('_PS_VERSION_')) {
  exit;
}

class MyModule extends Module
{
}

...

Code Block
titlemymodule.php
borderStylesolid
<?php
if (!defined('_PS_VERSION_')) {
  exit;
}

class MyModule extends Module
{
  public function __construct()
  {
    $this->name = 'mymodule';
    $this->tab = 'front_office_features';
    $this->version = '1.0.0';
    $this->author = 'Firstname Lastname';
    $this->need_instance = 0;
    $this->ps_versions_compliancy = array('min' => '1.6', 'max' => _PS_VERSION_);	
    $this->bootstrap = true;

    parent::__construct();

    $this->displayName = $this->l('My module');
    $this->description = $this->l('Description of my module.');

    $this->confirmUninstall = $this->l('Are you sure you want to uninstall?');

    if (!Configuration::get('MYMODULE_NAME'))		 {
      $this->warning = $this->l('No name provided');
    }
  }
}

Let's examine each line from this first version of the MyModule class...

...

Code Block
$this->displayName = $this->l('My module');
$this->description = $this->l('Description of my module.');

$this->confirmUninstall = $this->l('Are you sure you want to uninstall?');

if (!Configuration::get('MYMODULE_NAME'))	 {
    $this->warning = $this->l('No name provided.');  
}

These lines respectively assign:

...

Code Block
public function install()
{
  if (!parent::install()) {
    return false;
  return}

  return true;
}

In this first and extremely simplistic incarnation, this method does the minimum needed: return true returned by the Module class' install() method, which returns either true if the module is correctly installed, or false otherwise. As it is, if we had not created that method, the superclass' method would have been called instead anyway, making the end result identical.
Nevertheless, we must mention this method, because it will be very useful once we have to perform checks and actions during the module's installation process: creating SQL tables, copying files, creation configuration variables, etc.

...

Code Block
public function install()
{
  if (Shop::isFeatureActive()) {
    Shop::setContext(Shop::CONTEXT_ALL);
  }

  if (!parent::install() ||
    !$this->registerHook('leftColumn') ||
    !$this->registerHook('header') ||
    !Configuration::updateValue('MYMODULE_NAME', 'my friend')
  ) {
    return false;
  }
return
  return true;
}

If any of the lines in the testing block fails, the method returns false and the installation does not happen.

...

Code Block
public function uninstall()
{
  if (!parent::uninstall()) {
    return false;
  }
  
  return true;
}

Building on this foundation, we want an uninstall() method that would delete the data added to the database during the installation ( MYMODULE_NAME configuration setting). This method would look like this:

Code Block
public function uninstall()
{
  if (!parent::uninstall() ||
    !Configuration::deleteByName('MYMODULE_NAME')
  ) {
    return false;
  }

  return true;
}

The Configuration object

...

Code Block
if (Shop::isFeatureActive()) {
  Shop::setContext(Shop::CONTEXT_ALL);
}

As said earlier, here we check that the Multistore feature is enabled, and if so, set the current context to all shops on this installation of PrestaShop.

...

To put the finishing touch to this basic module, you should add an icon, which will be displayed next to the module's name in the back - office modules list.
In case your module is made for a prominent service, having that service's logo visible brings trust.
Make sure you do not use a logo already used by one of the native modules, or without authorization from the owner of the logo/service.

...