As a reminder, in Advanced → Performance → Smarty settings → Template compilation (for PrestaShop 8.2), we have three options:

1. Never recompile template files.

2. Recompile templates if the files have been updated.

3. Force compilation.

Out of these three, the second option — recompiling templates when their files have changed — is often recommended. Why? Honestly, no one knows for sure. I’ve heard arguments that when changes are made in the back office, product prices or information might not refresh properly on the storefront. But that’s simply not true. Any modification event, such as editing a product or category, should trigger cache clearing for the relevant modules — for example, the Featured Products module on the homepage.

The purpose of this article is to clearly state that on a production site, there is absolutely no reason to use any option other than “Never recompile template files.” Any other setting will only make your store less efficient. Of course, things are different in a test or development environment.

I’d also add that in some specific situations, monitoring template files for modifications can drastically slow down the front office loading time. I’ve seen this happen while consulting on module implementations from certain companies working with PrestaShop.

Of course, also make sure that caching itself is enabled. There, it’s worth setting the option to “Clear cache every time something has been modified”, because otherwise, changes made in the back office won’t actually be visible to visitors. (Yes, I’m aware that sometimes it makes sense to clear the cache only on demand — especially in high-traffic stores where cache management is handled differently. :-))

Database prefix

In this article, table names are intentionally written as PREFIX_table_name, because the prefix is something you should adapt to your own setup — I trust you’re not using the default ps_, and if you are, I suggest changing it. After copying the SQL query, remember to replace all instances of PREFIX. I also recommend making a backup before running any of the queries below.

Cleaning the PREFIX_guest and PREFIX_cart tables

The PREFIX_guest table stores data about visitors, but over time it also accumulates records that are no longer useful. One way to clean this table is to remove all records that didn’t result in a purchase, customer registration, or cart creation.

The following query will delete abandoned carts older than one month:

DELETE FROM PREFIX_cart
WHERE id_cart NOT IN (SELECT id_cart FROM PREFIX_orders)
AND date_add < NOW() - INTERVAL 1 MONTH;

The PREFIX_connections and PREFIX_connections_source tables

These tables store information about customer visits, provided you’re using the statsdata module and have data collection enabled. If your store relies on Google Analytics, Matomo, or another analytics solution, you likely don’t need the data from these tables.

That said, it’s worth noting that sometimes third-party modules use this data — for example, some Google Tag Manager integration modules rely on these tables to determine the traffic source for conversions. Before changing the configuration of the statsdata module or cleaning these tables, it’s a good idea to check with a specialist to make sure you don’t actually need this data.

If you’re using Google Tag Manager modules that may depend on this information, it’s better to only remove records older than, say, 6 months. Below are two queries that will delete records older than 3 months.

DELETE FROM PREFIX_connections
WHERE date_add < NOW() - INTERVAL 3 MONTH;

DELETE FROM PREFIX_connections_source
WHERE date_add < NOW() - INTERVAL 3 MONTH;

The PREFIX_log and PREFIX_mail tables

These tables store data that may turn out to be important, but you certainly don’t need their entire history. I recommend archiving them from time to time. Here, you have two options: you can either clean out records older than a few months or completely clear them after archiving once in a while.

DELETE FROM PREFIX_log
WHERE date_add < NOW() - INTERVAL 3 MONTH;

DELETE FROM PREFIX_mail
WHERE date_add < NOW() - INTERVAL 3 MONTH;

Optimizing tables after cleaning

After cleaning up individual tables, it’s a good idea to run a command that will optimize them, for example:

OPTIMIZE TABLE PREFIX_connections, PREFIX_connections_source;

What’s next?

There are many modules available on the market that allow you to perform such cleanups in a simpler way. Remember to always run such modules on a store copy first, as they may cause data integrity issues.

One of the free modules that can be useful for cleaning up a PrestaShop database is PrestaClean, available on GitHub.

