Alessandro Aili - WordPress Developer
Alessandro Aili - WordPress DeveloperPlay Alessandro Aili - WordPress DeveloperDrag Alessandro Aili - WordPress DeveloperView
Alessandro Aili - WordPress Developer
  • Homepage
  • Chi sono
  • Portfolio
  • Aree di Attività
    • Sviluppo di Siti Web Personalizzati
    • Ottimizzazione delle Prestazioni
    • Sicurezza del Sito Web
    • Aggiornamenti e Manutenzione
    • Sviluppo di Temi e Plugin Personalizzati
    • Migrazione e Trasferimento del Sito
  • Blog
  • Contatti
Alessandro Aili - WordPress Developer
Alessandro Aili - WordPress Developer Alessandro Aili - WordPress Developer
  • Homepage
  • Chi sono
  • Portfolio
  • Aree di Attività
    • Sviluppo di Siti Web Personalizzati
    • Ottimizzazione delle Prestazioni
    • Sicurezza del Sito Web
    • Aggiornamenti e Manutenzione
    • Sviluppo di Temi e Plugin Personalizzati
    • Migrazione e Trasferimento del Sito
  • Blog
  • Contatti
MENU Alessandro Aili - WordPress Developer
  • Home
  • Temi e Plugin
  • Blog
  • Come creare una alert bar in WordPress: dall’editor, a mano o con un plugin

Come creare una alert bar in WordPress: dall’editor, a mano o con un plugin

Alessandro Aili - WordPress Developer
Alessandro Aili WordPress Developer

Data di pubblicazione

4 Settembre 2026

Tempo di lettura

19 minuti

Categoria

Temi e Plugin

Commenti

0

Barra di avviso a tutta larghezza in cima a un sito WordPress, con il pulsante di chiusura a destra e l'intestazione del tema sotto

Devi mettere una riga in cima al sito: le spedizioni sono sospese, il negozio chiude per ferie, c’è un webinar giovedì. Sembra la modifica più piccola che esista, e infatti quasi tutte le guide la liquidano in due passaggi — installa un plugin, scrivi il testo. Poi il messaggio compare, e con lui compaiono quattro problemi che nessuno aveva nominato: la pagina che sussulta al caricamento, il pulsante di chiusura che non si riesce a premere, il visitatore che chiude la barra e se la ritrova identica alla pagina dopo.

La domanda giusta non è «quale plugin», è che tema hai. Se è un tema a blocchi, questa modifica si fa dall’editor in cinque minuti, senza codice, senza plugin e — la parte che sorprende chi arriva qui dalla guida al child theme — senza child theme. Se è un tema classico, serve una funzione, ma il posto dove metterla non è quasi mai quello che ti aspetti.

Questa guida copre le tre strade — dall’editor, a mano, con un plugin — e dice per ciascuna quando è quella giusta. Poi affronta la parte che decide se la barra funziona davvero: come si chiude, che su un sito con la cache di pagina attiva non è un dettaglio di comodo ma un vincolo di architettura.

Una nota sulle fonti. Tutto quello che segue l’ho verificato il 3 settembre 2026 sulla documentazione ufficiale di WordPress, sulle schede dei plugin nel repository, sulle specifiche del W3C e — per il comportamento dei due tipi di tema — sul codice sorgente del core. I blocchi di codice sono stati eseguiti, non solo riletti: dove il risultato è misurabile, il numero che leggi è quello che ho misurato.

Prima di scegliere il metodo: che tema hai

Questa è l’unica domanda preliminare, e cambia tutte le risposte successive. WordPress ha due famiglie di temi che si comportano in modo diverso proprio nel punto che ci interessa — come si costruisce l’intestazione della pagina.

Il modo più rapido di scoprirlo non richiede di aprire file: vai in Aspetto nel menu della bacheca. Se c’è la voce Editor, il tema è a blocchi. Se ci sono Personalizza e Widget, è classico. È una distinzione che il core espone anche a chi scrive codice, con la funzione wp_is_block_theme(), introdotta nella 5.9.

