Gérer les redirections URL avec WebBlocks Redirect Manager

Utilisez un site de test et un compte Super admin pour l'installation. Le catalogue officiel indique que Redirect Manager 0.1.28 est compatible avec CMS ^1.100.0, PHP ^8.3 et Laravel ^13.0. Votre version du CMS peut imposer des exigences supplémentaires ; ce guide fonctionne avec PHP 8.4. Vérifiez le résultat de compatibilité du serveur dans le catalogue officiel de Redirect Manager.

Préparez et publiez d'abord la page de destination. Dans notre exemple, /workshops s'ouvre déjà correctement. L'extension envoie une réponse de redirection ; elle ne crée pas la destination, ne publie pas un brouillon, ne met pas à jour les liens existants et ne vérifie pas la disponibilité d'un site distant.

Avant d'enregistrer, identifiez l'ancien chemin, la destination voulue et le site ou domaine auquel appartient l'ancien lien. Utilisez la portée site pour un changement courant sur un seul site web. Une règle globale affecte les requêtes correspondantes de toute l'installation ; ne la choisissez que si vous souhaitez ce comportement étendu.

1. Ouvrez System → Plugins en tant que Super admin.
2. Utilisez Browse Plugin Catalog pour trouver WebBlocks Redirect Manager.
3. Vérifiez la version, les notes et la compatibilité, puis choisissez Install from Catalog.
4. Si votre administrateur fournit l'archive officielle publiée, sélectionnez-la dans Plugin ZIP et cliquez sur Upload Plugin ZIP.
5. Examinez le paquet installé avant de l'activer.

Notre exemple utilise le ZIP officiel publié. Une extension nouvellement installée est Disabled. Le CMS actuel applique les modifications de base de données pendant le cycle normal d'installation et d'activation.

Ouvrez les détails de WebBlocks Redirect Manager et choisissez Enable Plugin. Confirmez les états Enabled, stockage Healthy et Migrations Up to Date. Une installation saine indique que le stockage des redirections est prêt et que le traitement public est actif.

Ouvrez Maintenance → Redirects. Sur une nouvelle installation, la liste affiche No redirects have been created yet. L'action Create redirect ouvre le formulaire de la règle.

Si le menu n'apparaît pas immédiatement après l'activation, rechargez l'administration. Si le stockage n'est pas prêt, résolvez la mise à jour de base de données ou l'avertissement de compatibilité avant de créer une règle.

Redirect Manager distingue la lecture de la liste de la modification des règles :

Un opérateur qui gère les règles a généralement besoin des deux autorisations. L'installation et le cycle de vie de l'extension restent des tâches administratives. Utilisez le guide Rôles et autorisations pour attribuer à votre équipe l'accès adapté.

La liste d'administration contient toutes les règles de l'installation. Applies to détermine quelles requêtes publiques correspondent à la règle ; il ne limite pas les règles qu'un opérateur peut voir ou gérer. Considérez l'autorisation de gestion comme le pouvoir de modifier les redirections dans toute l'installation. Les restrictions de site de l'Internal API constituent un contrôle d'intégration distinct.

Choisissez Create redirect et saisissez les valeurs suivantes :

Le formulaire sélectionne initialement All sites and domains, 301 permanent et Enabled. Modifiez volontairement ces valeurs par défaut pour cet exemple. Une règle n'a pas d'étape de publication séparée : l'enregistrement d'une règle active modifie la redirection publique dès que la requête atteint l'extension active.

Cliquez sur Create redirect. Le message de réussite confirme l'enregistrement ; la nouvelle ligne affiche la portée, la source, la destination, le statut, l'activation, Hits et Last hit. Une nouvelle règle commence avec zéro visite et un tiret comme heure de dernière visite.

Pour préparer une règle sans l'activer, décochez Enabled avant l'enregistrement. Vous pourrez l'activer après avoir vérifié la source, la portée et la destination.

