Struttura di un modulo moderno per PrestaShop 8 e 9

Molti moduli sono ancora scritti come in PrestaShop 1.6: un file principale di migliaia di righe, SQL a mano e form di HelperForm. Funzionano, ma costano molto da mantenere. Questa è la struttura che seguiamo nei nostri moduli per PrestaShop 8 e 9.

L'albero delle cartelle

mimodulo/
├── mimodulo.php          # classe principale: installazione, hook, poco altro
├── composer.json         # autoload PSR-4 del namespace
├── config/
│   ├── services.yml      # servizi Symfony
│   └── routes.yml        # rotte del back office
├── src/
│   ├── Controller/Admin/ # controller Symfony
│   ├── Entity/ o Repository/
│   └── Service/          # logica di business, testabile
├── views/
│   ├── templates/hook/   # template Smarty del front
│   ├── templates/admin/  # template Twig del back office
│   ├── css/ js/ img/
├── upgrade/              # upgrade-1.1.0.php, upgrade-1.2.0.php…
├── translations/
└── logo.png

La classe principale, snella

Il file mimodulo.php dovrebbe limitarsi a dichiarare il modulo, installarlo e delegare. La logica vera va in classi di src/ che si possono testare separatamente:

public function hookActionValidateOrder(array $params)
{
    $this->get('mimodulo.order_notifier')->notify($params['order']);
}

Composer e namespace

{
  "name": "rekire/mimodulo",
  "autoload": { "psr-4": { "Rekire\\MiModulo\\": "src/" } },
  "config": { "prepend-autoloader": false },
  "type": "prestashop-module"
}

L'opzione prepend-autoloader: false evita che il tuo autoloader si metta davanti a quello di PrestaShop, cosa che può causare conflitti di versione con librerie che il core include già.

Back office con Symfony

In PrestaShop 8 e 9 le schermate di configurazione possono essere controller Symfony con form Symfony e template Twig, dichiarati in config/routes.yml. Così si integrano con il menu, i permessi e i token CSRF del back office senza reinventarli.

Upgrade fin dal primo giorno

Ogni versione che modifica il database, registra nuovi hook o crea schede ha il suo upgrade/upgrade-X.Y.Z.php. E quello script deve essere idempotente: se si esegue due volte, non duplica niente. È ciò che evita schede duplicate nel menu o colonne che falliscono alla creazione.

Validazione prima di pubblicare

• Intestazione della licenza in tutti i file.
• Escape delle variabili in Smarty (|escape:'html':'UTF-8').
• Nessuna funzione vietata dal validatore di Addons.
• index.php in ogni cartella.
• Test su almeno due versioni di PrestaShop e con la modalità debug attiva: gli avvisi che in produzione non si vedono, nel rapporto di compatibilità contano eccome.

Con questa struttura, un modulo può crescere per anni senza diventare un file che nessuno osa toccare.