Mises à jour

Les mises à jour dans WebBlocks CMS reposent sur les versions publiées et sur les paquets.

• La version installée reflète la dernière version réelle appliquée à l'installation.
• Le développement ordinaire du code source ne change pas la version installée.
• L'outil de mise à jour intégré applique des paquets de versions publiées, et non les modifications locales de l'arbre de travail.
• Les nouveaux consommateurs Composer doivent d'abord installer avec composer require fklavyenet/webblocks-cms et php artisan webblocks:install avant d'utiliser le flux normal de mise à jour fondé sur les versions publiées.
• Les installations natives de paquet actuelles consomment directement les ZIP de version à racine de paquet.
• Les System Updates natives de paquet appliquent l'artefact du paquet à la racine canonique du paquet Composer, vendor/fklavyenet/webblocks-cms, de sorte que la mise à jour Composer et la System Update produisent la même arborescence de paquet installée.
• Historiquement, les installations antérieures au natif de paquet, telles que 1.31.53, ne pouvaient pas consommer directement les ZIP de version à racine de paquet et exigeaient d'abord le pont géré depuis la racine à l'ancien format 1.32.33. Ce chemin de pont est désormais retiré de la validation de version courante, car il ne reste plus d'anciennes installations gérées depuis la racine à prendre en charge dans les contrôles normaux.

• N'exécutez les mises à jour qu'à partir de versions publiées.
• Conservez les fichiers propres à l'installation dans des chemins préservés tels que .env, storage/ et project/.
• Traitez séparément les flux de développement et de publication.
• Dans les copies de maintenance gérées depuis les sources, les modifications locales sont déjà présentes dans l'arbre de travail. Les System Updates ne doivent pas servir à appliquer ces modifications locales, et la version du code CMS en cours d'exécution est comparée à la dernière version publiée pour déterminer la disponibilité d'une mise à jour.
• Les paquets de version ne contiennent que du code réutilisable du cœur du CMS et ne doivent pas embarquer de contenu project/ propre à l'installation.
• Les chemins préservés lors de la mise à jour ne modifient pas la frontière du paquet de version : project/ reste local à l'installation et hors de l'artefact publié.
• Les copies de travail CMS installées sont consommatrices de mises à jour, non publieuses en amont. Si une installation possède un origin git, conservez l'accès en fetch si nécessaire mais désactivez le push avec git remote set-url --push origin DISABLED.
• Une System Update n'est enregistrée comme réussie qu'après que l'exécution du paquet appliqué rapporte la version cible depuis la source de version canonique WebBlocks\Cms\Support\WebBlocks. Si le code appliqué rapporte encore une version ancienne ou inattendue, l'exécution est enregistrée comme échouée et les opérateurs doivent restaurer la sauvegarde antérieure à la mise à jour ou inspecter l'état du système de fichiers et du cache avant de réessayer.

Avant de modifier le comportement de compatibilité des versions, des mises à jour, de la publication, de Publisher, des artefacts ou des migrations du CMS, interrogez WebBlocks Advisor et intégrez la réponse au rapport sous forme de note d'implémentation. Si Advisor n'a pas la bonne réponse, mettez d'abord à jour la source de connaissance ou le fragment concerné plutôt que d'inventer un flux de travail ponctuel.

L'écran System Updates affiche des détails de version lisibles avant qu'un administrateur ne lance une mise à jour. Le flux principal comporte deux cartes : Install Update et Update Details. Install Update indique si une mise à jour est disponible, si la version du code CMS en cours d'exécution est à jour, si la version locale ou issue des sources est plus récente que le dernier paquet publié, si la mise à jour est incompatible, ou si la réponse du serveur de mises à jour ne peut pas être considérée comme fiable. Le résumé affiché compare la version du code CMS en cours d'exécution à la dernière version publiée. La version installée enregistrée reste une valeur d'historique d'installation et de persistance des mises à jour, consultable dans Update Readiness, mais elle ne sert pas à rendre l'action Install Update opérante.