Ouvrez l'ancienne URL publique sur le domaine réel du site. Dans notre exemple, la visite de /old-workshops conduit à /workshops, où la nouvelle page s'ouvre normalement. Vérifiez aussi l'adresse du navigateur, pas seulement le contenu : voir la destination n'indique pas si la réponse était 301 ou 302.

Retournez dans Maintenance → Redirects et actualisez la liste. L'exemple affiche maintenant 1 visite et une valeur dans Last hit. Il s'agit d'une requête réelle passée par la redirection, et non d'un compteur saisi manuellement.

Pour vérifier la réponse exacte, utilisez le panneau Network du navigateur ou un client HTTP qui envoie une requête à votre propre site. Une requête HEAD permet d'examiner les en-têtes sans télécharger la page de destination :

Remplacez le nom d'hôte d'exemple par le vôtre. Pour la règle ci-dessus, attendez-vous à un statut 302 et à un en-tête Location indiquant /workshops. La commande ne suit pas la redirection. Vérifiez également la destination séparément afin de confirmer qu'elle renvoie la page souhaitée.

Les requêtes GET et HEAD sont toutes deux comptabilisées. Les outils de surveillance, les robots et les tests répétés peuvent augmenter le total. Les visites sont des correspondances de redirection qui atteignent l'application ; elles ne représentent ni des personnes uniques, ni des visites réussies de la destination, ni des conversions achevées.

Le sélecteur Applies to propose trois types de portée. Les choix de site et de domaine proviennent des enregistrements du CMS. Si un domaine manque, configurez d'abord les domaines actifs du site concerné ; le formulaire n'enregistre pas un nouveau nom d'hôte. Consultez Plusieurs sites.

Une règle globale sert de solution de repli commune pour le chemin correspondant dans toute l'installation. Ici, /programme conduit à /contact lorsqu'aucune règle active plus précise ne l'emporte.

Une règle de site correspond aux domaines actifs enregistrés du site. Notre règle de site pour /programme conduit à /workshops et précède la règle globale sur les domaines de Northstar Studio.

Cette portée suit les enregistrements de domaines actifs du site. Réexaminez la redirection lorsqu'un domaine est ajouté, supprimé ou désactivé. Un nom d'hôte inconnu n'hérite pas des règles du site simplement parce que ce site est celui par défaut de l'installation.

Une règle de domaine ne correspond qu'au nom d'hôte sélectionné. Notre exception pour events.example.test envoie /programme vers /summer-workshops. studio.example.test, la variante www et les autres sous-domaines ne sont pas inclus automatiquement.

Ces trois règles peuvent coexister, car le chemin source doit être unique dans sa propre portée, et non entre toutes les portées de l'installation.

Les règles actives correspondant au même chemin source sont évaluées dans cet ordre :

1. Domaine exact.
2. Site associé au nom d'hôte entrant.
3. Tous les sites et domaines.

Les trois exemples pour /programme produisent le résultat suivant :

La dernière ligne décrit la correspondance de l'extension une fois la requête arrivée au CMS ; elle ne configure pas le DNS et ne permet pas à un nom non enregistré de servir votre site. Les paramètres d'hébergement, de domaine et de domaine principal restent applicables.

Après avoir testé les noms d'hôte concernés, les compteurs distincts indiquent quelles règles ont traité les requêtes. Désactiver une règle plus précise peut laisser agir la règle active plus large. Vérifiez les solutions de repli de site et globale avant de désactiver une exception de domaine.

Testez le nom d'hôte public exact, notamment les alias et le comportement du domaine principal de votre déploiement. Le serveur web, le CDN ou une redirection au niveau du domaine peut répondre avant que la requête atteigne Redirect Manager.

Source path est un chemin interne, pas une URL complète. Saisissez /old-workshops, et non https://your-site.example/old-workshops. L'extension normalise la barre oblique initiale manquante et les barres finales ; old-workshops, /old-workshops et /old-workshops/ représentent la même source.