The queries mentioned in this article are worth running regularly — you might even consider creating a script that runs via a cron job on your server. Of course, these are just a few examples of tables that can be safely cleaned; this doesn’t cover fixing data integrity issues, removing ghost records in some places, outdated discounts, etc. Perhaps one day there will be an opportunity to write about that as well.

classes/PrestaShopBackup.php

The PrestaShopBackup class exists to make it easier to create database backups. It contains all the necessary logic for gathering database tables, generating a backup file name, and saving the backup data into a file. By default, it is used in the Advanced → Database → DB Backup section, but to illustrate a practical use of the PrestaShopBackup class in your own solution, let’s consider a scenario where you need a backup mechanism for specific tables related to product and category languages.
We’ll assume we need these tables because we created a mechanism that generates, for example, SEO-friendly URLs and other product SEO data based on given criteria, but we want to ensure the user always has a backup.

Don’t reinvent the wheel

Instead of building this from scratch, you can extend the PrestaShopBackup class by creating a new class, for example ProductLangTablesBackup.
The method responsible for creating and saving a new backup is PrestaShopBackupCore::add(). By default, it creates a backup of all the data in your store (except for some tables, such as statistics, if backups were configured that way). Obviously, we are not interested in a full backup, so in our code we need to add a condition that simply skips all the tables we don’t care about.

Example

Below you’ll find code I used in one of my projects. It’s based on the class from PrestaShop 1.7.8. If you want to follow this article and build something for your own solution, make sure to use the PrestaShop 8.2 codebase.
In the code, I’ve highlighted the lines that were modified compared to the original file. We changed:

• the file name
• reversed the backup condition — instead of ignoring selected tables, we allow only selected tables

The most important changes are highlighted in the code below.

<?php