I due temi predefiniti recenti sono entrambi a blocchi: Twenty Twenty-Four e Twenty Twenty-Five, e quest’ultimo è il tema che WordPress attiva sulle installazioni nuove. Se hai comprato un tema su un marketplace tre o quattro anni fa, invece, è quasi certamente classico. La strada cambia così:

Il tuo temaStradaServe un child theme?
A blocchiEditor del sito, parte del template HeaderNo
Classico, chiama wp_body_open()Una funzione in un pluginNo
Classico, non lo chiamaSovrascrivere header.phpSì
Qualsiasi, ma servono programmazione e statistichePlugin dedicatoNo

Tre righe su quattro dicono no, ed è il motivo per cui questa guida non parte da un file PHP come fanno quasi tutte. Il child theme resta la risposta giusta a molte cose — è la domanda che conviene porsi prima di ogni modifica al tema — ma per una barra di avviso è quasi sempre lo strumento sbagliato, perché una barra è contenuto, e il contenuto non dovrebbe sparire il giorno in cui cambi tema. Lo stesso ragionamento vale, con un esito ancora più secco, per due righe di testo nell’header.

Se stai leggendo perché il tema che hai ti sta stretto in generale, e questa è solo l’ultima di una lista di cose che non riesci a cambiare, la domanda vera è un’altra e l’ho trattata a parte: i sei criteri con cui si sceglie un tema.

Tema a blocchi: si fa dall’editor, senza codice e senza plugin

In un tema a blocchi l’intestazione del sito non è un file PHP: è una parte del template, cioè un pezzo di layout salvato una volta e riusato da tutti i modelli che lo includono. La documentazione ufficiale del blocco Parte del template, che esiste dalla 5.9, lo dice in una riga che vale tutta la sezione: quando modifichi i blocchi dentro una parte del template, l’editor aggiorna quei blocchi su ogni modello che la include.

Tradotto: aggiungi la barra una volta sola nell’header e compare su tutto il sito. Non serve ripeterla nei modelli, non serve un plugin che la inietti, non serve una funzione agganciata da qualche parte.

Dove si aggiunge, esattamente

Il percorso, con i nomi che vedi davvero nell’interfaccia in italiano:

  1. Aspetto → Editor.
  2. Pattern, e in fondo alla colonna Parti del template.
  3. Apri Header — è il nome dell’area, e nell’interfaccia italiana resta in inglese.
  4. Porta il cursore sopra il primo blocco e usa il segno + per inserire un blocco Gruppo prima di tutto il resto.
  5. Dentro il Gruppo metti il testo, e se serve un pulsante o un link.
  6. Salva.

Il Gruppo va messo prima del contenuto esistente dell’header, non dopo: una barra di avviso sotto il menu non è una barra di avviso, è un sottotitolo. Se preferisci vederla come elemento separato dall’intestazione, puoi anche creare una parte del template nuova con Area: Generale e inserirla in cima ai modelli — ma allora la devi aggiungere a ogni modello, e il vantaggio dell’header è proprio che è uno solo.

C’è una cosa da sapere prima di affezionarsi a questa strada, ed è la stessa che vale per il CSS aggiuntivo: quello che modifichi dall’editor sta nel database, legato al tema attivo. Nel codice del core la parte del template personalizzata viene cercata filtrando per il tema in uso, quindi il giorno in cui cambi tema la tua barra non sparisce dal database ma smette di comparire, perché appartiene al tema di prima. Se prevedi di cambiare tema e portarti dietro il messaggio, la strada giusta è la prossima, non questa.

Farla restare in cima quando si scorre

Non serve CSS. Seleziona il Gruppo, apri le impostazioni del blocco e cerca Posizione: la voce da scegliere è In evidenza. È la traduzione italiana di sticky, ed è una traduzione che confonde, perché la stessa parola in WordPress indica anche gli articoli in evidenza in home page — qui non c’entra niente. L’editor stesso lo spiega bene: «Il blocco rimarrà nella parte superiore della finestra invece di scorrere».

