extend_signup_form e validate_extend_signup_form sono due interessanti callback messe a disposizione da Moodle, fin dalla versione 3.8, per estendere le funzionalità relative all’iscrizione degli utenti. Ad esempio, grazie all’estensione dell’hook validate, possiamo aggiungere la classica funzione custom che verifica la coerenza sintattica di un codice fiscale.
Basta definire questi due hook all’interno di un semplice plugin di tipo local, nel file lib.php, e i giochi sembrano fatti. Almeno in apparenza.
Infatti, queste callback si applicano solo alla fase di iscrizione e non a quella di modifica. Quindi, un utente già registrato che vada a modificare il proprio codice fiscale, inserendone uno errato, non verrebbe bloccato: il dato verrebbe comunque salvato nel database senza alcun controllo.
Inoltre, queste callback non sono compatibili né con le API esposte ai web services né con l’app Moodle.
Due possibili strade
A questo punto abbiamo due strade:
- una corretta e ortodossa,
- l’altra un po’ “pecionata”, ma — come tutte le pecionate — funzionante.
✅ Soluzione corretta: il campo personalizzato
Se la nostra esigenza è quella di validare un campo specifico, la strada giusta non è usare le callback, bensì creare un nuovo campo personalizzato.
A tal fine, possiamo sviluppare un plugin nella cartella user/profile/field, ad esempio codicefiscale, in cui estendere la classe profile_field_base, implementando in particolare il metodo edit_validate_field.
Questo metodo riceve come parametro $usernew, che rappresenta i dati aggiornati dell’utente prima che vengano salvati nel database. Tramite $usernew->id possiamo anche distinguere tra fase di iscrizione e fase di modifica dei dati.
Ecco un esempio pratico:
public function edit_validate_field($usernew) {
$errors = [];
if (isset($usernew->{$this->inputname})) {
if (!preg_match('/^[A-Z]{6}[0-9]{2}[A-Z][0-9]{2}[A-Z][0-9]{3}[A-Z]$/i', $usernew->{$this->inputname})) {
$errors[$this->inputname] = get_string('invalidcf', 'profilefield_codicefiscale');
}
}
return $errors;
}
È importante verificare l’esistenza del campo (isset()), poiché l’amministratore del sito può decidere se mostrarlo o meno — spesso i campi custom vengono visualizzati solo nella fase di modifica, per semplificare il modulo d’iscrizione iniziale.
🧩 Gli observer: utili ma “postumi”
A corredo, Moodle mette a disposizione anche gli observer, come \core\event\user_created e \core\event\user_updated. Questi eventi possono essere intercettati anche da un plugin di tipo local, e sono ottimi per operazioni post-salvataggio.
Tuttavia, non sono adatti alla validazione, in quanto vengono richiamati solo dopo che i dati sono già stati memorizzati nel database.
Un possibile escamotage, se proprio necessario, è salvare temporaneamente i dati in una tabella di appoggio e intervenire in un secondo momento per verificarli e ripristinarli se non validi. Ma è una soluzione decisamente poco ortodossa.