Update Details regroupe les notes de version, la préparation à la mise à jour et la dernière exécution de mise à jour derrière des lignes d'accordéon WebBlocks UI. Update Readiness est un résumé de préparation de l'installation et du service de mise à jour, et non les notes de version de la cible. Last Update Run affiche le résumé de l'exécution pertinente la plus récente et ouvre les détails dans une modale si nécessaire. Un téléchargement de rapport de support réservé aux super-administrateurs est disponible pour les cas de support en hébergement mutualisé ; il contient des résumés sûrs de version, de préparation et d'exécution et exclut les jetons, les secrets, les chemins locaux absolus et les traces d'appels brutes.

Les enregistrements d'exécution de mise à jour sont purgés automatiquement après les vérifications de mise à jour et les flux d'application ou d'annulation. La rétention par défaut conserve les cinq dernières exécutions, tandis que la dernière exécution échouée est conservée jusqu'à ce qu'une exécution réussie plus récente existe. L'écran d'administration principal ne liste pas les anciennes exécutions. Les opérateurs disposant d'un terminal peuvent inspecter les exécutions conservées avec php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last et php artisan webblocks:updates:runs --failed ; une purge contrôlée est possible avec php artisan webblocks:updates:prune-runs --keep=5.

L'accordéon compact Release Notes d'Update Details restitue des métadonnées structurées à partir de champs tels que title, summary, highlights, fixes, compatibility_notes, migration_notes, asset_notes, operator_notes et technical_notes. Le CMS restitue ces champs sous forme de texte brut échappé et conserve les contrôles de préparation, la version installée enregistrée et les détails de réponse de bas niveau dans Update Readiness.

La chaîne historique release_notes reste prise en charge pour les charges utiles de versions plus anciennes. En l'absence de notes de version, l'écran affiche No release notes were provided for this release. L'outil de mise à jour ne déduit pas les changements à partir des numéros de version.

Les métadonnées de version sont préparées localement avec composer release:prepare et publiées directement sur le service Publisher avec composer release:publish-update. Le publieur natif envoie des champs structurés de détail de version dans des charges utiles de premier niveau et imbriquées, aux côtés de la valeur historique release_notes, afin que le service de mise à jour puisse servir des notes enrichies aux écrans System Updates compatibles tandis que les clients plus anciens continuent de recevoir des notes simples. Les clients compatibles lisent les détails structurés depuis les champs de premier niveau, details, release_details et les charges utiles du serveur de mises à jour meta.release_details ou meta.details.

GitHub Actions ne crée plus de paquets de version ni ne publie de métadonnées de mise à jour, et les workflows .github sont intentionnellement absents du dépôt du CMS. Les mainteneurs peuvent toujours pousser des commits et des tags git pour l'historique des sources, mais les System Updates ne consomment que les métadonnées du serveur de mises à jour et les artefacts de paquet. publisher.webblocksui.com est le service canonique pour la publication comme pour la consommation des mises à jour : les mainteneurs publient sur https://publisher.webblocksui.com/api/updates/publish, les sites CMS installés lisent les dernières métadonnées depuis https://publisher.webblocksui.com/api/updates/latest, et les URL d'artefact des métadonnées doivent pointer vers les téléchargements de paquet sur https://publisher.webblocksui.com/downloads/.... Les sites CMS installés ne configurent pas de clés d'environnement pour Publisher/serveur de mises à jour, produit ou canal dans les fichiers .env habituels, car le code produit du CMS détient le serveur de versions par défaut, la clé produit, le canal stable, le chemin de lecture et le chemin de publication via ReleaseDefaults. L'ancien pont updates.webblocksui.com est purement historique et ne doit pas être utilisé comme chemin de configuration actif.

Commandes du mainteneur :

