TL;DR: se una funzione AI in WordPress riceve due volte la stessa richiesta, non dovrebbe chiamare due volte il modello. Crea una chiave dalla richiesta e dalla versione del prompt, salva la risposta in un transient con scadenza e prevedi sempre il ricalcolo quando la cache manca.

Il problema: pagare due volte la stessa risposta

Un form ricaricato, un doppio clic o un job ripetuto possono inviare lo stesso input più volte. Se ogni passaggio chiama subito l’API AI, aumentano latenza e consumo senza produrre nuovo valore. Per una PMI il problema non è il singolo centesimo: è un’integrazione che non ha un comportamento prevedibile.

La soluzione: una chiave stabile e versionata

Prima della chiamata, normalizza solo i campi che determinano davvero la risposta. Poi costruisci una chiave con input, modello e versione delle istruzioni. Se cambi prompt ma lasci invariata la chiave, WordPress può restituire una risposta prodotta con regole vecchie.

$domanda = isset( $_POST['question'] )
	? sanitize_text_field( wp_unslash( $_POST['question'] ) )
	: '';

$payload_cache = array(
	'v'        => 2,
	'model'    => 'modello-configurato',
	'domanda'  => mb_strtolower( trim( $domanda ) ),
);

$chiave = 'lr_ai_' . hash( 'sha256', wp_json_encode( $payload_cache ) );
$risposta = get_transient( $chiave );

if ( false === $risposta ) {
	$risposta = lr_chiama_ai( $domanda );

	if ( ! is_wp_error( $risposta ) ) {
		set_transient( $chiave, $risposta, HOUR_IN_SECONDS );
	}
}

if ( is_wp_error( $risposta ) ) {
	echo esc_html__( 'Servizio temporaneamente non disponibile.', 'tema-o-plugin' );
	return;
}

echo esc_html( (string) $risposta );

Il punto non è copiare lo snippet alla cieca. La funzione lr_chiama_ai() deve già gestire autenticazione e timeout; la cache viene dopo una risposta valida, mai dopo un errore. Se la chiamata fallisce, la pagina mostra un messaggio sicuro invece di passare un oggetto WP_Error all’escaping.

I passaggi essenziali

  1. Sanitizza l’input prima di usarlo.
  2. Inserisci nella chiave tutto ciò che cambia il risultato: testo, modello, lingua e versione del prompt.
  3. Controlla get_transient() con false ===, come indica la documentazione WordPress.
  4. Salva soltanto risposte valide e assegna una scadenza esplicita.
  5. Fai escaping quando mostri il risultato nella pagina.

WordPress definisce la scadenza di un transient come durata massima, non come garanzia di permanenza. Un object cache o un’operazione sul database può rimuoverlo prima. Il codice deve quindi saper rigenerare la risposta in ogni momento.

L’errore da evitare

Non usare i transient come archivio definitivo e non mettere nella chiave dati personali in chiaro. Una chiave hash riduce l’esposizione accidentale, ma non rende automaticamente sicuro il contenuto salvato. Per richieste riservate o risposte legate a un singolo utente servono isolamento, autorizzazioni e una politica di conservazione precisa. In molti casi è meglio non fare cache.

La take operativa

La cache non è un trucco di performance: è una regola di prodotto. Decidi quando due richieste sono equivalenti e scrivilo nella chiave. Se non sai spiegare quando la risposta va invalidata, non hai ancora progettato la cache.

Lo stesso principio vale per l’output: prima di salvarlo o pubblicarlo, valida la struttura JSON generata dall’AI.

Fonti