class ProductLangTablesBackup extends PrestaShopBackupCore
{
    /**
     * Creates a new backup file.
     *
     * @return bool true on successful backup
     */
    public function add()
    {
        $tablesToBackup = [_DB_PREFIX_ . 'product_lang'];
        // Generate some random number, to make it extra hard to guess backup file names
        $rand = dechex(mt_rand(0, min(0xffffffff, mt_getrandmax())));
        $date = time();
        $backupfile = $this->getRealBackupPath() . $date . '-' . $rand . '-ProductLanguageData.sql';

        // Figure out what compression is available and open the file
        if (function_exists('bzopen')) {
            $backupfile .= '.bz2';
            $fp = @bzopen($backupfile, 'w');
        } elseif (function_exists('gzopen')) {
            $backupfile .= '.gz';
            $fp = @gzopen($backupfile, 'w');
        } else {
            $fp = @fopen($backupfile, 'wb');
        }

        if ($fp === false) {
            echo Context::getContext()->getTranslator()->trans('Unable to create backup file', array(), 'Admin.Advparameters.Notification') . ' "' . addslashes($backupfile) . '"';

            return false;
        }

        $this->id = realpath($backupfile);

        fwrite($fp, '/* Backup for ' . Tools::getHttpHost(false, false) . __PS_BASE_URI__ . "\n *  at " . date($date) . "\n */\n");
        fwrite($fp, "\n" . 'SET NAMES \'utf8\';');
        fwrite($fp, "\n" . 'SET FOREIGN_KEY_CHECKS = 0;');
        fwrite($fp, "\n" . 'SET SESSION sql_mode = \'\';' . "\n\n");

        // Find all tables
        $tables = Db::getInstance()->executeS('SHOW TABLES');
        $found = 0;
        foreach ($tables as $table) {
            $table = current($table);

            // Skip tables which do not start with _DB_PREFIX_
            if (strlen($table) < strlen(_DB_PREFIX_) || strncmp($table, _DB_PREFIX_, strlen(_DB_PREFIX_)) != 0) {
                continue;
            }

            if (!in_array($table, $tablesToBackup)) {
                continue;
            }

            // Export the table schema
            $schema = Db::getInstance()->executeS('SHOW CREATE TABLE `' . $table . '`');

            if (count($schema) != 1 || !isset($schema[0]['Table']) || !isset($schema[0]['Create Table'])) {
                fclose($fp);
                $this->delete();
                echo Context::getContext()->getTranslator()->trans('An error occurred while backing up. Unable to obtain the schema of %s', array($table), 'Admin.Advparameters.Notification');

                return false;
            }

            fwrite($fp, '/* Scheme for table ' . $schema[0]['Table'] . " */\n");

            if ($this->psBackupDropTable) {
                fwrite($fp, 'DROP TABLE IF EXISTS `' . $schema[0]['Table'] . '`;' . "\n");
            }

            fwrite($fp, $schema[0]['Create Table'] . ";\n\n");

            $data = Db::getInstance()->query('SELECT * FROM `' . $schema[0]['Table'] . '`', false);
            $sizeof = Db::getInstance()->numRows();
            $lines = explode("\n", $schema[0]['Create Table']);

            if ($data && $sizeof > 0) {
                // Export the table data
                fwrite($fp, 'INSERT INTO `' . $schema[0]['Table'] . "` VALUES\n");
                $i = 1;
                while ($row = Db::getInstance()->nextRow($data)) {
                    $s = '(';

                    foreach ($row as $field => $value) {
                        $tmp = "'" . pSQL($value, true) . "',";
                        if ($tmp != "'',") {
                            $s .= $tmp;
                        } else {
                            foreach ($lines as $line) {
                                if (strpos($line, '`' . $field . '`') !== false) {
                                    if (preg_match('/(.*NOT NULL.*)/Ui', $line)) {
                                        $s .= "'',";
                                    } else {
                                        $s .= 'NULL,';
                                    }

                                    break;
                                }
                            }
                        }
                    }
                    $s = rtrim($s, ',');

                    if ($i % 200 == 0 && $i < $sizeof) {
                        $s .= ");\nINSERT INTO `" . $schema[0]['Table'] . "` VALUES\n";
                    } elseif ($i < $sizeof) {
                        $s .= "),\n";
                    } else {
                        $s .= ");\n";
                    }

                    fwrite($fp, $s);
                    ++$i;
                }
            }
            ++$found;
        }

        fclose($fp);
        if ($found == 0) {
            $this->delete();
            echo Context::getContext()->getTranslator()->trans('No valid tables were found to backup.', array(), 'Admin.Advparameters.Notification');

            return false;
        }

        return true;
    }
}

Executing a backup of only the tables we care about is as simple as running:

// The following code will create a new backup based on your file
$backup = new ProductLangTablesBackup();
$backup->add();

This is, of course, a very simple example of how you can make your work easier. If you need something more advanced, there are ready-made libraries you can use in your modules. And finally, I’d like to recommend that module developers consider including such solutions in their products. More than once, it can help your users — and as you can see, the implementation is not complicated. 😉

Friends of Presta

Let’s start with what Friends of Presta actually is. As they write on their website:

“Friends of Presta brings together the PrestaShop community consisting of programmers, integrators, agencies, and software publishers. We are the first network of technology experts around PrestaShop CMS.”

This is an independent association of members of the PrestaShop community founded in France, which runs a series of initiatives in our ecosystem. One of them is “Security Advisories,” aimed at improving security in the ecosystem.

Friends of Presta Security Advisories

“Friends of Presta” launched an initiative that consists of creating a catalog with information about vulnerabilities in modules available for PrestaShop. They respond to reports from the community, clients of the association’s members, investigate them, and make sure the whole process ends with patching the vulnerabilities.

They follow best practices for reporting such bugs, investigate the issue, contact the authors of modules where vulnerabilities have been found, and then share detailed information about the potential attack and the version containing the security patch. However, it sometimes happens that the author completely ignores communications from their side. Unfortunately, some popular marketplaces (not from Poland and not the official one) ignore such calls to react. In this case, the Friends of Presta maintainers recommend finding an alternative to the affected module.