Il controllo è arrivato con WordPress 6.2, del marzo 2023, e ha un limite dichiarato: vale per i blocchi Gruppo di primo livello. Se annidi il tuo Gruppo dentro un altro Gruppo — cosa che capita facilmente, perché molti temi avvolgono l’header in un contenitore — la voce Posizione non compare. Se non la trovi, il problema è quasi sempre questo: sposta il Gruppo fuori, al livello più esterno della parte del template.

La scelta ha anche un effetto sulla stabilità del layout, ed è il primo dei quattro punti dell’ultima sezione.

Colori e caratteri si impostano dalle stesse opzioni degli altri blocchi, e se il tema è ben fatto pescano dalla tavolozza definita nel suo theme.json — il file che centralizza gli stili globali, di cui ho parlato nella guida alla preparazione di un tema. Usare i colori della tavolozza invece di scriverne uno a mano significa che la barra resterà coerente anche se cambi la palette del sito.

Tema classico: dove si aggancia, e perché il codice non va nel child theme

In un tema classico l’intestazione è header.php, un file PHP che appartiene al tema. Toccarlo direttamente significa perdere la modifica al primo aggiornamento, ed è esattamente il problema che il child theme risolve. Ma prima di crearne uno conviene verificare una cosa, perché nella maggior parte dei casi rende il child theme inutile.

Il gancio si chiama wp_body_open

WordPress mette a disposizione un punto di aggancio che scatta subito dopo l’apertura del tag <body>, introdotto nella versione 5.2. È il posto naturale per una barra che deve stare sopra a tutto, ed è dove finiscono anche altre cose che conosci, come il frammento noscript di Google Tag Manager. Ne ho parlato descrivendo cosa va davvero dentro header.php.

Qui però c’è una differenza fra le due famiglie di temi che quasi nessuna guida distingue, e vale la pena essere precisi. Nei temi a blocchi il gancio scatta sempre: lo chiama il core, nel file che disegna la pagina, prima di tutto il resto del modello. Nei temi classici deve chiamarlo il tema, dentro il suo header.php — e i temi scritti prima del 2019, o scritti male dopo, non lo fanno.

Verificarlo costa un comando, da lanciare nella cartella di WordPress:

grep -rn "wp_body_open" wp-content/themes/nome-del-tuo-tema/

Se ottieni una riga come header.php:40: wp_body_open(); sei a posto e puoi saltare il child theme. Se non ottieni niente, il gancio non c’è e il tema va integrato: è l’unico caso di questa guida in cui il child theme serve davvero, e lo vediamo fra due paragrafi.

Con il gancio disponibile, la barra è una funzione di una decina di righe. Il posto dove metterla non è il child theme: è un plugin. La regola l’ho scritta nella guida al tema figlio e vale identica qui — se una cosa deve sopravvivere al cambio di tema, il suo posto è un plugin, non un tema. Una barra che annuncia la chiusura estiva è contenuto del sito, non aspetto del tema: il giorno in cui cambi tema, l’avviso deve restare.

Crea un file barra-avviso.php in wp-content/plugins/ e attivalo da Plugin. In alternativa, se preferisci che non sia disattivabile per sbaglio, lo stesso file va in wp-content/mu-plugins/ e si attiva da solo.

<?php
/**
 * Plugin Name: Barra di avviso
 * Description: Stampa in cima al sito una barra di avviso.
 * Version:     1.0.0
 */

defined( 'ABSPATH' ) || exit;

add_action( 'wp_body_open', 'aa_barra_stampa' );

function aa_barra_stampa() {
	?>
<div class="aa-barra">
	<p class="aa-barra__testo">
		Spedizioni sospese dal 10 al 20 settembre.
		<a href="<?php echo esc_url( home_url( '/contatti/' ) ); ?>">Scrivici</a>
	</p>
</div>
	<?php
}

Due note su questo codice. esc_url() e home_url() servono a non scrivere a mano un indirizzo che cambierebbe in ambiente di staging. E il messaggio è nel PHP, quindi per cambiarlo devi modificare il file: se la barra la aggiorna qualcun altro, o cambia spesso, questa è la ragione per cui a un certo punto conviene un plugin vero — ne parlo nella sezione dopo.