La publication par le mainteneur ne nécessite normalement que WEBBLOCKS_PUBLISHER_TOKEN. Les vérifications de mise à jour du CMS installé utilisent les valeurs par défaut du produit pour https://publisher.webblocksui.com, le produit webblocks-cms, le canal stable et le chemin de lecture /api/updates/latest ; la publication par le mainteneur utilise la même identité détenue par le produit et le chemin de publication /api/updates/publish. Les exécutions de publication avec configuration mise en cache ne rafraîchissent que le jeton du publieur depuis le .env du projet, si bien qu'un jeton configuré localement est détecté sans export shell. L'exécution à blanc valide les entrées sans rien téléverser. Une publication réelle sans jeton signale un état contrôlé de non-publication, se termine sans succès et ne doit pas être considérée comme une publication de version.

Lorsqu'une System Update intégrée est appliquée avec succès, WebBlocks CMS exécute le flux post-installation dans cet ordre :

• gestion des migrations pour la stratégie d'installation courante
• étapes de vidage du cache
• enregistrement de l'exécution de mise à jour
• persistance de la version installée

Les System Updates normales appliquent des paquets de versions publiées. Elles n'exécutent pas automatiquement l'amorçage du catalogue du cœur, block-types:sync-core, la synchronisation des icônes, la réparation des types de slot, la réparation des slots du layout de page ni la réparation étendue du catalogue. Si une version nécessite une transformation de schéma ou de données, celle-ci doit être traitée comme une migration de mise à jour explicite pour cette version.

Les étapes de vidage du cache comprennent les vidages de configuration, de vues, de cache applicatif et de routes de Laravel, afin que les layouts et helpers Blade appartenant au paquet soient recompilés après le remplacement des fichiers. Sur les installations PHP-FPM en production dont l'OPcache est configuré pour ne pas valider les horodatages, rechargez le service PHP-FPM concerné après une mise à jour réussie afin que PHP ne continue pas de servir depuis la mémoire des classes de paquet antérieures à la mise à jour.

Pour les copies de maintenance gérées depuis les sources, la gestion des migrations conserve l'autorité historique de la racine database/migrations et exécute artisan migrate --force. Ce chemin n'est retenu que lorsque le manifeste Composer de la racine détient l'autorité d'autoload WebBlocks CMS du dépôt de maintenance, y compris WebBlocks\\Cms\\ => packages/webblocks-cms/src/.

Pour les nouveaux consommateurs Composer natifs de paquet installés avec webblocks:install, la System Update n'exécute pas le répertoire racine database/migrations de l'application Laravel hôte. La seule présence du répertoire du paquet n'est pas un signe de copie des sources. Cela évite que des migrations de démarrage Laravel en attente, telles que 0001_01_01_000000_create_users_table.php, n'entrent en conflit avec les tables CMS créées par le schéma d'installation neuve du paquet. Les mises à jour des consommateurs du paquet appliquent l'artefact de version à vendor/fklavyenet/webblocks-cms et n'exécutent des migrations de mise à jour dédiées appartenant au paquet depuis vendor/fklavyenet/webblocks-cms/database/migrations/updates que lorsque ce répertoire contient des fichiers de migration PHP ; sinon, l'outil de mise à jour consigne que les migrations de l'hôte ont été ignorées et poursuit avec les vidages de cache et la persistance de la version installée. Les migrations de mise à jour du paquet sont aussi l'endroit approprié pour des réparations sûres de schéma sur les installations existantes, comme l'ajout de clés parentes manquantes nécessaires à la portabilité de la sauvegarde et de la restauration complètes de la base de données.

Tout changement de schéma de WebBlocks CMS requis par le code à l'exécution doit prendre en charge les deux chemins d'installation :

1. Installations neuves ou de consommateur du paquet : mettez à jour le chemin de migration de schéma normal ou d'installation neuve.
2. Installations natives de paquet existantes mises à jour via les System Updates : ajoutez une migration de mise à jour du paquet sous database/migrations/updates du paquet ; les consommateurs installés l'exécutent depuis vendor/fklavyenet/webblocks-cms/database/migrations/updates.

