Child pages
  • Creating a PrestaShop module

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As you would expect, we have to create a template file in order to use the theme's style. Let's create the display.tpl file, which will contain the basic "Welcome to my shop!" line, and call that will be called by display.php, which we will rewrite . That display.php file will be rewritten into a front-end controller in order to properly embed our basic template within the theme's header, footer, columns, etc.

Tip

You should strive to use explicit and recognizable names for your template files, so that you can find them quickly in the back-office – which is a must when using the translation tool.

...

Let's explore display.php, a new our first PrestaShop front-end controller, stored in the /controllers/front folder of the module's main folder:

  • A front-end controller must be a class that extends the ModuleFrontController class.
  • That controller must have one method: initContent(), which calls the parent class' iniContent() method...
  • ...which then calls the setTemplate() method with our display.tpl file.

setTemplate() is the method that will take care of embedding our one-line template into a full-blown page, with proper header, footer and sidebars.

...

Code Block
titlemymodule.tpl
borderStylesolid
{$my_module_message}

As a side note, you should always prefix your variables with the name of your module.

PrestaShop adds its own set of variables. For instance, {$hook_left_column} will be replaced with the content for the left column, meaning the content from all the modules that have been attached to the left column's hook.

...

But having a getContent() public method in the MyModule object does only make the "Configure" link appear; it does not create the configuration page out of nowhere. We are going to explain how to create one, where we will be able to edit the content of the MYMODULE_NAME variable that we stored in the Configuration ps_configuration data table.

...

La méthode getContent()

...

First, here is the complete code for the Tout d'abord, voici le code complet pour notre méthode getContent() method :

Code Block
public function getContent()
{
    $output = null;

    if (Tools::isSubmit('submit'.$this->name))
    {
        $my_module_name = strval(Tools::getValue('MYMODULE_NAME'));
        if (!$my_module_name  || empty($my_module_name) || !Validate::isGenericName($my_module_name))
            $output .= $this->displayError( $this->l('Invalid Configuration value') );
        else
        {
            Configuration::updateValue('MYMODULE_NAME', $my_module_name); 
            $output .= $this->displayConfirmation($this->l('Settings updated'));
        }
    }
    return $output.$this->displayForm();
}

The La méthode getContent()method is the first one to be called when the configuration link page is clickedloaded. Therefore, we use it to first update any value that might have been submitted by the form that the configuration page contains.

Here is a line by line explanation:

  1. ToolsTools::isSubmit() is est une méthode propre à PrestaShopis a PrestaShop-specific method, which checks if the indicated form has been validated.
    In this case, if the configuration form has not yet been validated, the whole if() block is skipped and PrestaShop will only use the last line, which displays the configuration with the current values, as defined in generated by the displayForm() method.
  2. Tools:getValue() is a PrestaShop-specific method, which retrieve the content of the POST or GET value for array in order to get the value of the specified variable.
    In this case, we retrieve the value of the MYMODULE_NAME form variable, turn its value into a text string using the strval() method, and stores it in the $my_module_name PHP variable.
  3. We then check for the existence of actual content in $my_module_name, including the use of Validate::isGenericName().
    The Validate object contains many data validation methods, among which is isGenericName(), a method that helps you keep only strings that are valid PrestaShop names – meaning, a string that does not contain special characters, for short.
  4. If any of these checks fail, the configuration will open with an error message, indicating that the form validation failed.
    The $output variable, which contains the final rendition of the HTML code that makes the configuration page, is created thus begins with an error message, created using PrestaShop's displayError() method. This method returns the correct HTML code for our need, and since that code is first in $output, this means the configuration will open with that message.
  5. If all these checks are successful, this means we can store the value in our database.
    As we saw earlier in this tutorial, the Configuration object has just the method we need: updateValue() will store the new value for MYMODULE_NAME in the configuration data table.
    To that, we add a friendly message to the user, indicating that the value has indeed been saved: we use PrestaShop's displayConfirmation() method to add that message as the first data in the $output variable – and therefore, at the top of the page.
  6. Finally, we use the custom displayForm() method (which we are going to create and explain in the next section) in order to add content to $output (whether the form was submitted or not), and return that content to the page.
    Note that we could have included the code for displayForm() right within getContent(), but chose to separate the two for readability and separation of concerns.

...

While this might look like a huge block of code for a single value to change, this method block actually uses some of PrestaShop's method to make it easier to build forms, most notably the HelperForm object.

...