Après normalisation, la correspondance est exacte. Une règle pour /old-workshops ne correspond pas à /old-workshops/photography. Le formulaire ne propose ni caractères génériques, ni expressions régulières, ni remplacement de préfixe, ni transfert automatique du suffixe. Utilisez une casse cohérente ; notre serveur de test n'a pas associé /OLD-WORKSHOPS à l'exemple en minuscules.

Les paramètres de requête entrants sont ignorés lors de la correspondance de la source. /old-workshops et /old-workshops?utm_source=newsletter activent la même règle. La chaîne de requête entrante n'est pas copiée automatiquement vers la destination. Si une requête fixe est nécessaire, ajoutez-la directement à Target URL, par exemple /workshops?from=legacy.

La destination peut être un chemin relatif à la racine comme /workshops ou une URL http/https complète comme https://destination.example/workshops. Une destination relative conserve le nom d'hôte entrant ; utilisez une URL complète pour changer de domaine. Les destinations relatives au schéma comme //destination.example/workshops sont refusées. Les fragments d'URL sont traités par le navigateur et ne peuvent pas distinguer les règles sources entrantes.

N'utilisez pas l'extension pour rediriger les envois de formulaires ou les écritures API. Elle examine les requêtes publiques GET et HEAD ; les autres méthodes poursuivent leur route dans l'application serveur. Elle ignore également les espaces réservés /admin, /api, /webadmin, /cms, /storage, /assets, /static, /build, /vendor et /webblocks-ui ainsi que leurs sous-chemins. Les fichiers servis directement par le serveur web peuvent ne jamais atteindre la redirection du CMS.

Une règle active peut remplacer une page publique existante sur le même chemin. Avant d'enregistrer, confirmez que vous souhaitez retirer l'ancienne page de la navigation normale. Redirect Manager n'exige pas que la page source renvoie d'abord un 404.

Si vous créez deux fois la même source normalisée dans une même portée, le formulaire affiche The source path has already been taken. Modifiez la règle existante. Une règle désactivée occupe elle aussi cette source dans la portée.

L'extension refuse une redirection interne qui pointe directement vers elle-même. /loop-check ne peut pas conduire à /loop-check?from=legacy ; la requête ne modifie pas le chemin de base. L'erreur indique The target must not redirect this path back to itself.

La protection contre les boucles directes ne remplace pas l'examen de toute la chaîne. Évitez d'associer /a → /b à /b → /a, ou des redirections entre domaines qu'un autre système renvoie à l'origine. Envoyez les anciennes adresses directement vers la destination finale et testez toute la chaîne.

Pour déplacer une page d'accueil, saisissez / comme source et choisissez une portée site ou domaine. Une règle globale active pour la page d'accueil est refusée avec Choose a site or domain for a homepage redirect., ce qui empêche une règle racine globale de capturer toutes les pages d'accueil.

Examinez attentivement les destinations de page d'accueil : une destination relative reste sur le domaine actuel. Préférez la portée la plus étroite et vérifiez que la destination ne possède pas de règle renvoyant le visiteur vers /.

Utilisez 302 temporary pendant la vérification de la source, du nom d'hôte, de la destination et du compteur. Si le déplacement sera permanent et que les tests sont concluants :

1. Trouvez la règle dans Maintenance → Redirects.
2. Utilisez l'action crayon Edit redirect.
3. Vérifiez Applies to, Source path et Target URL.
4. Réglez Status code sur 301 permanent.
5. Laissez Enabled coché et cliquez sur Save changes.

La liste affiche maintenant 301 et un rappel concernant le cache du navigateur. La modification conserve le nombre de visites et l'historique de la dernière visite.