Il caso in cui il child theme serve davvero

Se il grep non ha trovato niente, il tema non espone il gancio e non hai un punto in cui agganciarti. A quel punto le strade sono due: un plugin dedicato, che di solito ha modi alternativi di iniettarsi; oppure il child theme, dove copi header.php dal tema padre e aggiungi la chiamata mancante subito dopo il tag <body>.

Il secondo è il caso previsto dalla guida al child theme, ma con una precisazione che fa la differenza: nel child theme copi solo header.php, e dentro ci metti soltanto wp_body_open(). La barra resta nel plugin. Così, se un giorno cambi tema con uno che il gancio ce l’ha, butti via il child theme e la barra continua a funzionare senza che tu tocchi niente. Il contrario — barra dentro il child theme — ti obbliga a rifare il lavoro a ogni cambio di tema, ed è il motivo per cui trovi tante guide che finiscono con «e poi ricordati di rimetterlo».

Un tema che nel 2026 non chiama wp_body_open() è comunque un segnale: quel gancio è arrivato con la 5.2 del maggio 2019, e da allora sono uscite una ventina di release maggiori. Non averlo significa che il tema non viene aggiornato da un pezzo.

Con un plugin: quando conviene, e le tre righe da guardare prima

Le due strade precedenti hanno un limite comune: il messaggio lo cambia chi sa dove metterci le mani. Un plugin dedicato serve quando la barra smette di essere una cosa e diventa un processo — quando va programmata per accendersi e spegnersi da sola in date decise prima, quando ne servono di diverse su pagine diverse, quando il testo lo aggiorna una persona del marketing che nell’editor del sito non deve entrare, o quando vuoi sapere quanti hanno cliccato.

Se invece ti serve una riga fissa per tre settimane, un plugin è una dipendenza in più a fronte di dieci righe risparmiate, e vale il ragionamento generale su come si valuta un plugin prima di installarlo.

Il criterio per scegliere è lo stesso di sempre e sta in tre righe della scheda sul repository: ultimo aggiornamento, testato fino alla versione, e la presenza dell’avviso in cima che WordPress.org mostra quando un plugin non viene testato da tre release maggiori. Sono trenta secondi e dicono più di qualsiasi classifica.

Ecco i numeri dei più diffusi della categoria, rilevati il 3 settembre 2026 — vanno riletti alla data in cui leggi, non presi come verdetto:

PluginInstallazioni attiveUltimo aggiornamentoTestato fino a
My Sticky Bar100.0002 set 20267.1
WPFront Notification Bar50.00018 ago 20267.1
Simple Banner50.00021 ago 20267.1
Announcer10.0003 ago 20267.0.4
Easy Notification Bar9.00010 mar 20266.9.7

Una cosa che vale la pena notare, perché va al contrario di quello che succede spesso: qui i più installati sono anche i più aggiornati. Nella categoria dei plugin per creare child theme è l’opposto — il più diffuso è fermo da più di un anno — e chi si affida al numero di installazioni finisce sullo strumento peggiore. In questa, il numero e la manutenzione vanno d’accordo, e l’unico che resta indietro è anche il meno installato dei cinque.

Qualunque plugin tu scelga, i quattro controlli della prossima sezione valgono lo stesso: un plugin può sbagliare l’accessibilità e la stabilità del layout come le sbaglieresti tu, con la differenza che nel tuo codice le puoi correggere.

La barra che si chiude: è la cache di pagina a decidere come

Una barra che non si può chiudere è una barra che il visitatore impara a ignorare. Aggiungere il pulsante sembra la parte facile, e l’istinto di chi conosce WordPress è di risolverla in PHP: metto un cookie quando la chiudono, e a ogni caricamento controllo il cookie prima di stampare la barra. Sei righe.

Su un sito con la cache di pagina attiva, quelle sei righe non funzionano. E i siti con la cache di pagina attiva sono la maggioranza.

Perché il PHP non basta

