PrestaShop Addons Module Validation

PrestaShop Addons Module Validation (what it is and how to pass it)

When you submit a module to the PrestaShop Addons Marketplace, it goes through automated checks and a manual review. The reviewers mainly look for security, upgrade safety, code quality, and compatibility.

5

The fastest way to fail validation

1. Executing raw SQL with user input.
2. Trusting $_GET, $_POST, $_REQUEST, $_COOKIE directly.
3. Using Tools::getValue() without validation/casting.
4. Hard-deleting or altering core tables in uninstall() without clear justification.
5. Modifying core files or overriding classes without necessity.
6. Bundling obfuscated/minified-only PHP code.
7. Shipping debug code, dump statements, or writable 0777 permissions.
8. Making remote calls without disclosure, timeout handling, or user consent when required.
9. Using deprecated APIs for the declared compatibility range.
10. Missing multilingual support or escaping output in templates.

What reviewers typically check

Critical security pattern

Bad (often rejected):

Good (validated + cast + escaped/parameterized approach):

For strings, validate with Validate::isGenericName, Validate::isEmail, etc., and escape with pSQL() when building SQL manually.

Minimal module skeleton that reviewers like

Configuration form checklist

1. Use HelperForm or Symfony Settings Form (for modern modules).
2. Include a CSRF token (Tools::getAdminTokenLite() or Symfony token manager depending on controller stack).
3. Validate every field before saving.
4. Store config via Configuration::updateValue().
5. Escape output in templates: {$var|escape:'htmlall':'UTF-8'}.

Common compatibility declarations

In __construct():

Be conservative: only claim versions you actually test.

Before you upload: practical validation workflow

1. Enable dev mode and clear cache; install the module on a clean shop.
2. Run through install → configure → use feature → disable → uninstall → reinstall.
3. Check PHP logs for notices/warnings/fatal errors.
4. Scan for direct superglobals and raw SQL concatenation.
5. Verify translations load and templates escape variables.
6. Test with friendly URLs on/off and multistore if you claim support.
7. Zip only the module directory; exclude .git, node_modules, build artifacts, and IDE files.

PrestaShop 8/9 specifics

• Prefer namespaced classes + Composer autoloading for new modules.
• Use the Symfony service container/settings forms where appropriate instead of legacy admin controllers for new back-office UIs.
• Avoid legacy overrides unless absolutely necessary; reviewers scrutinize them heavily.
• Declare and bundle third-party dependencies cleanly; include license notices.

If your module calls external APIs

• Document what data is sent and why.
• Provide timeouts and error handling (don’t block page loads indefinitely).
• Use HTTPS and verify certificates.
• Make telemetry/analytics opt-in or clearly disclosed.

Submission package checklist

• README / user guide included
• Changelog included
• License information included
• Screenshots match the current UI
• Compatibility range matches tested versions
• No credentials, API keys, or test data in the package
• Module installs on a fresh PrestaShop instance

If you already have a module ZIP or source tree, review my module against Addons rules scan for security/compatibility issues check a specific install/uninstall or form implementation.