Le schéma d'installation neuve ne suffit pas à lui seul. Si le nouveau code à l'exécution attend une table ou une colonne, la version doit inclure une migration de mise à jour pour les installations existantes, ou bien la mise à jour doit échouer proprement avant que le nouveau chemin de code ne puisse produire une erreur 500 brute. Les System Updates natives de paquet ne doivent pas obliger les utilisateurs ordinaires à se connecter en SSH à un site et à lancer des migrations manuelles après une mise à jour réussie.

Une System Update native de paquet réussie signifie que le code appliqué, le schéma requis, les vidages de cache et la préparation de version et de schéma après application sont alignés. Les pages d'administration, d'API et d'exécution qui dépendent d'un schéma nouvellement ajouté doivent afficher des indications maîtrisées de configuration ou de mise à jour en cas de schéma manquant, au lieu d'exposer des erreurs brutes du framework ou de la base de données. L'incident des jetons d'API entre 1.32.146 et 1.32.147 est le mode de défaillance de référence : cms_api_tokens n'existait que dans le chemin de migration normal, QuizTem, natif de paquet, a mis à jour le code, et System -> API Tokens a renvoyé une erreur 500 brute jusqu'à ce que la 1.32.147 ajoute une migration de mise à jour du paquet et une gestion propre de la préparation.

Les rapports de version comportant un changement de schéma doivent répondre explicitement à :

• chemin de schéma d'installation neuve mis à jour : oui/non
• migration de mise à jour du paquet ajoutée : oui/non
• test de non-régression de la migration de mise à jour ajouté : oui/non
• comportement propre en cas de schéma manquant nécessaire/ajouté : oui/non

Pendant la transition vers le paquet, certaines installations peuvent encore comporter une copie obsolète packages/webblocks-cms à la racine de l'installation ou une ancienne copie de transition imbriquée dans vendor. Ces chemins sont des artefacts hérités de la transition, et non la source de vérité native de paquet active. La System Update native de paquet remplace désormais la racine canonique du paquet Composer à vendor/fklavyenet/webblocks-cms et vérifie la version cible depuis cette racine de paquet. Elle ne conserve pas packages/webblocks-cms comme seconde copie d'exécution mise à jour.

Les installations plus anciennes peuvent avoir un répertoire vendor Composer en forme de dépôt à vendor/fklavyenet/webblocks-cms, avec des fichiers racine tels que artisan, app/, bootstrap/, packages/webblocks-cms/, plugins/ ou tests/. La System Update normalise ce répertoire vendor en le remplaçant par l'artefact plat à racine de paquet. La racine de paquet obtenue contient des fichiers du paquet tels que composer.json, src/, docs/, routes/, resources/, database/, public/, config/ et stubs/ directement sous vendor/fklavyenet/webblocks-cms. Les mises à jour natives de paquet normalisent les métadonnées de paquets installés de Composer avant de régénérer les fichiers d'autoload optimisés, puis vérifient que les métadonnées d'autoload générées par Composer résolvent WebBlocks\Cms\ depuis vendor/fklavyenet/webblocks-cms/src, et non depuis l'ancien chemin imbriqué vendor/fklavyenet/webblocks-cms/packages/webblocks-cms/src. S'il reste des chemins imbriqués obsolètes, l'exécution de la mise à jour échoue au lieu de signaler un succès avec une administration hors service.

Les mises à jour modernes préservent la séparation entre l'administration /webadmin et les ressources /cms introduite par la migration de la v1.32.56. /cms est uniquement un espace de noms de ressources statiques, et non un préfixe d'administration, car le try_files de Nginx peut résoudre /cms/ comme le répertoire physique public/cms/ avant que Laravel ne voie une route. Les mises à jour ne doivent pas restaurer d'alias d'administration /cms appartenant au CMS, de redirections /cms, de routes /admin ni de relais public/cms/index.php, que ce soit à la racine de l'installation ou dans les ressources publiques du paquet.

