Gestisci i reindirizzamenti URL con WebBlocks Redirect Manager

Per l'installazione usa un sito di prova e un account Super admin. Il catalogo ufficiale dichiara Redirect Manager 0.1.28 compatibile con CMS ^1.100.0, PHP ^8.3 e Laravel ^13.0. La tua versione del CMS può imporre requisiti aggiuntivi; questa guida usa PHP 8.4. Controlla l'esito di compatibilità del server nel catalogo ufficiale di Redirect Manager.

Prepara e pubblica prima la pagina di destinazione. Nel nostro esempio, /workshops si apre già correttamente. Il plugin invia una risposta di reindirizzamento; non crea la destinazione, non pubblica una bozza, non aggiorna i collegamenti esistenti e non verifica la disponibilità di un sito remoto.

Prima di salvare, individua il vecchio percorso, la destinazione desiderata e il sito o dominio a cui appartiene il collegamento. Per una normale modifica in un singolo sito usa l'ambito sito. Una regola globale riguarda le richieste corrispondenti nell'intera installazione; sceglila solo se desideri questo comportamento esteso.

1. Apri System → Plugins come Super admin.
2. Usa Browse Plugin Catalog per trovare WebBlocks Redirect Manager.
3. Controlla versione, note e compatibilità, quindi scegli Install from Catalog.
4. Se l'amministratore fornisce l'archivio ufficiale pubblicato, selezionalo in Plugin ZIP e premi Upload Plugin ZIP.
5. Esamina il pacchetto installato prima di abilitarlo.

Il nostro esempio usa lo ZIP ufficiale pubblicato. Un plugin appena installato è Disabled. Il CMS attuale applica le modifiche al database durante il normale ciclo di installazione e abilitazione.

Apri i dettagli di WebBlocks Redirect Manager e scegli Enable Plugin. Verifica gli stati Enabled, archiviazione Healthy e Migrations Up to Date. Un'installazione sana indica che l'archiviazione dei reindirizzamenti è pronta e l'elaborazione pubblica è attiva.

Apri Maintenance → Redirects. In una nuova installazione l'elenco mostra No redirects have been created yet. L'azione Create redirect apre il modulo della regola.

Se il menu non appare subito dopo l'abilitazione, ricarica il pannello. Se l'archiviazione non è pronta, risolvi l'aggiornamento del database o l'avviso di compatibilità prima di creare una regola.

Redirect Manager separa la lettura dell'elenco dalla modifica delle regole:

Chi gestisce le regole in genere necessita di entrambe le autorizzazioni. Installazione e ciclo di vita del plugin rimangono compiti amministrativi. Usa la guida Ruoli e autorizzazioni per assegnare l'accesso appropriato al team.

L'elenco del pannello comprende tutte le regole dell'installazione. Applies to stabilisce quali richieste pubbliche corrispondono alla regola; non limita quali regole un operatore può vedere o gestire. Considera l'autorizzazione di gestione come potere di modificare i reindirizzamenti in tutta l'installazione. Le restrizioni di sito della Internal API sono un controllo di integrazione separato.

Scegli Create redirect e inserisci questi valori:

Inizialmente il modulo seleziona All sites and domains, 301 permanent e Enabled. Per questo esempio modifica consapevolmente i valori predefiniti. Una regola non ha un passaggio di pubblicazione separato: salvare una regola attiva modifica il reindirizzamento pubblico non appena la richiesta raggiunge il plugin.

Premi Create redirect. Il messaggio di riuscita conferma la registrazione; la nuova riga mostra ambito, origine, destinazione, stato, attivazione, Hits e Last hit. Una nuova regola inizia con zero accessi e un trattino come ora dell'ultimo accesso.

Per preparare una regola senza attivarla, deseleziona Enabled prima di salvare. Potrai abilitarla dopo avere controllato origine, ambito e destinazione.

Apri il vecchio URL pubblico sul dominio reale del sito. Nel nostro esempio, visitare /old-workshops porta a /workshops, dove la nuova pagina si apre normalmente. Controlla anche l'indirizzo nel browser, non soltanto il contenuto: vedere la destinazione non rivela se la risposta fosse 301 o 302.

Torna in Maintenance → Redirects e aggiorna l'elenco. L'esempio mostra ora 1 accesso e un valore in Last hit. Si tratta di una richiesta reale passata attraverso il reindirizzamento, non di un contatore inserito manualmente.

Per verificare la risposta esatta, usa il pannello Network del browser o un client HTTP che invii la richiesta al tuo sito. Una richiesta HEAD consente di esaminare le intestazioni senza scaricare la pagina di destinazione:

Sostituisci il nome host di esempio con il tuo. Per la regola precedente attenditi 302 e un'intestazione Location che indica /workshops. Il comando non segue il reindirizzamento. Controlla anche la destinazione separatamente per confermare che restituisca la pagina desiderata.

