Utiliser l’IA pour générer un module PrestaShop conforme à la Safe Customization

Tuto PrestaShop : Utiliser l’IA pour générer un module PrestaShop conforme à la Safe Customization

L’intelligence artificielle peut devenir un véritable copilote pour développer vos modules PrestaShop plus rapidement… à condition de lui parler correctement !

Dans ce tutoriel 🎥, vous apprendrez à formuler des prompts efficaces pour obtenir un module fonctionnel, clair, et 100 % conforme aux règles de la Safe Customization.

🛠️ Nous verrons comment vérifier le code généré, corriger les erreurs typiques, et utiliser les IA comme Copilot, ChatGPT ou Claude pour vous faire gagner du temps tout en restant rigoureux.

Prompt utilisé :

You are a PrestaShop expert. I want you to generate a PrestaShop module for version 8.1 (PHP 8.1), strictly following all the official Safe Customization guidelines, including those listed here:  

https://docs.cloud.prestashop.com/10-validation-checklist/#common-rules

---

## 🎯 Expected functionality:

Please generate a PrestaShop module that:  

“NEED.”

---

## ⚙️ Constraints:

The module must follow these rules and best practices **without exception**:

🧱 Structure & Technical Compliance

• Folder name = main PHP file name = main class name.
• All .php files (except Ajax/cron) must begin with: if (!defined('_PS_VERSION_')) { exit; }
• The use of smarty / Twig templates is mandatory to display HTML. Your PHP code should not contain HTML.
• Compatibility declaration using $this->ps_versions_compliancy is required with specific version range (e.g., 'max' => '8.9.99' instead of _PS_VERSION_).
• No override of core PrestaShop files or native classes.
• No direct external dependencies (CDNs, third-party APIs) without validation.
• Code and comments must be in English only.
• Hook executions must be context-aware to reduce performance impact (e.g. if ($this->context->controller->controller_name === 'product')).
• Include a docs/ folder with documentation (documentation.md or PDF).
• Include a proper .gitignore file.
• Include a .htaccess file at the root to prevent direct access to .php files.
• Every single file of the package has to contain a valid license header.

🚨 CRITICAL SYMFONY COMPATIBILITY REQUIREMENTS

⚠️ IMPORTANT: To avoid 500 errors during installation, follow these rules:

• DO NOT create config/services.yml files unless the module has proper PSR-4 autoloading setup
• DO NOT use composer.json with PSR-4 autoloading unless all namespaced classes are properly implemented
• START SIMPLE: Create a basic working module first, then add Symfony features incrementally
• If using /src/ folder structure:
  • All classes MUST have proper namespaces: namespace PrestaShop\Module\ModuleName\Service;
  • All classes MUST include proper use statements for PrestaShop classes
  • Use \pSQL() instead of pSQL() in namespaced classes
  • Services MUST be properly defined with full namespace paths
• ALTERNATIVE APPROACH: Keep business logic in the main module class initially, then refactor to services later
• Use Dependency Injection (DI) instead of direct calls to Context::getContext() only when Symfony structure is fully implemented
• All business logic can reside in the main module class initially, then be moved to src/Service/ once proper namespace structure is established

🗃️ Database

• Use a dedicated table if needed.
• Never modify a native PrestaShop table.
• If linking to a native entity (customer, product, etc.), use a proper foreign key in the custom table.
• EMBED SQL directly in install/uninstall methods rather than separate files to avoid path issues
• SQL queries must use Db::getInstance()->execute() with:
  • _DB_PREFIX_
  • pSQL(), (int), bqSQL() for escaping
• Scripts install.php, uninstall.php, upgrade-x.y.z.php must be clean, testable, and contain only what is necessary.
• If a file must be deleted during upgrade, use unlink() in the upgrade file.

🔐 Security

• All user input must be validated and escaped.
• Do not use serialize() or unserialize() — prefer json_encode() / json_decode().
• All AJAX or CRON requests must:
  • go through a ModuleFrontController
  • be protected with a secure token (Tools::getAdminToken() or similar)
• Never expose raw variables in templates.
• Prevent directory browsing by using index.php in each folder.
• Use Tools::getIsset() or Tools::getValue() with caution (type casting, filtering).
• Use HelperForm::getToken() for back office forms and verify the token.

🖼️ Front and Back Office Display

• USE SIMPLE .tpl TEMPLATES INITIALLY to avoid Twig configuration issues
• .tpl templates are preferred for compatibility, and all variables must be escaped:
  • {$var|escape:'htmlall':'UTF-8'}
• Use Twig only after basic functionality is working:
  • Example: views/templates/admin/twig/configure.html.twig
• No HTML should be echoed from PHP classes.
• Back office UI must use HelperForm or a Symfony-compatible form class.
• USE $this->l() for translations instead of $this->trans() to avoid translation domain issues

🧪 Tests & Quality Tools

• Provide a tests/ directory with:
  • unit tests in tests/Unit/
  • integration tests in tests/Integration/
• A phpunit.xml file must be present at the root.
• Optional but recommended: add a linter (phpcs.xml, .editorconfig, etc.)

🧽 Clean Code & Quality

• No var_dump(), dump(), die(), console.log(), or echo statements.
• No unnecessary comments, blank lines, or temporary files.
• No .DS_Store, .log, .bak, or similar files.
• Remove any unused or empty files before zipping.
• Code must be properly indented, readable, and logically separated.
• Follow MVC structure: separate business logic, presentation, and data.
• Remove trailing whitespace at the end of blank lines. 
• There should not be blank lines between docblock and the documented element. 
• A single space or none should be between cast and variable. 
• An empty line feed must precede any configured statement. 
• README.md must include:
  • Module description
  • Prerequisites
  • Installation steps
  • Configuration instructions
  • Example output or rendering

🔧 Miscellaneous

• All configuration keys must be prefixed:
  Configuration::get('CUSTOMHEADERCOLOR_ENABLED')
• All custom classes must be prefixed with the module name.
• If the module loads external resources (iframe, remote JS), include a header_csp.txt file.
• Use the /var/dev/ or /var/prod/ directory for temporary or local storage if needed.
• The license must comply with the PrestaShop open source model (OSL-3.0 or AFL-3.0) and be included in file headers.

🔄 DEVELOPMENT APPROACH:

Phase 1 - Basic Working Module:

1. Create simple module class with embedded SQL
2. Use $this->l() for translations
3. Use .tpl templates
4. Basic HelperForm configuration
5. Test installation and configuration page

Phase 2 - Add Functionality:

1. Add customer form hooks
2. Add validation logic
3. Add database operations
4. Test customer registration flow

Phase 3 - Symfony Integration (Optional):

1. Add proper namespaced service classes
2. Create config/services.yml
3. Add composer.json with PSR-4
4. Migrate to Twig templates
5. Implement dependency injection

🔄 Expected Output:

Please generate all necessary files in a clean and zip-ready structure.
The module must be:

• functional right after installation (Phase 1 approach)
• fully Safe Customization compliant
• free of overrides or core class modifications
• ready for submission to the PrestaShop Addons Marketplace
• installable without 500 errors by following the phased approach

START WITH PHASE 1 - create a simple, working module that can be installed and configured successfully, then build functionality incrementally."