Cette section est historique. L'outil de mise à jour de la 1.31.53 validait l'ancien contrat d'archive géré depuis la racine : artisan et composer.json devaient exister à la racine de l'archive, ou dans un unique répertoire englobant. Les artefacts à racine de paquet tels que 1.32.31 ne contenaient volontairement pas d'artisan racine, si bien que ces anciens clients échouaient avant l'application avec Package validation failed because composer.json and artisan were not found at the archive root.

La stratégie de pont retirée se déroulait en deux étapes :

• Publier ou republier un artefact de version passerelle dans l'ancienne forme gérée depuis la racine, construit à partir d'une source compatible passerelle qui contenait encore les enveloppes héritées App\Support\System\Updates\* et validait déjà les archives strictes à racine de paquet fklavyenet/webblocks-cms. Pour la passerelle 1.32.33, la référence source était v1.32.30.
• Publier des versions à racine de paquet avec minimum_client_version fixé à 1.32.18 ou plus récent, afin que les anciens clients ne se voient pas proposer le dernier artefact à racine de paquet avant la passerelle.
• Une fois la passerelle appliquée, l'updater installé pouvait valider et appliquer la forme stricte d'artefact à racine de paquet fklavyenet/webblocks-cms utilisée par les versions modernes.

scripts/build-root-managed-bridge-archive.sh VERSION [OUTPUT_DIR] [GIT_REF] n'est conservé que comme outil archivé de récupération manuelle pour le ZIP passerelle à l'ancienne forme ; par exemple scripts/build-root-managed-bridge-archive.sh 1.32.33 dist v1.32.30. Le constructeur exclut délibérément les chemins appartenant à l'installation tels que .env, storage/, project/, public/site/, public/storage et le config/ racine ; les valeurs par défaut appartenant au paquet sous packages/webblocks-cms/config restent partie intégrante du runtime du paquet. La validation courante native du paquet n'emprunte pas ce chemin de passerelle.

Le chemin historique achevé était 1.31.53 -> 1.32.33 bridge -> 1.32.34+ package-rooted. Les installations déjà compatibles passerelle, comme 1.32.30, ont sauté la passerelle et sont passées directement à une version à racine de paquet 1.32.34+. Les garde-fous de version actuels ne protègent que l'artefact à racine de paquet et le comportement de l'updater natif du paquet.

La réparation et la synchronisation du catalogue sont des actions de maintenance explicites, distinctes de System Updates. Utilisez :

La commande prend en charge une maintenance ciblée avec --block-types, --slot-types, --page-layouts et --icons. Exécutez-la d'abord avec --dry-run pour voir les lignes qui seraient créées, mises à jour, laissées inchangées ou ignorées. La commande est idempotente, préserve les lignes de catalogue personnalisées ou propres à l'installation et ne supprime aucune ligne personnalisée.

La synchronisation de plus bas niveau des types de bloc reste disponible pour des raisons de compatibilité :

Le chemin de réparation des types de bloc maintient le catalogue block_types stocké en base aligné sur le catalogue du cœur du CMS livré, sur les installations existantes :

• les types de bloc du cœur manquants sont créés
• les types de bloc du cœur existants sont mis à jour sur place
• les types de bloc personnalisés propres à l'installation sont préservés
• aucune ligne du cœur en double n'est créée

Ce flux de maintenance couvre le cas où une installation doit rafraîchir des lignes de catalogue sans obliger chaque application d'un paquet de version à effectuer une réparation étendue du catalogue en base.

Lorsque l'updater s'exécute dans un clone d'installation géré par git qui pointe encore vers l'upstream canonique du CMS, le CMS désactive désormais aussi automatiquement le push vers origin après les commandes de post-installation, afin que de futures tentatives accidentelles de git push échouent clairement tandis que l'accès normal en fetch ou pull reste disponible.

• Exploitation
• Installation
• Flux de travail de développement