La documentazione ufficiale di W3 Total Cache descrive la cache di pagina come la creazione di «istantanee statiche di pagine già interamente generate», conservate e servite alle richieste successive — e chiarisce che la consegna avviene «senza bisogno di elaborare il codice PHP». È la stessa cosa che fa qualsiasi altro sistema equivalente, compresi quelli integrati negli hosting gestiti.

La conseguenza è secca: il tuo if gira una volta sola, quando la pagina viene generata, e il suo risultato viene fotografato e consegnato a tutti quelli che arrivano dopo. Se la fotografia è stata scattata da un visitatore che aveva chiuso la barra, nessuno la vede più; se è stata scattata da uno che non l’aveva chiusa, non sparisce a nessuno. In entrambi i casi il pulsante sembra rotto, e il primo sospetto — «sarà la cache da svuotare» — porta fuori strada, perché il problema non è una cache vecchia: è che quella decisione lì dentro non ci può stare.

Escludere il sito dalla cache per far girare un if è uno scambio pessimo, e le opzioni che sembrano fatte apposta — «Non mettere in cache le pagine seguenti», «Non mettere in cache le pagine per gli utenti loggati» — servono ad altro: la prima al carrello e al checkout, la seconda a chi è dentro la bacheca. Il quadro d’insieme è nella guida a caching e minificazione, e il confronto fra i due plugin più diffusi dice quale imposta cosa.

La regola generale, che vale ben oltre le barre di avviso: tutto ciò che cambia da visitatore a visitatore va deciso nel browser, non nel PHP. La barra si stampa sempre, uguale per tutti — così l’HTML è cacheabile — e a nasconderla ci pensa il browser di chi l’ha chiusa.

C’è un dettaglio che distingue l’implementazione fatta bene da quella fatta in fretta. Se il JavaScript nasconde la barra dopo che la pagina è stata disegnata, chi l’aveva chiusa la vede comparire e sparire a ogni visita: fastidioso, e per giunta è uno spostamento del layout. La soluzione è la stessa che si usa per il tema scuro — un frammento minuscolo nell’head che decide prima del primo disegno, mettendo una classe sull’elemento <html>, e il CSS fa il resto.

Aggiungi questo al plugin della sezione precedente, e nel markup della barra il pulsante di chiusura:

<?php
/**
 * Identificativo dell'avviso in corso. Cambialo quando ne pubblichi
 * uno nuovo: chi aveva chiuso il precedente tornerà a vedere la barra.
 */
function aa_barra_id() {
	return 'avviso-2026-09';
}

/**
 * Nasconde la barra prima del primo disegno, se il visitatore
 * l'aveva già chiusa. Deve stare nell'head: più in basso, la barra
 * farebbe in tempo a comparire e sparire.
 */
add_action( 'wp_head', 'aa_barra_stato', 1 );

function aa_barra_stato() {
	?>
<script>
( function () {
	try {
		if ( window.localStorage.getItem( 'aa-barra' ) === <?php echo wp_json_encode( aa_barra_id() ); ?> ) {
			document.documentElement.classList.add( 'aa-barra-chiusa' );
		}
	} catch ( e ) {}
} )();
</script>
	<?php
}

add_action( 'wp_footer', 'aa_barra_chiusura' );

function aa_barra_chiusura() {
	?>
<script>
document.addEventListener( 'click', function ( event ) {
	var chiudi = event.target.closest && event.target.closest( '.aa-barra__chiudi' );
	if ( ! chiudi ) {
		return;
	}
	document.documentElement.classList.add( 'aa-barra-chiusa' );
	try {
		window.localStorage.setItem( 'aa-barra', <?php echo wp_json_encode( aa_barra_id() ); ?> );
	} catch ( e ) {}
} );
</script>
	<?php
}

L’identificativo dell’avviso è la parte che ripaga nel tempo. Il browser non memorizza «ha chiuso la barra», memorizza quale barra ha chiuso: il giorno in cui pubblichi l’avviso successivo cambi la stringa in aa_barra_id(), e tutti tornano a vederla senza che tu debba chiedere a nessuno di svuotare niente. Senza quell’accorgimento, chi ha chiuso la barra a settembre non vedrà mai più un tuo avviso.