Les navigateurs peuvent mettre en cache une redirection 301 et la réutiliser sans atteindre le CMS. Une destination modifiée peut ainsi sembler inchangée et la nouvelle visite ne pas être enregistrée. Vérifiez avec un client HTTP qui effectue une nouvelle requête ou désactivez le cache dans les outils réseau du navigateur. Désactiver la règle ne peut pas rappeler les réponses déjà stockées par le client ou une couche supérieure.

Pour arrêter la redirection tout en conservant sa configuration et son historique, modifiez la règle, décochez Enabled et cliquez sur Save changes.

La ligne reste dans la liste avec l'état Disabled. Les nouvelles requêtes n'utilisent plus cette règle et le compteur n'augmente plus. S'il n'existe aucune autre règle de portée active ou couche de redirection, le serveur renvoie sa page normale ou une erreur 404. Dans l'exemple, l'ancienne adresse inutilisée renvoie 404 après la désactivation.

Pour la réactiver, modifiez la même ligne, cochez Enabled, vérifiez la destination et enregistrez. Vous évitez ainsi une source en double et conservez l'historique de la règle.

L'action corbeille Delete redirect supprime la règle et son historique de visites. Dans la version 0.1.28, elle est exécutée directement ; l'extension n'a ni corbeille ni écran de restauration. Notez les informations nécessaires avant la suppression et utilisez Disabled pour une pause réversible.

Désactiver toute l'extension depuis System → Plugins arrête le traitement et masque ses contributions. Le cycle de vie actuel conserve les tables de l'extension. Cette action est plus large que la désactivation d'une règle et ne vide pas les caches du navigateur ou du CDN.

Redirect Manager 0.1.28 propose des règles individuelles, deux codes de statut, le choix de la portée et un historique agrégé des visites. Il n'ajoute aucun bloc au constructeur de pages : une fois actif, il traite directement les requêtes publiques correspondantes.

L'administration ne propose ni règles planifiées, ni import/export CSV en masse, ni caractères génériques, ni analyse par visiteur, ni détection automatique des liens cassés. Planifiez ces besoins séparément plutôt que de saisir des motifs non pris en charge dans Source path. Cette version ne comporte pas non plus d'action pour remettre le compteur à zéro.

Si vous modifiez l'adresse d'une page dans le CMS, examinez vous-même l'ancienne URL. Renommer une page n'ajoute pas automatiquement une règle à la liste de l'extension. Mettez à jour la navigation et les liens internes vers l'adresse finale ; conservez des redirections volontaires pour les favoris externes et les liens que vous ne pouvez pas modifier. Consultez Modifier l'adresse d'une page.

Pour l'automatisation, l'extension expose sa collection de règles via l'Internal Content API à l'adresse /webadmin/api/redirect-manager/redirects. La lecture utilise plugins.read ; l'écriture utilise plugins.manage et les restrictions de site correspondantes. Utilisez la découverte de l'API du CMS pour examiner les points de terminaison installés et le contrat des requêtes. Les utilisateurs de l'administration n'ont pas besoin d'un jeton API pour suivre ce guide.

Avant d'activer le déplacement réel, confirmez que la nouvelle page est publiée et renvoie le bon contenu sur l'hôte de destination. Commencez avec 302 ; testez l'ancienne adresse sans suivre la redirection pour examiner le statut et l'en-tête Location, puis suivez-la afin de vérifier la page finale.

Vérifiez tous les domaines concernés, les règles de portée plus précises, les barres finales et les attentes concernant les requêtes. Confirmez que la destination ne renvoie pas en arrière et que les tests GET/HEAD produisent la variation de compteur attendue. Passez à 301 uniquement lorsque le déplacement permanent est définitif.

Après le lancement, mettez à jour les liens que vous contrôlez, consignez la portée et l'objectif de la règle et examinez régulièrement les totaux. Pour une pause, désactivez avant de supprimer. Vous disposerez ainsi d'un processus reproductible qui conserve les anciennes URL utilisables tout en contrôlant où chaque redirection s'applique.