Sia le richieste GET sia quelle HEAD vengono conteggiate. Monitor, bot del browser e test ripetuti possono aumentare il totale. Gli accessi sono corrispondenze arrivate all'applicazione; non indicano persone uniche, visite riuscite alla destinazione o conversioni completate.

Il selettore Applies to offre tre tipi di ambito. Le opzioni sito e dominio derivano dai record del CMS. Se manca un dominio, configura prima i domini attivi del sito interessato; il modulo non registra un nuovo nome host. Consulta Più siti.

Una regola globale funge da ripiego comune per il percorso corrispondente nell'intera installazione. In questo caso /programme porta a /contact quando non prevale una regola attiva più specifica.

Una regola di sito corrisponde ai domini attivi registrati del sito. La nostra regola di sito per /programme porta a /workshops e precede la regola globale sui domini di Northstar Studio.

Questo ambito segue i record dei domini attivi del sito. Riesamina il reindirizzamento quando un dominio viene aggiunto, rimosso o disattivato. Un nome host sconosciuto non eredita le regole del sito soltanto perché quel sito è il predefinito dell'installazione.

Una regola di dominio corrisponde solo al nome host selezionato. La nostra eccezione per events.example.test invia /programme a /summer-workshops. studio.example.test, la variante www e gli altri sottodomini non sono inclusi automaticamente.

Le tre regole possono coesistere perché il percorso di origine deve essere univoco nel proprio ambito, non tra tutti gli ambiti dell'installazione.

Le regole attive che corrispondono allo stesso percorso vengono valutate in quest'ordine:

1. Dominio esatto.
2. Sito associato al nome host in ingresso.
3. Tutti i siti e domini.

Le tre regole di esempio per /programme producono questo risultato:

L'ultima riga descrive la corrispondenza del plugin dopo che la richiesta raggiunge il CMS; non configura il DNS e non fa sì che un nome non registrato serva il sito. Le impostazioni di hosting, dominio e dominio principale restano valide.

Dopo avere provato i nomi host pertinenti, i contatori separati mostrano quali regole hanno elaborato le richieste. Disattivare una regola più specifica può far intervenire la regola attiva più ampia. Controlla i ripieghi di sito e globale prima di disattivare un'eccezione di dominio.

Prova il nome host pubblico esatto, inclusi alias e comportamento del dominio principale nel tuo ambiente. Il server web, la CDN o un reindirizzamento a livello di dominio può rispondere prima che la richiesta raggiunga Redirect Manager.

Source path è un percorso interno, non un URL completo. Inserisci /old-workshops, non https://your-site.example/old-workshops. Il plugin normalizza la barra iniziale mancante e quelle finali; old-workshops, /old-workshops e /old-workshops/ indicano la stessa origine.

Dopo la normalizzazione la corrispondenza è esatta. Una regola per /old-workshops non corrisponde a /old-workshops/photography. Il modulo non offre caratteri jolly, espressioni regolari, sostituzione di prefissi o trasferimento automatico dei suffissi. Mantieni coerente l'uso delle maiuscole; il nostro server non ha associato /OLD-WORKSHOPS all'esempio minuscolo.

I parametri di query in ingresso vengono ignorati nella corrispondenza. /old-workshops e /old-workshops?utm_source=newsletter attivano la stessa regola. La query in ingresso non viene copiata automaticamente nella destinazione. Se serve una query fissa, aggiungila direttamente a Target URL, per esempio /workshops?from=legacy.

La destinazione può essere un percorso relativo alla radice come /workshops o un URL http/https completo come https://destination.example/workshops. Una destinazione relativa mantiene il nome host in ingresso; usa un URL completo per passare a un altro dominio. Le destinazioni relative allo schema come //destination.example/workshops vengono rifiutate. I frammenti URL sono gestiti dal browser e non distinguono le regole di origine.

Non usare il plugin per reindirizzare invii di moduli o scritture API. Esamina le richieste pubbliche GET e HEAD; gli altri metodi proseguono nell'applicazione server. Ignora anche gli spazi riservati /admin, /api, /webadmin, /cms, /storage, /assets, /static, /build, /vendor e /webblocks-ui e i relativi sottopercorsi. I file serviti direttamente dal server web potrebbero non entrare mai nel reindirizzamento CMS.

Una regola attiva può sostituire una pagina pubblica esistente sullo stesso percorso. Prima di salvare, conferma di voler rimuovere la vecchia pagina dalla navigazione normale. Redirect Manager non richiede che la pagina di origine restituisca prima un 404.

Se crei due volte la stessa origine normalizzata nello stesso ambito, il modulo mostra The source path has already been taken. Modifica la regola esistente. Anche una regola disattivata occupa l'origine in quell'ambito.

Il plugin rifiuta un reindirizzamento interno diretto a se stesso. /loop-check non può portare a /loop-check?from=legacy; la query non cambia il percorso di base. L'errore indica The target must not redirect this path back to itself.

La protezione dai cicli diretti non sostituisce l'esame dell'intera catena. Evita di combinare /a → /b con /b → /a, oppure reindirizzamenti tra domini che un altro sistema rimanda indietro. Invia i vecchi indirizzi direttamente alla destinazione finale e prova l'intera catena.