I due try non sono decorazione: localStorage solleva un’eccezione, invece di restituire vuoto, quando il browser ha le impostazioni sui dati dei siti più restrittive. Senza la protezione, in quei browser si romperebbe lo script e con lui tutto quello che gira dopo.

I quattro errori che rompono la pagina

I quattro modi in cui una barra peggiora il sito su cui è stata messa. Tre su quattro non si vedono guardando lo schermo: si vedono con la tastiera, o con uno strumento che misura.

1. Il layout sussulta al caricamento

È l’errore delle barre iniettate via JavaScript dopo il caricamento: la pagina si disegna, poi la barra si infila in cima e spinge tutto il resto verso il basso, di solito nell’istante in cui il visitatore sta premendo un pulsante. Sono i «banner cookie, alert e annunci inseriti dinamicamente» che ho elencato fra le cause di un layout che si muove, e pesano sul CLS.

Le tre strade di questa guida non hanno il problema, perché in tutte e tre la barra è nell’HTML fin dall’inizio. Il rimedio, se usi un plugin che la inietta, è riservarle lo spazio con un contenitore di altezza fissa. E position: sticky è la scelta giusta anche qui: a differenza di fixed, lascia il blocco nel flusso della pagina, quindi lo spazio che occupa resta occupato e non c’è niente da riservare a mano.

2. Il focus finisce sotto la barra

Questo è il più diffuso e il meno conosciuto. Chi naviga con il tasto Tab arriva a un link a metà pagina, il browser scorre per portarlo in vista allineandolo al bordo superiore della finestra — e lì c’è la tua barra. L’elemento a fuoco resta nascosto sotto, e chi sta tabulando non ha modo di sapere dove si trova.

Non è un’opinione sull’usabilità, è un criterio: 2.4.11 Focus Not Obscured (Minimum), livello AA delle WCAG 2.2, che chiede che un componente a fuoco non sia interamente nascosto da contenuto messo lì da chi ha fatto il sito. La pagina di spiegazione del W3C nomina proprio gli header appiccicati in alto e i banner dei cookie come i casi tipici.

La correzione è una riga di CSS, ed è la stessa che consiglio per gli header fissi nella guida all’accessibilità da tastiera: si dichiara al browser quanto spazio è occupato in cima con scroll-padding-top sull’elemento radice. Con la barra alta 44 pixel e senza quella riga, nella mia prova il link a fuoco atterrava a 35 pixel dal bordo — cioè sotto la barra; con la riga, atterra esatto a 44, appena sotto il bordo inferiore. Attenzione a un caso frequente: se il tema ha già un header appiccicato, il valore da dichiarare è la somma delle due altezze, non solo quella della barra.

3. Il pulsante di chiusura è troppo piccolo

La «×» di chiusura è quasi sempre un carattere tipografico senza dimensioni proprie, e finisce a occupare un’area di dodici o quattordici pixel di lato. Su un telefono è un bersaglio che si manca, e il visitatore che prova due volte a chiudere la barra e non ci riesce fa la cosa peggiore per te: se ne va.

Anche qui c’è un numero: 2.5.8 Target Size (Minimum), livello AA, chiede almeno 24 × 24 pixel CSS, salvo cinque eccezioni fra cui i bersagli dentro una riga di testo. Un pulsante di chiusura non è dentro una riga di testo: le eccezioni non lo coprono. È uno dei controlli dell’audit di accessibilità in ventiquattro punti, e la chiusura dei banner è il punto in cui casca più spesso.

4. La barra è marcata come «alert»

Il nome inglese del componente porta fuori strada: siccome si chiama alert bar, sembra logico scrivere role="alert" nel markup. È sbagliato due volte.

La prima: nella specifica del W3C il ruolo alert è «un tipo di regione dinamica con informazioni importanti, e di solito urgenti». Un annuncio commerciale non lo è, e le linee guida sui modelli di interazione avvertono che le interruzioni frequenti peggiorano l’usabilità per chi ha disabilità visive o cognitive. La seconda, che chiude la questione: le stesse linee guida scrivono che gli screen reader non annunciano gli alert già presenti nella pagina prima che il caricamento sia completo. Una barra che sta nell’HTML dall’inizio ricade esattamente in quel caso: quel ruolo, oltre che scorretto, non fa proprio niente.

