WebBlocks Redirect Manager

Version du package documentée : 0.1.18. WebBlocks CMS ^1.32 ; PHP >=8.1.

WebBlocks Redirect Manager est un petit plugin WebBlocks CMS permettant de créer et de gérer des redirections 301/302 simples à partir de la zone d'administration WebBlocks CMS.

• Poignée de plug-in : webblocks-redirect-manager
• Version du plug-in : 0.1.18
• Produit hôte cible : webblocks-cms
• Version CMS requise : ^1.32
• PHP : >=8.1

1. Créez l'artefact du plugin localement : composer plugin:build
2. Téléchargez build/releases/webblocks-redirect-manager-0.1.18.zip vers le flux de téléchargement du plug-in WebBlocks CMS.
3. Après le téléchargement, le CMS doit d'abord enregistrer le plugin dans un état désactivé.
4. Examinez les métadonnées et les autorisations du plugin.
5. Activez le plugin lorsque vous êtes prêt.
6. RExécutez la migration du plug-in via le cycle de vie du plug-in CMS ou la commande de migration requise par l'installation de l'hôte.

Le plugin possède une table :

webblocks_redirect_manager_redirects

La migration crée des enregistrements de redirection avec :

• source_path
• target_url
• status_code
• is_enabled
• hit_count
• last_hit_at
• horodatages

• webblocks-redirect-manager.view
• webblocks-redirect-manager.manage

• Les redirections activées sont évaluées pour les requêtes publiques GET et HEAD sans correspondance avant que le CMS ne renvoie un 404.
• CMS 1.32.112 découvre les fournisseurs de plug-ins installés pour les métadonnées definition(), mais ne les enregistre ni ne les démarre en tant que fournisseurs de services Laravel. Redirect Manager enregistre donc sa route de secours publique à partir de definition() au lieu de s'appuyer sur la mutation du groupe de middleware du fournisseur boot().
• Les requêtes POST, PUT, PATCH et DELETE sont contournées.
• Les espaces de noms administrateur et statiques sont contournés, notamment /webadmin/..., /cms/..., /storage/..., /assets/..., /static/..., /build/..., /vendor/... et /webblocks-ui/....
• Les chemins source sont normalisés avec une barre oblique de début et aucune barre oblique de fin, donc /test-1, test-1 et /test-1/ correspondent à la même règle.
• Les chaînes de requête entrantes sont ignorées pour la correspondance. /test-1?x=1 correspond à la source /test-1.
• Les chaînes de requête entrantes ne sont pas ajoutées à l'URL cible. Une règle de /test-1 vers /test-2 redirige /test-1?x=1 vers /test-2.
• La correspondance entre GET et HEAD redirige à la fois l'incrément hit_count et la mise à jour last_hit_at.
• Les redirections internes auto-cibles sont rejetées lors de la validation de création/modification par l'administrateur et contournées lors de l'exécution en tant que protection contre les boucles.
• Si la table des plugins est manquante parce que les migrations de plugins n'ont pas été exécutées, les requêtes publiques contournent le middleware sans erreur SQL.

Les navigateurs peuvent mettre en cache les redirections 301. Lors du test des compteurs d'accès, utilisez les redirections 302, videz le cache du navigateur, utilisez la navigation privée ou testez avec curl.

• Les migrations de plugins ne sont pas exécutées automatiquement ; exécutez-les tout au long du cycle de vie du plugin CMS lors de l’installation ou de la mise à jour.
• Aucun comportement npm, Vite, Tailwind, Node, place de marché, paiement, licence, installation à distance ou mise à jour automatique n'est inclus.