The list of module security advisories on this site can undoubtedly make it easier for agencies and store owners to react even before an attack, which is the most important thing — to respond before it happens.

Automatic module checking in your store

Now that you know such an initiative exists, let’s move to the main point of this article. One of the community members has created a module that allows you to scan your stores in search of add-ons that have known security vulnerabilities.

Wilson Alba Cal has shared a module that fetches vulnerability information from the Friends of Presta site and creates a ready report available in your store’s back office. The module also includes an option for scheduling periodic tasks that will check the store, e.g., once a day, and if any modules requiring your attention are detected, an email will be sent to you.

PrestaShop store security

It’s worth installing the described module, adding a recurring CRON task on your server, and helping yourself keep your stores secure. Of course, this is not a solution to every security problem. The security of any software is a complex matter. You should, above all, make sure to apply regular updates. If your store runs on an older version of PrestaShop, nothing prevents the agency that manages it from implementing only and exclusively security patches released for newer versions. Very often this is possible, sometimes it requires more work, but it’s certainly not as much as a full update.

It’s also worth remembering to properly care for the storage of your back office passwords — the access to your back office should be unique, maybe even cataloged in a secured password manager, and you might also consider using two-factor authentication modules. It’s equally important to update modules regularly. However, all of this does not mean that your store will never fall victim to an attack — unfortunately, quite the opposite. This does not only concern PrestaShop. Every month, similar cases occur in the WordPress or Magento ecosystems. Therefore, following the above recommendations or downloading and installing the module described in this article is just the first step.

The fop_publishedvulnerabilityscan module

The latest version of the module can be downloaded from GitHub in the repository where its development is ongoing.

If you are a developer and want to expand this module with new features, that’s of course possible too.

The module mentioned in this article is not the only community product designed to help you fight vulnerabilities in the PrestaShop ecosystem. In upcoming articles, we will cover more advanced solutions.

One of the users of a popular Polish PrestaShop group on Facebook did not manage to modify the form fields available during the registration process. His task was to alter the "optin" field. He wanted to change both the content and style of the field.

Code from this article will work with PrestaShop 1.7.7 and above versions.

With help comes the "additionalCustomerFormFields" hook. Since PrestaShop version 1.7.7, it got the &$fields parameter, which contains a whole array of fields used to create a registration form.

This article describes how we can use it.

How does it work?

As in many other places in the system, we have a parameter that is available as a reference (here's a more detailed explanation of what references are), thanks to that, we can operate with the data freely, and we will apply our modifications after calling this Hook.

To get started, we need, of course, to hook to the appropriate place in the code in our module.

public function install()
{
    return parent::install() && $this->registerHook('additionalCustomerFormFields');
}

In our module, we have access to the entire array of fields in the method that handles the hook. You can dump them, like this:

public function hookAdditionalCustomerFormFields($params)
{
    $format = $params['fields'];
    dump($format);
}

If we go to the registration page at this point, we will see all the fields:

The rest is just a formality. Let's move on to the real-world use of hookAdditionalCustomerFormFields.

Adding fields

Each field is an instance of FormField. This is a class available globally in the system. We can add a new field like this:

public function hookAdditionalCustomerFormFields($params)
{
    $format = $params['fields'];
    $format['confirmation_email'] = (new FormField())
        ->setName('confirmation_email')
        ->setType('email')
        ->setLabel($this->trans('Confirm your e-mail address', [], 'Modules.Demooverridecustomerformatter.Front'))
        ->setRequired(true);
    $params['fields'] = $format;
}

This way, we added a new field to the form. This field called "confirmation_email" is a typical example of adding an element to force the buyer to confirm their email address.

Deleting fields

If we want to make any of the fields no longer available in the form, we can remove them using PHP's unset. Example:

public function hookAdditionalCustomerFormFields($params)
{
    $format = $params['fields'];
    unset($format['id_gender']);
    $params['fields'] = $format;
}

Modifying existing fields

Let's see how we can modify fields, which the author of the thread on Facebook cared about. How to change the fields? Let's focus on the optin field. Let's modify its label and add a style (although this is not something we should do in this application layer).

public function hookAdditionalCustomerFormFields($params)
{
    $format = $params['fields'];
    $newLabel = '<em class="text-warning">';
    $newLabel .=    $this->trans(
        'I want to receive free gift from your partners',
        [],
        'Modules.Demooverridecustomerformatter.Front'
    );
    $newLabel .= '</em>';
    $format['optin']->setLabel(
        $newLabel
    );
    $params['fields'] = $format;
}

As we can see, by having access to an instance of a field, we can use methods available in the FormField class, one of them is setLabel.

We added em, color and changed the text, the effect is as follows:

Summary

As we can see, modifying the registration form fields using a dedicated Hook is quite accessible and allows developers to have complete control over it. As the fields are an array, we can freely modify them, change their order, delete and add new ones.

This article did not cover all the issues related to the registration form and its fields, I did not show how to receive the values sent from the additional fields, verify and possibly save them in the database. There will be time for that at another time.

If you have any questions, let me know :-)