Cosa scriverci, allora: niente. Un contenitore normale con dentro del testo si legge già benissimo. L’unico attributo che serve davvero è quello sul pulsante — un aria-label che dica cosa fa, perché una «×» da sola non lo dice. E una nota sul contenitore: non usare un secondo <header>. Un <header> che non sia annidato dentro un articolo, una sezione o un elemento di navigazione diventa il punto di riferimento banner della pagina, e averne due significa che chi naviga per punti di riferimento ne trova due dove ne dovrebbe trovare uno. Un <div> va benissimo.

Questo è il CSS che tiene insieme i quattro punti, da mettere nel foglio di stile del tema o nel CSS aggiuntivo:

:root {
	--aa-barra-h: 44px;
	/* Il focus non deve finire sotto la barra: criterio 2.4.11 delle WCAG 2.2. */
	scroll-padding-top: var(--aa-barra-h);
}

.aa-barra {
	position: sticky;
	top: 0;
	z-index: 100;
	box-sizing: border-box;
	display: flex;
	align-items: center;
	justify-content: center;
	gap: 1rem;
	min-height: var(--aa-barra-h);
	padding: 0.5rem 1rem;
	background: #1d2327;
	color: #fff;
}

.aa-barra__testo {
	margin: 0;
}

/* 24 × 24 CSS pixel è il minimo del criterio 2.5.8 delle WCAG 2.2. */
.aa-barra__chiudi {
	display: grid;
	place-items: center;
	min-width: 24px;
	min-height: 24px;
	border: 0;
	background: none;
	color: inherit;
	font-size: 1.25rem;
	line-height: 1;
	cursor: pointer;
}

.aa-barra-chiusa .aa-barra {
	display: none;
}

.aa-barra-chiusa {
	scroll-padding-top: 0;
}

Quando la barra non serve

Prima di metterla, tre casi in cui la risposta onesta è che non è lo strumento giusto.

  • Il messaggio riguarda una pagina sola. Un avviso sulle spedizioni ha senso sul prodotto e sul carrello, non nell’articolo del blog letto da chi arriva da una ricerca. Su WooCommerce ci sono strumenti che mostrano avvisi contestuali dentro il carrello, e ne ho parlato fra i plugin da integrare in un negozio: un avviso mirato viene letto, uno globale diventa arredamento.
  • Il messaggio è permanente. «Spedizione gratuita sopra i 50 €» non è un avviso, è una promessa commerciale stabile: il suo posto è nel disegno dell’intestazione, non in una barra che finge di essere temporanea e non lo è.
  • Le cose da dire sono tre. Una barra regge una frase e un link. Al secondo messaggio diventa un carosello, e un carosello in cima al sito è la cosa che i visitatori imparano a saltare più in fretta di qualsiasi altra.

E una volta messa, va tolta. L’avviso di chiusura estiva ancora online a novembre dice del sito più di quanto direbbe la sua assenza: vale la pena metterlo fra i controlli ricorrenti di manutenzione, insieme alle altre cose che scadono senza avvisare.

Domande frequenti

Posso mostrare la barra solo su alcune pagine?

Sì, ed è uno dei pochi casi in cui la condizione in PHP funziona anche con la cache attiva. Il motivo è che la cache conserva una copia per indirizzo: una condizione che dipende solo da quale pagina si sta guardando dà lo stesso risultato per tutti i visitatori di quell’indirizzo, quindi la fotografia è corretta. Nel plugin basta racchiudere la stampa in un controllo sul tipo di pagina. È diverso dalla chiusura, che dipende dalla persona e non dall’indirizzo: quella nel PHP non ci può stare.

Una barra di avviso rallenta il sito?

