Reseller Manager: dall’audit ai test Docker per WooCommerce
Riproduzione dei difetti, correzione di permessi e prezzi, 48 verifiche comportamentali e pipeline Docker ripetibile.
Quando riprendo un progetto dimostrativo, una delle domande più utili è questa: quali comportamenti posso dimostrare con una verifica ripetibile?
Ho affrontato questa domanda lavorando su Reseller Manager, un mio plugin dimostrativo per WooCommerce dedicato alla registrazione dei rivenditori, all’approvazione degli account e alla gestione di prezzi riservati.
Il lavoro ha riguardato codice, test e documentazione. Il riferimento per il codice applicativo verificato è la revisione 3f4e199. Il risultato è una suite eseguibile in Docker che ha superato 48 verifiche comportamentali, accompagnata dal controllo sintattico dei 17 file PHP presenti nel repository. È un avanzamento del progetto, che mantiene il suo carattere didattico e alcuni limiti ancora da esplorare.
Il progetto in breve
Reseller Manager nasce come progetto dimostrativo per esplorare un’esigenza frequente negli e-commerce B2B: affiancare al normale catalogo WooCommerce un percorso riservato ai rivenditori, senza trasformare il negozio in una piattaforma commerciale separata.
Il flusso coperto dal plugin parte dalla richiesta di registrazione. Il nuovo account riceve il ruolo rivenditore e rimane in attesa finché un amministratore non lo approva. Dall’area Rivenditori è possibile creare, approvare, disabilitare o eliminare gli account e configurare le condizioni economiche dedicate.
Il repository implementa due strategie di prezzo:
- prezzi riservati nel catalogo e nel carrello, definiti per singolo prodotto oppure calcolati applicando uno sconto globale;
- prezzo pubblico visibile con sconto nel carrello, dove il catalogo resta invariato e la riduzione viene applicata come voce negativa sul subtotale.
I moduli di registrazione e accesso sono disponibili sia come shortcode sia come blocchi Gutenberg. Nel codice, il file di ingresso inizializza il plugin, la logica principale è raccolta nella classe core e le interfacce sono separate tra pagine amministrative, shortcode e blocchi. Questa organizzazione rende riconoscibili i confini tra bootstrap, regole applicative e presentazione.
Il progetto è pubblico per documentare scelte tecniche, verifiche e progressi. Rimane un laboratorio didattico: non è un servizio ospitato né un prodotto dichiarato pronto per l’uso in produzione. Il repository GitHub contiene codice, istruzioni, test e limiti aggiornati.
Il modulo della demo locale, con dati di esempio e senza un sito di produzione.
Prima riprodurre, poi correggere
Il punto di partenza era un test circoscritto del modulo di iscrizione, costruito con funzioni WordPress simulate. Era utile per controllare che i nomi dei campi corrispondessero a quelli letti dal gestore e che codice fiscale e partita IVA restassero separati.
Per verificare autorizzazioni, utenti e prezzi serviva però anche un ambiente con WordPress, WooCommerce e un database reali.
Ho quindi aggiunto uno stack Docker dedicato. Il primo ciclo di integrazione ha fatto emergere 14 casi falliti su 18. I controlli successivi hanno esteso la copertura alle azioni amministrative, alla disinstallazione, ai blocchi Gutenberg e agli input malformati.
Per ogni gruppo di problemi, l’obiettivo era ottenere una riproduzione prima della correzione e mantenere il caso nella suite come test di regressione.
Permessi: il nonce è solo una parte del controllo
Una parte dell’intervento ha riguardato l’accesso ai profili rivenditore e le operazioni amministrative.
I test hanno mostrato che i controlli sui nonce, da soli, non garantivano che l’utente avesse anche il diritto di eseguire l’azione. Ho aggiunto verifiche esplicite delle capability e del ruolo dell’account destinatario.
La gestione dei profili e delle azioni richiede ora manage_options; la cancellazione verifica anche la capability relativa all’utente da eliminare. I test controllano sia il rifiuto delle operazioni non autorizzate sia il percorso di approvazione consentito all’amministratore.
È una distinzione utile nello sviluppo WordPress: la validità di una richiesta e l’autorizzazione di chi la invia sono controlli separati.
Prezzi WooCommerce: mantenere separati numeri e presentazione
Un altro gruppo di problemi riguardava il calcolo dei prezzi riservati.
Nel percorso del carrello, un prezzo personalizzato veniva formattato come HTML prima di essere assegnato al prodotto. Inoltre, un’uscita prematura dal ciclo impediva di elaborare tutte le righe.
Ho separato il valore numerico dalla sua visualizzazione e corretto l’elaborazione dell’intero carrello. I test verificano anche due casi facili da trascurare: un prezzo personalizzato con sconto globale pari a zero e il ricalcolo dei totali.
Per esempio, un prodotto con prezzo corrente di 160 e sconto rivenditore del 10% deve restare a 144 anche dopo un secondo calcolo. Il prezzo regolare del prodotto deve rimanere invariato.
Le verifiche coprono inoltre l’esclusione dagli sconti degli account disabilitati e degli utenti che non hanno il ruolo rivenditore.
Un account e due prodotti fittizi mostrano le impostazioni disponibili nell’amministrazione.
Moduli, blocchi e conservazione dei dati
L’intervento ha incluso altri comportamenti osservabili:
- il salvataggio dei prezzi in una pagina del catalogo conserva quelli assegnati agli altri prodotti;
- gli shortcode restituiscono il contenuto e i blocchi Gutenberg mostrano correttamente i moduli;
- alcuni input inviati come array vengono gestiti senza provocare l’errore PHP riprodotto nei test;
- le password vengono affidate a WordPress senza trattarle come normale testo da ripulire;
- la disinstallazione rimuove i dati propri del plugin e conserva gli account WordPress e i contenuti.
Quest’ultimo comportamento è documentato anche nel README: eliminare un account dall’amministrazione e disinstallare il plugin sono operazioni distinte.
Risposta a un invio reale del modulo nel browser locale. La conferma non attesta l’invio effettivo di un’email.
Che cosa verificano i test
La suite completa comprende:
| Livello | Verifiche | Oggetto |
|---|---|---|
| Contratto del modulo | 12 | Campi, nonce e dati di registrazione con funzioni simulate |
| Integrazione | 29 | Permessi, approvazione, prezzi, carrello, moduli e pulizia dei dati |
| HTTP | 7 | Iscrizione e login tramite richieste al WordPress locale |
Le prove HTTP controllano che l’iscrizione crei un account in attesa, che il login sia negato prima dell’approvazione e che un account abilitato riceva il redirect e il cookie di accesso. Comprendono anche nonce non valido e password errata.
L’ambiente verificato usa WordPress 7.0, WooCommerce 11.2.1 e MariaDB 10.11, con PHP 8.3.33 per i test da riga di comando e PHP 8.2.31 per le richieste web.
Rapporto visuale generato dal log del runner Docker locale, distinto dall’esecuzione su GitHub Actions.
Le schermate e l’output completo della verifica accompagnano il case study nel repository.
Una suite ripetibile, senza usare il sito di produzione
Il comando di ingresso è:
bash tests/run.sh
Il runner crea un nuovo progetto Docker con volumi dedicati, installa le dipendenze, esegue i controlli e rimuove il proprio ambiente temporaneo al termine. Le immagini sono fissate per digest e la versione di WooCommerce è esplicita.
L’ambiente non pubblica porte e monta il repository in sola lettura. Le prove sono state eseguite localmente: il sito matcode.dev non è stato modificato.
Rendere il controllo disponibile anche su GitHub
Ho aggiunto un workflow GitHub Actions che usa lo stesso runner su push e pull request e conserva il log come artifact. La configurazione è stata controllata con actionlint.
La prima esecuzione pubblica della pipeline, sul commit 440ceae, è terminata con esito positivo. È stata verificata anche la presenza dell’artifact docker-test-output. Il risultato riguarda quella revisione; l’esito dei controlli successivi resta consultabile nella scheda Actions del repository.
Il repository include inoltre il testo della licenza GPLv2-or-later, coerente con la dichiarazione già presente nel plugin.
I limiti da portare nel prossimo incremento
I risultati descrivono gli scenari eseguiti. Restano da verificare prodotti variabili, combinazioni complesse di tasse e coupon, Store API e Checkout Blocks, multisite, versioni precedenti e interazioni con altri plugin che modificano i prezzi.
Anche l’invio reale delle email richiede un controllo dedicato: nei test dei controller viene intercettato. La suite non sostituisce un audit di sicurezza completo né una verifica di compatibilità con qualsiasi installazione WooCommerce.
Il prossimo incremento partirà da questi limiti, con nuovi casi riproducibili. Per seguire il progetto e consultarne codice e documentazione, il riferimento è il repository Reseller Manager su GitHub.
Torna alla raccolta dei progetti recenti oppure contattami per parlare di sviluppo WordPress, WooCommerce o backend PHP.