Usar IA para generar un módulo PrestaShop conforme a la Safe Customization

Tuto PrestaShop : Usar IA para generar un módulo PrestaShop conforme a la Safe Customization

La IA puede ser tu mejor aliada para desarrollar más rápido… ¡si sabes cómo guiarla!

En este tutorial 🎥, aprenderás a escribir prompts eficaces para generar módulos PrestaShop funcionales y conformes con la Safe Customization.

🛠️ Veremos cómo revisar y corregir el código generado, qué herramientas usar (Copilot, Claude, ChatGPT…) y cómo mantener la calidad y seguridad del código.

Prompt : 

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."