Nelle tre strade di questa guida no, in modo misurabile: è qualche riga di HTML e, dove c’è la chiusura, due frammenti di JavaScript che non caricano file esterni. Quello che rallenta è la versione adottata da molti plugin: una libreria JavaScript caricata su tutte le pagine per disegnare un rettangolo con dentro una frase. Valutando un plugin, guarda quante richieste aggiunge a una pagina in cui la barra nemmeno compare.

Come la faccio comparire e sparire in date decise?

Con un controllo sulla data prima di stampare la barra, oppure con un plugin che offre la programmazione dall’interfaccia. In entrambi i casi c’è un’avvertenza che riguarda la cache: la condizione viene valutata quando la pagina viene generata, quindi la barra non compare e non sparisce all’istante esatto, ma quando la copia in cache viene rigenerata. Se la data è un impegno preciso con i clienti, svuota la cache subito dopo il momento in cui deve cambiare.

Posso metterne più di una?

Tecnicamente sì, e quasi sempre è il segnale che la barra non è più lo strumento adatto. Due barre sovrapposte raddoppiano lo spazio sottratto al contenuto, raddoppiano il valore da dichiarare in scroll-padding-top, e obbligano a gestire due stati di chiusura indipendenti. Se hai due cose importanti da dire nello stesso momento, di solito la seconda merita una pagina.

Va bene usarla come banner dei cookie?

No, e non è una questione di aspetto. Un banner di consenso deve bloccare gli script prima che partano, registrare la scelta in modo dimostrabile e permettere di cambiarla dopo: sono comportamenti che una barra informativa non ha e che non si aggiungono con qualche riga. Le due cose si somigliano solo perché stanno nello stesso posto dello schermo. Se sul sito ci sono entrambe, tieni presente che si sommano in altezza, con tutto quello che ne consegue per il focus.

Ho un tema a blocchi ma non trovo «Parti del template»

La voce sta in Aspetto → Editor → Pattern, in fondo alla colonna di sinistra, e non nel primo livello del menu: è il punto in cui si arenano quasi tutti la prima volta. Se in Aspetto non compare proprio la voce Editor, allora il tema non è a blocchi, e la strada giusta è quella del tema classico. Se compaiono sia Editor sia Personalizza, il tema è a blocchi ma un plugin sta tenendo aperto il vecchio pannello di personalizzazione: per la barra, usa l’Editor.

Se ti serve una mano

Le tre strade qui sopra coprono la quasi totalità dei casi, e in tutte e tre la parte difficile non è scrivere la barra: è capire in quale dei tre casi ti trovi, e accorgersi dei quattro problemi prima che li segnali qualcun altro. Se il tema è ostico, se la barra c’è già e fa una delle quattro cose sbagliate, o se il sito è in cache e il pulsante di chiusura si comporta in modo che non torna, me ne occupo io: puoi vedere come lavoro nella pagina sullo sviluppo di temi e plugin WordPress su misura, oppure scrivermi e guardiamo insieme il caso specifico.

Indice dei contenuti

  • Prima di scegliere il metodo: che tema hai
  • Tema a blocchi: si fa dall’editor, senza codice e senza plugin
  • Tema classico: dove si aggancia, e perché il codice non va nel child theme
  • Con un plugin: quando conviene, e le tre righe da guardare prima
  • La barra che si chiude: è la cache di pagina a decidere come
  • I quattro errori che rompono la pagina
  • Quando la barra non serve
  • Domande frequenti
  • Se ti serve una mano

Tag in Evidenza

AccessibilitàEditor a blocchiPlugin WordPressTemaTemi WordPressWordPress

Condividi


Lascia un commento Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Alessandro Aili - WordPress Developer Alessandro Aili - WordPress Developer
Sono un WordPress developer che affronta tutte le tue sfide online.
Skills
  • Sviluppo di Siti Web Personalizzati
  • Ottimizzazione delle Prestazioni
  • Sicurezza del Sito Web
  • Aggiornamenti e Manutenzione
  • Sviluppo di Temi e Plugin Personalizzati
  • Migrazione e Trasferimento del Sito
© Copyright 2026 Alessandro Aili
  • Mappa del sito
  • Privacy Policy
  • Cookie Policy
  • Preferenze cookie
Alessandro Aili - WordPress Developer