Enabling the PrestaShop front office profiler is a great place to start if you need to know more about the performance of your PrestaShop.

The data is collected both for hooks and modules attached to them, but also for widgets. If you don't have PrestaShop 1.7.8, don't worry. The profiler in the new version is very easy to use also with older versions of PrestaShop. In this post I will show you how to use it in the older versions.

I've tested it in PrestaShop 1.7.7, and 1.7.6.

Using the profiler from 1.7.8 in lower versions of PrestaShop

To use profiler in lower versions of PrestaShop, only 4 steps are needed.

1. First download the PrestaShop 1.7.8 package, you can do it from here.
2. After unpacking it, copy the tools/profiling folder and move it to the same path in the older PrestaShop version.
3. Next step is to edit the config/config.inc.php file, just in the place where you currently have this code:

if (_PS_DEBUG_PROFILING_) {
    include_once _PS_TOOL_DIR_ . 'profiling/Controller.php';
    include_once _PS_TOOL_DIR_ . 'profiling/ObjectModel.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Db.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Tools.php';
}

replace it with:

if (_PS_DEBUG_PROFILING_) {
    include_once _PS_TOOL_DIR_ . 'profiling/Profiler.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Controller.php';
    include_once _PS_TOOL_DIR_ . 'profiling/ObjectModel.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Db.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Hook.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Module.php';
    include_once _PS_TOOL_DIR_ . 'profiling/Tools.php';
}

The last step you need to do, is to edit the controllers/admin/AdminLegacyLayoutController.php file and delete:

$this->outPutHtml;

from the end of the display method.

Now if you set _PS_DEBUG_PROFILING_ to true in the config/defines.inc.php, you can use a better version of the profiler in your PrestaShop store.

Summary

All this should give you more information about the health of your front office. You can expect more features available in the front office profiler in the next major version of PrestaShop.

Do you want to know more about the PrestaShop 8, and future of the PrestaShop? Read an article: PrestaShop Beyond 1.7.

The order list in PrestaShop has quite a bit of information about them. One piece of information missing, however, is the name of the selected carrier.

In this article I will walk you through the module that I published here:

https://github.com/kpodemski/kporderlistcarrier

This module allows you to add carrier name to the order list and filter by it. The whole thing is based on Hook, which is available in PrestaShop standard but it works only with the Symfony version of this page. That is why the module will work only for PrestaShop 1.7.7+

How it works. Grid component

At this moment, any list of elements taken from the database, on pages that have been migrated to Symfony in PrestaShop, uses a new component: Grid.

This component is similar to HelperList, which you may know from older versions of PrestaShop. HelperList is still present in the core, but you might want to use a modern alternative, which is Grid.

With this component, we will display a list of elements e.g. from the database. We will add options to search through it, sorting, we can also enable various operations on records, deleting, editing, or other. We can also define them ourselves.

