For a store to be classified as PrestaShop Enterprise and enjoy its full benefits, all custom modules must adhere to these guidelines without exception.
Modifying or overriding the original PrestaShop Core files conflicts with seamless upgrades.
Core modifications: Any changes to the PrestaShop Core are incompatible with future upgrades. Modifying source code without proper disclosure violates the license agreement.
Core overrides: Avoid overriding Core files to introduce new behaviors or alter native functionalities. Overrides hinder the upgrade process and should only be used in rare, unavoidable cases. Be prepared to justify your choice during PrestaShop’s analysis. If in doubt, contact PrestaShop for guidance.
Checksum verification: PrestaShop will perform a checksum comparison to detect any unauthorized modifications.
Rather than modifying or overriding Core files, prioritize using hooks. An extensive list of hooks is available in the Open Source documentation. Feel free to contribute to the Open Source by adding more.
No ROOT access to the PrestaShop server is allowed, as it provides access to restricted files and poses a significant security risk.
Configuration files for PHP, Apache, databases, and other system components should remain unchanged in the production environment.
If modifications are required, please submit a support ticket.
All code changes in a production environment must be made exclusively through Git. Direct modifications via FTP or SSH are strictly prohibited to ensure version control, traceability, and rollback capability.
Using wget in Cron jobs to call PHP scripts (PHP-FPM) via HTTP can introduce significant security risks.
What you should do instead:
Some modules use PHP functions like exec or shell_exec to execute server commands, bypassing PrestaShop’s security mechanisms. This can introduce significant vulnerabilities. Rely on PrestaShop’s built-in tools to ensure security and stability.
/modules, /themes, and /overrides directories should be tracked by Git (not included in the .gitignore file), as they represent critical parts of your PrestaShop store./uploads and /img, should be ignored by Git. These files don’t need to be versioned, and their inclusion could bloat the repository unnecessarily.Do not store module data at the root of the /modules folder or in unnecessary new folders.
Module data should be stored only in designated locations, such as /var/modules/<module_name>/, a non-versioned directory allowing you to keep your module organized.
Identify the best location for log writing. PrestaShop offers two logging systems:
PHP Logger: This is primarily used for logging small events (action history). It is possible to hook into this system, but it’s recommended to avoid using PHP Logger for large logs as it stores logs in the database, which can cause performance issues.
File Logging: For more extensive logging, it’s recommended to write logs to the /var/modules/<module_name>/logs folder.
vendor Folder ConflictsIf conflicts occur with the vendor folder, use PHP-Scoper to prefix it with the module’s name.
See the folder structure here.
Some hooks may be omitted in custom themes. If a module uses a hook that is not declared in the theme, the module will not display or function correctly.
To ensure compatibility, all existing hooks should be declared in the theme. Hooks can be removed during installation if necessary. It is still possible to unhook a module later if it causes issues.
Controllers should not be added through overrides, as this introduces new entry points and routes, making future upgrades more difficult. Instead, create a specific module with its own controller.
In the __construct function of your module, you must specify the minimum and maximum compatible versions of PrestaShop. This ensures your module’s compatibility remains clear and avoids potential issues with future updates. For more information, refer to the validation checklist.
$this->ps_versions_compliancy = ['min' => '1.7.6.0', 'max' => _PS_VERSION_];
Avoid using _PS_VERSION_ for the maximum version, as it would mark all future PrestaShop versions as compatible, which may cause issues.
$this->ps_versions_compliancy = ['min' => '1.7.6.0', 'max' => '8.1.99'];
Use the X.Y.99 format for the maximum version, where:
X represents the major version.Y represents the minor version.99 acts as a placeholder, allowing flexibility without needing to be updated for every minor release.This approach ensures that your module is marked compatible up to a specific version, preventing accidental compatibility with major updates that could introduce breaking changes.
Where possible, follow Symfony best practices for module development, as outlined in the official documentation. However, note that PrestaShop is not fully Symfony-compliant, and strictly following Symfony may not always be possible.
Prioritize the use of CQRS (Command Query Responsibility Segregation) when possible.
For more information, refer to the Open Source documentation on CQRS.
Avoid using SELECT * without a WHERE clause, as it can severely impact performance, especially when dealing with large datasets. Using LIMIT and OFFSET alone is also insufficient for performance optimization.
Implement web-based callbacks with proper exception handling. Remote API calls should have defined timeouts and robust error handling to prevent indefinite execution and resource wastage.
These modules are resource-intensive and can significantly degrade performance, especially in the backend. While they offer customization options for small merchants, they are not suitable for enterprise-level use.
Regularly clean up tables such as ps_guests, ps_connections, and ps_cart_rule to prevent performance issues. Monitor fast-growing tables and ensure they are emptied when necessary.