Child pages
  • New Developers Features In PrestaShop 1.5

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

 

Table of content

Table of Contents
maxLevel3

...

New Developers Features In PrestaShop 1.5

...

There are six main aspects of PrestaShop's Module API which received a significant overhaul for version 1.5: dynamic hooks, evolution of the override system, new file-tree and operations, multishop multistore feature, Addons webservice, and the update system. We will explore these one by one.

...

  • "Action" hooks. For example, to send out a mail when a client creates a user account.
  • "ViewDisplay" hooks. For example, to display a module in a column.

New hooks

...

Read the dedicated page: Hooks in PrestaShop 1.5.

Dynamic hooks

PrestaShop brings the ability of defining dynamic hooks. In effect, there is now a hook before and after each action of each controller: PrestaShop's ObjectModel and AdminController base objects have been updated so that this new feature is automatically applied to existing code. They make it possible for your code to hook to any object or back-office action.

Code Block

public function add($autodate = true, $null_values = false)
{
	// @hook actionObject*AddBefore
	Hook::exec('actionObjectAddBefore', array('object' => $this));
	Hook::exec('actionObject'.get_class($this).'AddBefore', array('object' => $this));
}

...

  • actionObjectAddBefore
  • actionObjectObjectNameAddBefore
  • actionObjectAddAfter
  • actionObjectObjectNameAddAfter
  • actionObjectUpdateBefore
  • actionObjectObjectNameUpdateBefore
  • actionObjectUpdateAfter
  • actionObjectObjectNameUpdateAfter
  • actionObjectDeleteBeforeactionObjectObjectNameDeleteBefore
  • actionObjectObjectNameDeleteBefore
  • actionObjectDeleteAfter
  • actionObjectObjectNameDeleteAfter

There are more dynamic hooks in AdminControllers, and new ones will be added in the future.

Here is the list of available dynamic hooks:

  • actionAdminActionNameBefore
  • actionControllerNameActionNameBefore
  • actionAdminActionNameAfter
  • actionControllerNameActionNameAfter
  • actionAdminControllerSetMedia

Override

PrestaShop's override system, which was introduced with PrestaShop 1.4, makes it easier for third party developers to include changes to the core methods without changing the core files.

...

The advantages are numerous, the major ones being:

  • easier Easier to manage, install, and share along with the module itself.
  • multiple Multiple modules can make changes to the core classes, as long as they do not attempt to override the same functions.

...

This is achieved by using FrontController classes in your module. In the example of the Cheque module, the following file has been place in the module's file-tree:
/modules/cheque/controllers/front/payment.php

...

Here is an example:

Code Block

class ChequePaymentModuleFrontController extends ModuleFrontController
{
  public $display_column_left = false;
  public $ssl = true;

  /**
  * @see FrontController::initContent()
  */
  public function initContent()
  {
    parent::initContent();

    $cart = $this->context->cart;
    if (!$this->module->checkCurrency($cart))
      Tools::redirect('index.php?controller=order');

    $this->context->smarty->assign(array(
      'nbProducts'    => $cart->nbProducts(),
      'cust_currency' => $cart->id_currency,
      'currencies'    => $this->module->getCurrency((int)$cart->id_currency),
      'total'         => $cart->getOrderTotal(true, Cart::BOTH),
      'isoCode'       => $this->context->language->iso_code,
      'chequeName'    => $this->module->chequeName,
      'chequeAddress' => Tools::nl2br($this->module->address),
      'this_path'     => $this->module->getPathUri(),
      'this_path_ssl' => Tools::getShopDomainSsl(true, true).__PS_BASE_URI__.'modules/'.$this->module->name.'/'
    ));

    $this->setTemplate('payment_execution.tpl');
  }
}

...

  • /config.xml: Automatically created by PrestaShop when the module is loaded.
  • /mymodule.php
  • /mymodulelogo.jpg: Logo file, 16*16 pixels. For versions of PrestaShop up to v1.4.
  • /mymodulelogo.png: Logo file, 32*32 pixels. For PrestaShop 1.5 and later.
  • /controllers/
  • /controllers/front/myfile.php: As explained above.
  • /translations/
  • /translations/fr.php: French language file, created automatically when you start translating the module in your back-office.
  • /translations/de.php: Deutsh German (deutsch) language file, created automatically when you start translating the module in your back-office.
  • /translations/...: ...and so on...
  • /views/
  • /views/css/: For CSS files.
  • /views/js/: For JavaScript files.
  • /views/templates/admin
  • /views/templates/admin/folder_name: For template files used by the module's admin controllers. (e.g. "sample_data" for the "SampleData" admin controller)
  • /views/templates/front/: For template files used by the module's controllers.
  • /views/templates/hooks/: For template files directly used by the module. For backward compatibility purposes, this type of files can also be placed in the root folder of the module.

...

Multistore Feature

One of the major features of version 1.5 is the multishop multistore feature, which enable shop owners to manage more than one shop with a single installation of PrestaShop. However, this has deep implications in the code of PrestaShop, and while all modules written for v1.4 should work as-is with v1.5, most will not work as expected in the multishop multistore context.

If your 1.4 module only stores its data using Configuration::get and Configuration::updateValue, it should have no problem working with multiple shops.
On the other hands, if the module stores its data within its own database tables, you will have to update these tables: add a id_shop row in the table where you will store the shop's ID when saving data.

...

For instance, the install-1.8.0.php file should be built like so:

Code Block

<?php
// Sample file for module update

if (!defined('_PS_VERSION_'))
  exit;

// object module ($this) available
function upgrade_module_1_8_0($object)
{
  // yourYour update code to upgrade from previous version 1.8.0 of the module
}
?>

When updating, PrestaShop will call all your update files one after the other, from the current version to the latest version. For instance, let's say the module's /upgrade folder contains the following files:

  • install-1.8.0.php
  • install-1.8.1.php
  • install-1.8.2.php
  • install-1.8.3.php

If you are updating from v1version 1.8.1 to v1version 1.8.3 of the module, PrestaShop will only load the two last files, install-1.8.2.php and install-1.8.3.php.

Theme API

Info

Coming soon...

See Changes in version 1.5 which impact theme development