Detailed information about the component is available in PrestaShop developers' documentation, you can find there examples of usage, default data types and much more about this component.

Example module

The solution I linked above uses the ability to modify the lists created by this component, directly from within the module. As you can see, I have attached to two Hooks:

/** @var array */
public const MODULE_HOOKS = [
    'actionOrderGridDefinitionModifier',
    'actionOrderGridQueryBuilderModifier',
];

The names of these Hooks are dynamic. You may want to hook to the customer list instead of the order list by replacing Order with Customer. You can find yet another example that executes hooks like these in the file: /src/Core/Grid/GridFactory.php.

/**
 * {@inheritdoc}
 */
public function getGrid(SearchCriteriaInterface $searchCriteria)
{
    $definition = $this->definitionFactory->getDefinition();
    $data = $this->dataFactory->getData($searchCriteria);

    // Here it is, hook that will modify the Grid data
    $this->hookDispatcher->dispatchWithParameters('action' . Container::camelize($definition->getId()) . 'GridDataModifier', [
        'data' => &$data,
    ]);

    $filterForm = $this->filterFormFactory->create($definition);
    $filterForm->setData($searchCriteria->getFilters());
    return new Grid(
        $definition,
        $data,
        $searchCriteria,
        $filterForm
    );
}

The Hook name is created as follows: action<Identifier of a given component>GridDataModifier.

The identifier is for example: const GRID_ID = 'customer';

This const is defined here: /src/Core/Grid/Definition/Factory/CustomerGridDefinitionFactory.php

Once we are hooked to the appropriate places in the core, we can execute our code. As it usually happens, in the implementation of a given Hook we get in the $params array, the appropriate "tools" to be able to modify the selected component.

In the case of hookActionOrderGridDefinitionModifier, we have access to the Grid component definition, which is hidden behind the GridDefinitionInterface implementation.

Using the $definition variable in the code, we can manipulate the columns in the listing. In the case of the sample module, we add the carrier_name column, which we display after the payment column. How do we know that the payment name column is payment? We can use, for example, the developer tools in the Chrome browser:

Next, we assign a filter to the column so that we can look for orders that should be shipped with the carrier we are looking for:

$filters = $definition->getFilters();
$filters->add((new Filter(static::CARRIER_FIELD_NAME, TextType::class))
    ->setTypeOptions([
        'required' => false,
    ])
    ->setAssociatedColumn(static::CARRIER_FIELD_NAME)
);

The code that allows us to retrieve the carrier name is a bit more complicated, but the principle is the same. We get the $params argument to modify the information retrieval for a given list and we do what we need with it.

The Grid component does not use the database legacy code, but the Doctrine one, $params['search_query_builder'] is a Doctrine instance of QueryBuilder.

In the addSelect method we can... yes, add the fields we want to retrieve. This works very similar to the DbQuery class that you may now from PrestaShop core.

It may puzzle you that at this point in the code:

$queryBuilder->addSelect(
    'IF(carrier.name = "0", "'.Configuration::get('PS_SHOP_NAME').'", carrier.name) carrier_name'
);

We check that the record is not "0". We do this because PrestaShop will set "0" when we select a carrier, which is added by default in the installer as "In-Store Pickup". This is a relic of the past, which should be straightened out in version 8.0 🙂

In the following code snippets, we already rely on search criteria. With this code, we control how we sort the listing and possibly filter it.

The whole process may seem very similar for developers who have already worked with Hooks like actionSomethingListingFieldsModifier. And, of course, it is.

Advanced Grid usage

Of course, the sample module that I give you is the simplest example of how to modify the Grid component. Grid is a very flexible mechanism that will allow you to add your own implementation of various mass actions that can be performed on records. There are also many possibilities of formatting the output data, etc.

I encourage you to read the documentation for developers and check the repository with more sample PrestaShop modules here.

btw. this is my first article here, your feedback will be a gift 🙏🏻