Per spostare una home page, inserisci / come origine e scegli un ambito sito o dominio. Una regola globale attiva per la home viene rifiutata con Choose a site or domain for a homepage redirect., impedendo a una regola radice globale di acquisire tutte le home page.

Esamina attentamente le destinazioni della home: una destinazione relativa resta sul dominio attuale. Preferisci l'ambito più ristretto e verifica che la destinazione non abbia una regola che riporti il visitatore a /.

Usa 302 temporary mentre controlli origine, nome host, destinazione e contatore. Se lo spostamento sarà permanente e i test sono riusciti:

1. Trova la regola in Maintenance → Redirects.
2. Usa l'azione con la matita Edit redirect.
3. Controlla Applies to, Source path e Target URL.
4. Imposta Status code su 301 permanent.
5. Lascia selezionato Enabled e premi Save changes.

L'elenco mostra ora 301 e un promemoria sulla cache del browser. La modifica conserva il conteggio esistente e la cronologia dell'ultimo accesso.

I browser possono memorizzare un reindirizzamento 301 e riutilizzarlo senza raggiungere il CMS. Una destinazione modificata può quindi sembrare invariata e il nuovo accesso non viene registrato. Verifica con un client HTTP che effettui una nuova richiesta oppure disattiva la cache negli strumenti di rete del browser. Disabilitare la regola non richiama le risposte già memorizzate dal client o dai livelli superiori.

Per fermare il reindirizzamento conservando configurazione e cronologia, modifica la regola, deseleziona Enabled e premi Save changes.

La riga resta nell'elenco come Disabled. Le nuove richieste non usano più la regola e il contatore non cresce. Se non esistono un'altra regola di ambito attiva o un altro livello di reindirizzamento, il server restituisce la pagina normale o un 404. Nell'esempio, il vecchio indirizzo inutilizzato restituisce 404 dopo la disattivazione.

Per riattivarlo modifica la stessa riga, seleziona Enabled, verifica la destinazione e salva. Eviterai un'origine duplicata e conserverai la cronologia della regola.

L'azione cestino Delete redirect elimina la regola e la cronologia degli accessi. Nella 0.1.28 viene eseguita direttamente; il plugin non dispone di cestino o schermata di ripristino. Registra i dati necessari prima di eliminare e usa Disabled per una pausa reversibile.

Disabilitare l'intero plugin da System → Plugins arresta l'elaborazione e nasconde i suoi contributi. Il ciclo di vita attuale conserva le tabelle del plugin. È un'azione più ampia della disattivazione di una singola regola e non svuota le cache di browser o CDN.

Redirect Manager 0.1.28 offre regole singole, due codici di stato, selezione dell'ambito e cronologia aggregata degli accessi. Non aggiunge blocchi al page builder: quando è attivo, elabora direttamente le richieste pubbliche corrispondenti.

Il pannello non offre regole programmate, importazione/esportazione CSV di massa, caratteri jolly, analisi per visitatore o rilevamento automatico dei collegamenti interrotti. Pianifica queste esigenze separatamente invece di inserire modelli non supportati in Source path. Questa versione non dispone neppure di un'azione per azzerare il contatore.

Se cambi l'indirizzo di una pagina nel CMS, controlla personalmente il vecchio URL. Rinominare una pagina non aggiunge automaticamente una regola all'elenco del plugin. Aggiorna navigazione e collegamenti interni all'indirizzo finale; mantieni reindirizzamenti consapevoli per segnalibri esterni e collegamenti che non puoi modificare. Consulta Modificare l'indirizzo di una pagina.

Per l'automazione, il plugin espone la raccolta di regole tramite la Internal Content API in /webadmin/api/redirect-manager/redirects. La lettura usa plugins.read; la scrittura usa plugins.manage e le relative restrizioni di sito. Usa il rilevamento API del CMS per esaminare endpoint installati e contratto delle richieste. Gli utenti del pannello non necessitano di un token API per seguire questa guida.

Prima di attivare lo spostamento reale, verifica che la nuova pagina sia pubblicata e restituisca i contenuti corretti sull'host di destinazione. Inizia con 302; prova il vecchio indirizzo senza seguire il reindirizzamento per controllare stato e intestazione Location, quindi seguilo per verificare la pagina finale.

Controlla tutti i domini pertinenti, le regole di ambito più specifiche, le barre finali e le aspettative sulle query. Conferma che la destinazione non rimandi indietro e che i test GET/HEAD producano la variazione prevista del contatore. Passa a 301 solo quando lo spostamento permanente è definitivo.

Dopo il lancio aggiorna i collegamenti sotto il tuo controllo, documenta ambito e scopo della regola e controlla periodicamente i totali. Per una pausa, disattiva prima di eliminare. Otterrai così una procedura ripetibile che mantiene utilizzabili i vecchi URL e ti consente di controllare dove si applica ogni reindirizzamento.