Opérations

WebBlocks CMS comprend des outils opérationnels au niveau de l'installation pour les mises à jour, les sauvegardes et les paquets de transfert de site.

Settings figure également dans la navigation System de l'administration car il contrôle l'identité de projet, la langue, le fuseau horaire, la confidentialité, la version et les réglages d'environnement au niveau de l'installation.

Admin -> System -> Block Types sert aussi d'écran d'inspection du catalogue au niveau de l'installation. Son filtre Support porte sur les métadonnées de capacité et de source de contenu des blocs, tandis que son filtre Usage porte sur les décomptes d'utilisation réels issus de la table blocks, afin que les administrateurs puissent examiner les lignes de types de bloc utilisées ou inutilisées.

Admin -> System -> Visitor Reports fournit des rapports de trafic respectueux de la vie privée, à côté des réglages système au niveau de l'installation.

Maintenance contient l'aperçu consolidé ainsi que les outils opérationnels existants :

• État du système
• Reconstruction de l’index de recherche
• Sauvegardes
• Nettoyage
• Exportation / Importation
• Mise à jour

Depuis CMS 1.98.0, Maintenance → System Health fournit un seul endroit pour examiner l'installation et ses sites. Pour les utilisateurs disposant d'un accès à l'intégrité du système, le tableau de bord affiche un résumé compact des vérifications nécessitant une action, méritant d'être examinées ou non encore vérifiées, avec un lien vers la présentation complète. Les comptes zéro montrent qu'aucun problème n'a été trouvé dans les contrôles disponibles. La page commence par les décomptes et les éléments les plus urgents, suivis par des cartes pour le système, les sites, les sauvegardes, le travail planifié, le stockage, la recherche, les plugins et les mises à jour. Chaque élément explique l'étape suivante et renvoie à l'outil existant. Les détails techniques, les résultats récents de sauvegarde/restauration/mise à jour et les valeurs d'informations système existantes sont repliés par défaut.

La carte Notifications programmées comprend l'avis détaillé du planificateur, l'effet sur les e-mails en attente, UTC les heures du dernier battement de cœur programmé et de l'exécution des notifications terminées, les instructions de configuration et un lien vers le guide d'installation. Les liens de révision de planification ouvrent cette section et conservent le filtre de site sélectionné. Les responsables des opérations du site qui ne peuvent pas accéder à l'intégrité du système conservent la carte Planificateur détaillée à l'échelle du site sur leur tableau de bord et dans les paramètres de contact du site. Le résumé de la boîte de réception des notifications du panneau reste sur le tableau de bord.

Les états distinguent les situations saines, à examiner, urgentes, pas encore vérifiées et non applicables. Une vérification indisponible n’est pas présentée comme saine. Les vérifications de recherche comparent les couples admissibles de page publiée et de langue à la couverture de l’index ; elles ne certifient pas l’actualité du texte. Les vérifications des sauvegardes couvrent les enregistrements récents réussis et la disponibilité des archives ; elles ne certifient pas l’intégrité de la restauration. La préparation à la mise à jour est distincte de l’état de l’installation ; la disponibilité des versions utilise un résultat récent de mise à jour mis en cache. Ouvrez Mises à jour pour demander une nouvelle vérification des versions.

Les vérifications du site sont mises en cache pendant cinq minutes ; l'écran d'intégrité du système lit les preuves enregistrées du planificateur à chaque visite. Le tableau de bord, les sauvegardes et le nettoyage affichent le dernier rapport terminé avec son temps de mesure. Ils n'analysent pas la sauvegarde SQL lors de l'ouverture. Les rapports manquants ne sont pas vérifiés et les rapports anciens ou invalidés sont explicitement marqués comme obsolètes. Les paramètres restent disponibles avant le premier rapport. Les onglets Stockage et historique et Actions de nettoyage de Cleanup expliquent les rapports indisponibles et proposent directement des vérifications d'actualisation ; une actualisation revient au même onglet. Le bouton d'actualisation affiche l'activité lors de la soumission et le résultat confirme l'achèvement, signale qu'une autre actualisation est déjà en cours ou affiche un message d'échec. Les actualisations de l’état du système conservent le filtre de site sélectionné.

Les entrées du cache du rapport de maintenance contiennent des tableaux versionnés et des valeurs scalaires, afin que les installations puissent désactiver la désérialisation des objets de cache. Les vérifications d'actualisation confirment le succès uniquement après avoir relu l'instantané exact qu'il a écrit. Un échec de vérification du cache affiche une erreur et tente de conserver le rapport terminé précédent ; Les décisions de conservation manquantes sur les sauvegardes sont affichées sous forme d'aperçus indisponibles plutôt que d'exigences de mise à jour du schéma. Après une mise à jour du produit, le premier rapport pour cette version est généré par Vérifications d'actualisation ou par le planificateur.

Le planificateur Laravel exécute php artisan system:reports:refresh toutes les cinq minutes. Les vérifications d'actualisation sur l'état du système peuvent également exécuter ce travail manuellement. Chaque appel valide au maximum huit archives de sauvegarde d'étage de récupération existantes, puis met à jour le rapport partagé ; une grande installation peut nécessiter plusieurs appels pour terminer la validation initiale. Les nouvelles sauvegardes et téléchargements enregistrent la validation lors de leur création. En attente de validation, l'éligibilité au nettoyage est retenue dans le rapport du panel. Un planificateur fonctionnel est nécessaire pour la fraîcheur automatique ; l'ouverture d'une page ne démarre pas une actualisation synchrone. Les rapports mis en cache ne remplacent jamais les contrôles de sécurité actuels effectués avant le nettoyage ou la restauration. Le dernier rapport complété est conservé jusqu'à sept jours et apparaît comme obsolète au bout de cinq minutes. Le filtre de site restreint les vérifications liées au site tout en conservant les vérifications à l'échelle de l'installation. La présentation n'exécute pas de nettoyage, de reconstruction de recherche, de démarrage de sauvegardes, d'installation de mises à jour ou de création de preuves de planificateur. Les sites existants et les pages de maintenance opérationnelle restent disponibles. Dans CMS 1.98.1, l'écran d'informations système séparé et le lien de la barre latérale sont supprimés ; ses neuf champs d'informations d'exécution restent dans System Health → System details , et /webadmin/system/information redirige vers System Health avec la même exigence d'accès au système. L'aide est un lien de documentation direct vers https://cms.webblocksui.com/docs ; Les destinations du plugin précédemment contribuées à l'aide restent accessibles sous Système.

Le point d’accès en lecture seule de l’API interne est GET /webadmin/api/system/health, avec le paramètre facultatif site_id. Il nécessite la capacité system-health.read explicitement accordée à un jeton système sans restriction dont le créateur actif dispose actuellement d’un accès au Système. Les jetons personnels et limités à des sites ne peuvent pas lire l’état de toute l’installation. Les réponses utilisent des messages contrôlés et des résultats normalisés plutôt que des textes d’exceptions, journaux d’opérations, chemins d’archives ou secrets de plugins. Consultez API interne de contenu pour le contrat de réponse.

Les rapports sur les visiteurs fournissent des résumés opérationnels de l’activité des pages publiques. Les enregistrements de base de pages vues ne nécessitent pas d’identifiants basés sur le consentement. Les enregistrements incluent des informations réduites sur les référents, les campagnes, les appareils et les robots :

• les référents sont normalisés en hôte/domaine plus un type direct, internal ou external ; les URL complètes des référents ne sont ni stockées ni affichées
• les référents vides sont regroupés sous Direct / Unknown
• la source, le support et la campagne UTM ne sont stockés que sous forme de valeurs normalisées ; la chaîne de requête complète n'est pas stockée
• les chaînes user-agent sont réduites au moment de la requête à une catégorie d'appareil (desktop, mobile, tablet, bot ou unknown) ainsi qu'à des familles approximatives de navigateur et de système d'exploitation lorsqu'elles sont disponibles ; les chaînes user-agent complètes ne sont pas stockées
• les motifs user-agent connus de robots d'exploration et de bots sont comptés comme vues de page de bots et restent visibles dans le rapport au lieu d'être supprimés silencieusement

Les visiteurs uniques, les sessions, les pages d'entrée et la moyenne de pages par session nécessitent un suivi de session soumis au consentement. Lorsqu'un filtre de date, de site, de langue ou de trafic contient des vues de page mais aucun identifiant de session ou de visiteur exploitable, l'interface affiche Not tracked au lieu de 0. Les lignes plus anciennes qui ne peuvent pas être complétées sans risque restent Unknown, Direct / Unknown ou Not tracked selon les champs agrégés présents.

L'autorisation par site continue de s'appliquer : les super administrateurs voient tous les sites, tandis que les administrateurs de site et les éditeurs ne voient que les données des sites qui leur sont attribués. Le filtre de site est limité aux sites accessibles à l'utilisateur.

À partir de CMS 1.105.26, la boîte de dialogue de progression affiche une phase actuelle traduite pendant que l'exécution est confirmée. Son titre identifie la version cible sans impliquer que le travail est toujours en cours une fois terminé. Lorsque le suivi s'arrête ou que le résultat devient terminal, la phase, l'indicateur de progression et l'avis d'attente disparaissent ensemble ; le temps écoulé et le résultat restent visibles. Le succès confirmé revient automatiquement aux mises à jour. Les résultats d’échec ou de sauvegarde restaurée restent disponibles pour examen. Les identifiants de phase inconnus utilisent une solution de secours lisible au lieu d'une clé de traduction.

System Updates compare la version du code du CMS en cours d'exécution au service de mise à jour configuré.

L'écran de mise à jour peut signaler des états tels que :

• mise à jour disponible
• à jour
• version locale/source plus récente que la dernière version publiée
• mise à jour incompatible disponible
• aucune version trouvée
• serveur de mise à jour indisponible
• réponse invalide ou non prise en charge

Le flux de mise à jour dans l'application s'effectue en un seul clic. Une seule action Update to X télécharge le package de version, effectue une sauvegarde automatique avant la mise à jour, applique les règles de chemin protégé, exécute les migrations de mise à jour de package requises, efface les caches, vérifie la version du code WebBlocks CMS appliquée par rapport à la version cible, enregistre l'exécution de la mise à jour et conserve la version installée. Si l'application échoue, le programme de mise à jour restaure automatiquement la sauvegarde préalable à la mise à jour et enregistre l'exécution avec le statut restored ; si la restauration automatique échoue également, l'exécution est enregistrée comme failed avec les deux pistes d'erreurs. Pour la récupération manuelle, la sauvegarde préalable à la mise à jour reste sur l'écran Sauvegardes pour le téléchargement et la restauration, et php artisan system:backup:restore effectue une restauration CLI.

Maintenance → Cleanup possède des politiques de rétention à l’échelle de l’installation. Les contrôles de cycle de vie ci-dessous sont disponibles dans CMS 1.105.12.

Les politiques enregistrées existantes, y compris la conservation de sécurité de restauration de 30 jours, restent inchangées. La protection en matière d’âge et de compte s’applique ensemble. Seules les archives physiques distinctes disponibles, structurellement validées, comptent dans le nombre minimum d'archives valides réussies d'un type. Une sauvegarde expirée peut rester protégée par ce nombre minimum. Les archives défaillantes/manquantes ne remplacent pas les points de récupération valides. Les sauvegardes en cours d'exécution et les points de récupération associés aux mises à jour récentes ayant échoué/restaurées restent protégés.

Utilisez l'icône de verrouillage/paramètres sur les sauvegardes pour gérer l'indicateur Protégé d'une archive et son mode policy, never ou expires. La protection bloque la suppression unique, forcée et groupée jusqu'à sa suppression. Le mode indéfini empêche l'expiration automatique mais permet toujours la suppression explicite. Le choix d'une date active explicitement le nettoyage de cette archive, y compris les archives manuelles et téléchargées ; la protection et les dénombres minimaux réussis s’appliquent toujours. Les dates suivent le fuseau horaire de l’application. La boîte de dialogue de création manuelle enregistre la protection/rétention sélectionnée avant la capture SQL.

Le budget facultatif est mesuré en GiB (1024³ octets), est par défaut non défini, avertit à 80 % et signale un dépassement à 100 %. Cela ne remplace jamais la protection ou la rétention. Les sauvegardes et le nettoyage affichent le stockage physique total, les octets explicitement protégés, les octets éligibles, le stockage estimé après le nettoyage et tout dépassement restant. Les fichiers non enregistrés sont pris en compte dans l'utilisation du disque mais ne sont jamais automatiquement sélectionnés. Les mesures partielles/non disponibles sont explicites. Une archive partagée n'est pas comptée plusieurs fois et la suppression d'un enregistrement ne dissocie jamais le fichier d'un autre enregistrement.

Explication du stockage (CMS 1.105.13) : la carte de rétention des sauvegardes dans l'onglet Stockage et historique de Cleanup et la liste des sauvegardes ajoutent un tableau de raisons. Il affiche le nombre d'enregistrements de sauvegarde, le nombre de fichiers physiques distincts et les octets mesurés pour la protection du nombre minimum, les périodes de conservation, la protection explicite, la conservation indéfinie, le nettoyage manuel désactivé et d'autres décisions en cours. Les archives éligibles apparaissent séparément. Les règles d'âge et de nombre minimum protègent toutes deux les sauvegardes ; « conserver le dernier N » est un plancher et non un plafond sur le nombre total retenu.

Les fichiers d'archives partagés contribuent en octets une fois sous la première raison applicable du tableau. Le nombre d’enregistrements suit toujours le statut de chaque enregistrement, donc une raison peut avoir des enregistrements sans octets physiques supplémentaires. Les autres fichiers du stockage de sauvegarde, y compris les fichiers de verrouillage ou de support, apparaissent séparément et ne sont jamais automatiquement supprimés. Une analyse partielle affiche les tailles d'archives connues avec des totaux non confirmés et d'autres tailles de fichiers marquées comme indisponibles. Le nettoyage de sauvegarde existant API inclut la même répartition que preview.overview.reason_summary.

Le nettoyage des sauvegardes s'exécute quotidiennement à 03:30 sous le paramètre activé existant. Le package n'appelle pas de nettoyage de sauvegarde après une mise à jour réussie ; un planificateur d'hôte fonctionnel est requis pour son exécution automatique. Aperçu avec php artisan system:backups:cleanup --dry-run -v ; l'exécution normale utilise la même politique. --force contourne uniquement le paramètre activé. Il ne contourne jamais la protection, les nombres minimaux ou les opérations actives. L'invocation du planificateur ajoute --scheduled pour enregistrer sa source. Les aperçus en lecture seule ne créent aucun historique d'exécution ni racine de disque ; les exécutions terminées enregistrent un résultat limité SQL avec les octets réellement supprimés.

Un bail de système de fichiers non bloquant commun sérialise la création, le téléchargement, la restauration, les modifications de conservation et la suppression des sauvegardes. Il survit à la restauration SQL et se libère à la sortie du processus. Les systèmes de fichiers de sauvegardes partagées doivent prendre en charge les verrous de fichiers consultatifs. Les migrations de packages actuelles sont requises. La maintenance de restauration répare le schéma de rétention/résumé additif lorsqu'un instantané SQL plus ancien est antérieur à lui.

L’API interne conserve GET/PUT /webadmin/api/system/backup-cleanup avec backups.read / backups.settings.write et le POST destructif /webadmin/api/system/backup-cleanup/run avec backups.delete. Les champs d’origine restent obligatoires ; les champs facultatifs du cycle de vie ne modifient que les valeurs fournies et conservent les valeurs omises. Null pour budget_gb supprime le budget. GET/PUT /webadmin/api/system/backups/{backup}/retention lit ou définit protection et expiration avec les mêmes capacités distinctes de lecture et d’écriture des paramètres. Consultez le contrat de découverte de l’API pour les champs obligatoires et modes valides. La copie vers un stockage distant reste une phase ultérieure.

L'espace de travail de nettoyage affiche le nombre de fichiers physiques et les octets pour les sauvegardes du système, les packages d'exportation/importation, les téléchargements publics à l'exclusion des variantes générées, les variantes générées, les espaces de travail temporaires connus, les fichiers de révision d'actifs, les fichiers publics du site et les journaux d'application standard. Les mesures sont horodatées et distinguent les répertoires manquants, les analyses partielles et le stockage indisponible. Ils ne mesurent pas le quota d'hébergement ou les tables de base de données allouées. Les emplacements de journaux personnalisés sont exclus ; Les racines de disque partagées peuvent entraîner un chevauchement des catégories, alors ne les ajoutez pas dans un chiffre de quota à l'échelle de l'installation. Les tailles de révision existantes par site décrivent séparément les charges utiles des instantanés logiques. Un aperçu du nettoyage indisponible s'affiche explicitement.

Les cinq catégories sont asset-revisions, media-variants, temporary-workspaces, page-revisions et shared-slot-revisions. Les révisions de ressources protègent par défaut au moins 90 jours d’historique et les 20 dernières révisions par ressource. Les espaces temporaires ont un délai par défaut de 24 heures. Les révisions de pages et de Shared Slot protègent au moins 90 jours et les 50 dernières révisions par propriétaire, ainsi que les sources utilisées par les restaurations de révisions actives. Les originaux de la médiathèque et les empreintes des variantes actuelles ne sont jamais éligibles au nettoyage des variantes. Les archives de transfert et les journaux restent gérés par l’opérateur.

L’âge de révision et la protection du nombre minimum s’appliquent ensemble. Par exemple, une page avec 20 révisions conserve toutes les 20 même si elles datent de plus de 90 jours, car les 50 dernières sont protégées. Les politiques explicitement enregistrées, y compris la conservation de 365 jours, sont préservées ; seule la période de repli pour un paramètre non défini passe à 90 jours. L’enregistrement des paramètres met à jour l’éligibilité et la prochaine tâche planifiée activée peut l’appliquer.

À partir de CMS 1.105.25, Retention Policy regroupe les planifications de catégories, la rétention des sauvegardes et la rétention des révisions/espaces de travail dans des tables réactives. La rétention signifie un seuil d'âge plus le nombre minimum protégé, et non un nombre maximum de sauvegardes. L'inclusion de la sauvegarde manuelle et le budget de stockage restent des contrôles distincts ; un budget ne l’emporte jamais sur la protection. Les valeurs enregistrées existantes sont conservées lors de la mise à niveau et après les erreurs de validation.

Le lien Configuration et vérification du planificateur ouvre un écran autorisé en lecture seule avec des commandes spécifiques à l'installation et des preuves de battement de cœur enregistrées. Il prend en charge l'hébergement standard cron sans Herne, ainsi qu'une configuration facultative confirmée CLI pour le compte d'application. Voir configuration du planificateur. L'ajout d'une entrée cron ne constitue pas une preuve d'exécution. Actualisez après 1–2 minutes pour vérifier l'activité réelle ; le nettoyage s'exécute toujours selon le calendrier indiqué dans le tableau.

L'espace de travail utilise des onglets natifs pour les actions de stockage et d'historique, de conservation et d'automatisation et de nettoyage. Les paramètres utilisent des groupes nommés WebBlocks UI avec des champs d'âge/compte appariés, sans HTML cadres d'ensemble de champs/légende. Les redirections de validation/action conservent le panneau concerné. Les actions d'engrenage de Retained History ouvrent l'onglet Paramètres de la politique de révision concernée, et son action oculaire ouvre la gestion des packages de transfert. Tous utilisent les actions d'icônes standard du panneau avec des étiquettes accessibles. Les catégories vides affichent un état neutre « Rien à nettoyer » ; les catégories avec des éléments éligibles conservent le modal de confirmation destructive existant. La sélection automatique affiche l'heure programmée de chaque catégorie.

Exécutez les migrations actuelles d’installation ou de mise à jour avant d’utiliser les nouveaux résumés. Chaque catégorie enregistre uniquement son dernier résultat manuel ou planifié avec début, fin, dernier succès, nombres, octets et erreurs. Une suppression partielle ne comptabilise que les octets réellement supprimés. L’absence du schéma de résumé bloque le nettoyage ; un ancien résumé d’exécution en cours est présenté comme interrompu. Les lectures et simulations ne créent aucune preuve d’exécution ni d’activité du planificateur.

Activez les catégories planifiées individuellement dans Maintenance → Nettoyage. Les nouveaux drapeaux sont désactivés par défaut. Les plannings quotidiens exécutent les révisions des actifs en 04:00, les variantes multimédias obsolètes en 04:10 et les espaces de travail temporaires en 04:20. Le nettoyage des pages et des révisions Shared Slot s'effectue le dimanche à 04:30 et 04:45. Les horaires suivent le fuseau horaire de planification de l'application. L'hôte doit exécuter Laravel Scheduler et utiliser un cache partagé avec des verrous atomiques lorsque plusieurs travailleurs fonctionnent. L’élagage des révisions d’écriture d’actifs existant s’applique toujours après les modifications d’actifs, même lorsque sa planification quotidienne supplémentaire est désactivée. Le nettoyage des sauvegardes existantes a sa politique et son calendrier distincts.

Le nettoyage temporaire couvre les exécutions de mise à jour d'horodatage/UUID reconnues et les exécutions de sauvegarde/restauration abandonnées sous storage/app/temp/system-backups et storage/app/temp/system-backup-restores. Chaque entrée imbriquée doit être plus ancienne que le seuil de rétention. La valeur par défaut reste 24 heures ; il n’est pas nécessaire de l’abaisser pour récupérer les travaux abandonnés. L'identité de l'installation, les fichiers ou noms d'exécution inconnus, les dossiers de récupération-sauvegarde du programme de mise à jour, les arborescences de liens symboliques et les archives de sauvegarde qui se chevauchent ou les téléchargements publics sont conservés. L'utilisation physique inclut les fichiers conservés, le stockage mesuré peut donc être différent de zéro sans candidat éligible.

L’historique des mises à jour obsolètes running/pending ne bloque plus le nettoyage. Les admissions récentes, les nouveaux battements de cœur, les tâches d'opérateur en file d'attente et les verrous de mise à jour réellement retenus protègent toujours le travail. Les baux du processus de sauvegarde/restauration protègent également les opérations dont l'instantané de base de données indique déjà completed. La suppression détient à la fois les baux d'exploitation et revérifie l'âge et l'identité de l'arbre ; il ne réécrit pas l'historique des mises à jour. Si le battement de cœur du bail ne peut pas être écrit et relu, le nettoyage s'arrête en toute sécurité. Les téléchargements de catalogue utilisent des baux de fichiers lors de l'installation ; seuls les fichiers temporaires expirés et déverrouillés catalog-plugin- sont éligibles. Les autres fichiers de ce répertoire ne sont pas sélectionnés. Le nettoyage temporaire automatique reste une option explicite par installation dans Rétention et automatisation ; l’activer ne modifie pas la limite d’âge ni les autres indicateurs de catégorie.

Le dernier formulaire ne s'exécute que si la maintenance automatique est activée pour cette catégorie. Utilisez l’un des cinq noms de catégorie pour l’argument de catégorie. Un essai à sec ne supprime jamais de fichiers ni n'écrit un résumé d'exécution ; les commandes renvoient un échec lorsque le nettoyage ou son aperçu ne peuvent pas se terminer.

L'interne API expose GET et PUT /webadmin/api/system/cleanup à maintenance.read et maintenance.settings.write, plus destructeur POST /webadmin/api/system/cleanup/{category}/run à maintenance.delete. Les champs de rétention existants restent obligatoires lors des écritures de paramètres. Les correctifs d'objet facultatifs automatic nommés indicateurs de catégorie booléenne ; les drapeaux omis conservent leurs valeurs. La réponse lue ajoute les mesures physiques et les derniers résultats sous overview.storage_report et overview.automation. Les indicateurs inconnus et les valeurs non booléennes sont rejetés. Une exécution échouée renvoie ok: false et un nombre d'échecs plutôt que de revendiquer un nettoyage réussi.

La disponibilité des mises à jour est basée sur le fait que la dernière version publiée est plus récente que la version du code CMS en cours d'exécution. Les exécutions de mise à jour historiques ayant échoué et les valeurs de version installée stockées obsolètes restent inspectables via le modal des détails d'exécution et l'exécution conservée CLI, mais elles ne rendent pas une installation actuelle exploitable par elles-mêmes.

L'écran est une seule carte d'état. Lorsqu'une mise à jour compatible est disponible, elle affiche le chemin de la version actuelle vers la dernière version, une zone de journal des modifications pliée What's new, l'action en un clic Update to X avec une note de sauvegarde et un avis de sauvegarde du serveur lié à l'écran Sauvegardes afin que les opérateurs effectuent une nouvelle sauvegarde complète avant une mise à jour majeure. Lorsqu'aucune mise à jour n'est disponible, un message discret de mise à jour s'affiche avec la version installée et l'heure de la dernière vérification.

Les super administrateurs ont un shell d'indicateur de mise à jour asynchrone dans la barre supérieure d'administration. Il est masqué par défaut, vérifie l'état de la mise à jour de manière asynchrone et devient visible uniquement lorsqu'une version approuvée plus récente est disponible.

La préparation au contrôle en amont est une liste de contrôle réussite/échec explicite à l'écran : connexion à la base de données, extensions ZIP et sodium PHP, exécution PHP/Composer/processus, accès en écriture à la racine de l'application et à l'espace de travail de mise à jour et espace disque libre. L’action de mise à jour n’est disponible que lorsque chaque vérification réussit et qu’aucune autre exécution de mise à jour ne détient le verrou.

L'historique des mises à jour restitue les exécutions conservées sous forme d'accordéon fermé ; chaque exécution ouvre son journal dans un modal et la suppression de lignes ne fait pas partie de l'administrateur UI. Les enregistrements d'exécution de mise à jour sont automatiquement élagués, conservant par défaut les cinq dernières exécutions. La dernière exécution ayant échoué est conservée jusqu'à ce qu'une nouvelle exécution réussie existe. Les opérateurs ayant accès au terminal peuvent inspecter les enregistrements conservés avec php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last ou php artisan webblocks:updates:runs --failed, et peuvent exécuter un élagage contrôlé avec php artisan webblocks:updates:prune-runs --keep=5.

Le client de mise à jour prend en charge les métadonnées structurées du service de mise à jour, notamment le titre, le résumé, les points forts, les correctifs, les notes de compatibilité, les notes de migration, les notes sur les actifs, les notes de l'opérateur et les notes techniques, ainsi que les entrées cumulatives du journal des modifications par version pour l'accordéon What's new. La préparation de la version native CMS dérive un résumé et les faits saillants de la section de version correspondante CHANGELOG.md et ajoute des métadonnées techniques spécifiques à la version, de sorte que la carte de version doit décrire la version réellement publiée au lieu d'espaces réservés répétés pour le flux de travail de publication. Ces valeurs sont rendues sous forme de texte brut échappé. Les versions plus anciennes qui fournissent uniquement release_notes affichent toujours ces notes clairement, et les versions sans notes affichent No release notes were provided for this release.

La synchronisation du catalogue expédié s'exécute automatiquement en tant qu'étape de la meilleure façon de la chaîne d'application des mises à jour (webblocks:catalog-repair --all) ; un échec de synchronisation ne fait pas échouer l'exécution de la mise à jour et peut être réparé manuellement par la suite.

Pour une maintenance manuelle ou une récupération sur une installation existante, les administrateurs et les développeurs peuvent également exécuter :

webblocks:catalog-repair prend en charge --block-types, --plugin-block-types, --slot-types, --page-layouts, --icons et --all. Il signale les lignes créées, mises à jour, inchangées et ignorées, préserve les lignes du catalogue personnalisé spécifiques à l'installation et peut être exécuté à plusieurs reprises. block-types:sync-core reste une commande de compatibilité de niveau inférieur pour le catalogue de types de blocs.

--plugin-block-types écrit une ligne de catalogue pour chaque type de bloc déclaré par un plugin installé, activé ou non, afin que le bloc puisse être placé dans l'éditeur ; les blocs d'un plugin désactivé sont toujours filtrés des sélecteurs par PluginBlockCatalog. Les actions du cycle de vie du plugin (installer, activer, désactiver, configurer, mettre à jour) exécutent déjà cette synchronisation via PluginRuntimeRefresher, la portée est donc un chemin de réparation plutôt que le chemin normal. Une resynchronisation corrige les colonnes appartenant au plugin (name, description, source_type, is_system, is_container) et laisse délibérément category, sort_order et status seuls, de sorte que la curation de l'opérateur - retablage d'un bloc, le réorganiser ou le mettre en brouillon pour le masquer - survit à la réparation.

Les packages de versions publiées contiennent le runtime réutilisable CMS : source, ressources publiques, migrations, vues, itinéraires, configuration, fichiers de langue et stubs d'installation. Les tests de développement, les scripts, les métadonnées du référentiel, la configuration locale, les sources de documentation et le contenu du projet spécifique à l'installation sont exclus de l'archive de distribution. La documentation canonique est conservée dans son référentiel indépendant.

La publication des versions/mises à jour du CMS est un flux de travail natif/local réservé au mainteneur :

release:push envoie la branche de publication et la balise annotée à origin en un seul push Git, de sorte que la suite de validation pré-push s'exécute une seule fois. Il reflète ensuite les références vérifiées dans backup sans réexécuter ce hook. release:prepare construit le package ZIP, la somme de contrôle et la charge utile Publisher à partir de la validation HEAD ; cela nécessite un arbre propre, une version source correspondante, la balise annotée exacte v{VERSION} et un inventaire révisé avec la provenance de la documentation correspondante.

Exécutez les vérifications locales et vérifiez le GitHub CI du commit de version avant de publier. release:publish-update -- --dry-run valide l'artefact et la configuration sans téléchargement. La commande de publication réelle nécessite une authentification GitHub CLI, signe et télécharge l'artefact sur Publisher, vérifie les métadonnées du canal stable et publie ou met à jour la version GitHub correspondante. Publisher reste la source de mise à jour de l'installation ; une version GitHub à elle seule ne publie pas le canal de mise à jour CMS. Si une réponse est interrompue, inspectez les deux états de publication avant de réessayer.

La publication du responsable nécessite WEBBLOCKS_PUBLISHER_TOKEN et WEBBLOCKS_PUBLISHER_SIGNING_KEY, chargés lors de l'exécution à partir de la configuration établie du responsable. Ne copiez pas ces informations d'identification dans une installation ou une documentation CMS. Les sites installés utilisent les valeurs par défaut du serveur de version, du produit et du canal stable appartenant au package ; les installations ordinaires n'ont pas besoin de Publisher paramètres d'environnement de serveur ou de canal. L'ancien pont updates.webblocksui.com est historique et n'est pas un chemin de configuration actif.

Les copies de travail CMS installées sont des consommatrices de mises à jour. Elles peuvent récupérer l'historique du code source si nécessaire, mais ne doivent pas pousser en amont ni publier de mises à jour du CMS depuis une copie d'installation.

Les soumissions du formulaire de contact sont enregistrées avant l'envoi de la notification. L'état de notification par e-mail reflète uniquement le comportement de notification et ne modifie pas la classification éditoriale. Sent signifie que Laravel a accepté l'envoi via un transport de courrier réel configuré sans exception ; cela ne garantit pas la livraison en boîte de réception. Failed signifie qu'une véritable tentative de notification a provoqué un échec purifié. Skipped ou Not configured signifie qu'aucun envoi réel n'a eu lieu. Les soumissions valides sont classées comme autorisées, mises en quarantaine ou spam ; la quarantaine et le spam sont conservés pour examen et les notifications sont supprimées. Une preuve signée invalide, un champ de contrôle généré rempli ou une soumission en dessous du délai minimum strict suivent le succès générique sans stockage. Le résumé continu de la protection ne compte que les demandes ayant atteint le score. Voir Protection des soumissions publiques pour les signaux, les seuils, les limites de confidentialité et les réglages.

Les destinataires des notifications du Contact Form sont résolus dans cet ordre :

1. recipient_email du bloc Contact Form
2. Destinataire de contact par défaut du site, depuis Site -> Edit -> Contact
3. .env CONTACT_RECIPIENT_EMAIL
4. repli sûr MAIL_FROM_ADDRESS

Les réglages SMTP Laravel habituels dans .env sont les suivants :

Après avoir modifié les réglages de messagerie du .env sur une installation de production ou issue d'un paquet, videz la configuration mise en cache si nécessaire :

Utilisez la commande de diagnostic de messagerie sans secrets lorsqu'un Contact Message signale un échec de notification :

La commande rend compte du mailer résolu, de l'hôte, du port, des champs de schéma/chiffrement, du nom d'utilisateur, de l'adresse d'expédition, de CONTACT_RECIPIENT_EMAIL, de l'état du cache de configuration et des replis facultatifs de destinataire du bloc Contact Form ou du site. Elle n'imprime jamais MAIL_PASSWORD ni de valeurs de jetons. Le test d'envoi facultatif ne rapporte que la réussite ou un détail d'échec assaini, afin que les opérateurs puissent distinguer une configuration obsolète, une incohérence d'hôte/port/chiffrement, une incohérence entre nom d'utilisateur et adresse d'expédition, et des identifiants de boîte aux lettres invalides, sans divulguer de secrets dans les journaux du terminal.

Utilisez Contact Messages comme source de vérité pour les envois stockés et l'état des notifications. Les mailers de développement tels que log, array et null ne doivent pas être considérés comme des e-mails remis dans les rapports d'exploitation.

Test de bon fonctionnement opérationnel :

1. Publiez ou prévisualisez une page comportant le bloc natif contact_form.
2. Envoyez un message de test.
3. Vérifiez que le message apparaît dans /webadmin/contact-messages.
4. Examinez l'état de la notification et le détail d'échec sécurisé.
5. Examinez les totaux de protection de 30 jours et corrigez les faux positifs via le statut.
6. Exécutez php artisan contact:mail-diagnose --block=ID si la résolution du destinataire n'est pas claire.
7. Exécutez php artisan contact:mail-diagnose --send-test=operator@example.com uniquement pour une vérification contrôlée d'envoi SMTP.

WebBlocks UI Manager est un plugin interne/opérateur dédié aux opérations de publication propres au produit. Il n'est pas intégré aux paquets de runtime CMS normaux et les installations CMS ordinaires ne devraient pas l'installer. Construisez son artefact local depuis le dépôt de maintenance avec :

Téléversez le ZIP généré via System -> Plugins en tant que super administrateur, examinez le détail du plugin installé, puis activez-le explicitement. Les plugins téléversés sont installés désactivés par défaut. Les installations désactivées ou incompatibles restent inertes, et l'état de santé n'est pas contrôlé tant qu'elles sont désactivées.

Si le plugin déclare des migrations, son activation n'implique pas que la configuration soit terminée. L'écran de détail du plugin affiche Setup required / Plugin migrations pending lorsque des tables appartenant au plugin sont absentes. Utilisez l'action de super administrateur Run Plugin Migrations depuis l'écran de détail du plugin pour n'exécuter que les migrations déclarées par ce plugin installé, et uniquement depuis le chemin d'installation du plugin. L'action est idempotente, enregistre un résultat de configuration dans le fichier d'état d'activation du plugin et rapporte des erreurs exemptes de secrets. Les routes de plugins activés visibles avant la configuration doivent afficher des indications de configuration contrôlées plutôt que des erreurs de base de données brutes.

Si une installation a brièvement exécuté la v1.32.67 et créé des tables webblocks_ui_manager_*, ce correctif ne les supprime pas automatiquement. La désinstallation manuelle du plugin conserve elle aussi les tables appartenant au plugin. Laissez-les en place à moins qu'un opérateur n'ait confirmé que le plugin n'est pas nécessaire et n'effectue un nettoyage manuel distinct de la base de données, avec une sauvegarde.

Lorsqu'il est installé, activé et configuré manuellement, le plugin ajoute /webadmin/plugins/webblocks-ui-manager/releases pour les métadonnées de version de WebBlocks UI, la validation en mode simulation et la publication sur un CDN statique local. Les utilisateurs CMS super_admin peuvent ouvrir les routes des plugins activés grâce aux permissions appartenant au plugin déclarées dans le manifeste ; les rôles autres que super administrateur nécessitent des attributions explicites de permissions du plugin. Si webblocks_ui_manager_releases, webblocks_ui_manager_artifacts ou webblocks_ui_manager_publish_runs est absent, l'écran Releases affiche les indications de configuration requise et renvoie vers la configuration du plugin au lieu d'interroger des tables inexistantes. Préparez une version avec des fichiers dist locaux de WebBlocks UI :

La commande enregistre les métadonnées de la version, calcule les sommes de contrôle SHA-256 et prépare les métadonnées de manifeste pour la convention statique propriétaire public/cdn/webblocks-ui/{version}/.... Les fichiers dist attendus sont configurés par webblocks-plugins.webblocks_ui_manager.expected_dist_files et valent par défaut webblocks-ui.css, webblocks-icons.css et webblocks-ui.js.

Validez le plan de publication sans écrire de fichiers :

Appliquez la publication locale une fois la validation en mode simulation réussie :

Le flux de publication valide les chemins sources, la correspondance entre la version et le chemin cible, les fichiers dist attendus, les sommes de contrôle enregistrées, la cohérence du manifeste et l'idempotence avant toute écriture. Les fichiers existants dont la somme de contrôle correspond sont ignorés. Les fichiers existants dont la somme de contrôle diffère bloquent la publication. La cible est locale/appartenant au projet par défaut via WEBBLOCKS_UI_MANAGER_CDN_BASE_PATH=cdn/webblocks-ui ; WEBBLOCKS_UI_MANAGER_CDN_BASE_URL est une métadonnée facultative d'affichage/URL. Le flux de travail ne déploie pas vers un serveur de production externe, ne publie pas de métadonnées sur le serveur de mise à jour et ne modifie pas les URL des fichiers WebBlocks UI du core du CMS.

System -> Plugins signale séparément les états désactivé, activé, incompatible, fichiers manquants et erreur. Les plugins désactivés affichent un état de santé inactif, et non un échec. Un plugin configuré comme activé mais incompatible reste inerte : aucune route, commande, entrée de menu, permission, route de réglages, widget, fichier, déclaration de bloc ni comportement de rapport d'état de santé du plugin ne devient actif.

La désinstallation manuelle n'est disponible que pour les plugins téléversés manuellement, après leur désactivation. Elle supprime le répertoire du paquet installé appartenant au stockage ainsi que le fichier d'état d'activation, jamais les fichiers du core du CMS, les fichiers publics /cms, les fichiers de projet, les fichiers vendor ou le stockage situé hors de la racine de plugins configurée. Elle n'exécute pas de migrations destructrices et ne supprime pas les tables de base de données appartenant au plugin.

Le déploiement sur un CDN de production externe, les contrôles rapides sur CDN hébergés, le comportement générique d'installation/de mise à jour des plugins tiers, les installateurs distants arbitraires, l'installation de paquets Composer, la publication sur un serveur de mises à jour et les flux marketplace/catalogue restent intentionnellement reportés.

Backup / Restore est l'outil de récupération au niveau de l'environnement.

Les sauvegardes peuvent inclure :

• vidage de la base de données
• CMS importations gérées à partir de storage/app/public, à l'exclusion des fichiers régénérables media/transforms/ dans les nouvelles sauvegardes
• fichiers publics du site de public/site
• métadonnées de l'archive dans manifest.json

Le comportement de restauration est explicite :

• seules les sauvegardes terminées disposant d'une archive valide peuvent être restaurées
• le téléchargement de l'archive, le détail, l'éligibilité à la restauration et les actions de suppression résolvent les chemins via la même racine du disque backups et bloquent la traversée de répertoires, les échappements par liens symboliques et les chemins absolus hors de cette racine
• les fichiers d'archive manquants ou illisibles sont présentés comme des messages contrôlés dans l'administration plutôt que comme des exceptions brutes du système de fichiers
• la restauration crée d'abord une sauvegarde de sécurité préalable
• la restauration remplace la base de données actuelle
• la restauration remplace storage/app/public lorsque les fichiers téléversés sont inclus dans l'archive
• les restaurations MySQL/MariaDB exécutent l'import avec des garde-fous temporaires sur les clés étrangères et les contrôles d'unicité, de sorte que les vidages complets valides restent portables même lorsque l'ordre de création des tables diffère d'un environnement à l'autre
• les installations existantes mises à jour via System Update exécutent aussi, au besoin, des migrations de réparation appartenant au package ; cela maintient alignés des contrats de schéma tels que la clé parente pages(id, site_id) avec des sauvegardes contenant des clés étrangères page_translations à portée de site

Les nouvelles sauvegardes enregistrent excluded_upload_paths: ["media/transforms/"] dans leur manifeste de version 1. Les images originales, les pièces jointes et autres téléchargements restent dans les archives. Les variantes générées sont reconstruites lorsque le moteur de rendu en a besoin après la restauration ; les codecs absents reviennent à l'original. La reconstruction de toutes les variantes à l'avance est facultative ; voir Variantes d'images multimédias. Les anciennes versions et les anciennes archives restent restaurables, y compris les variantes mises en cache lorsqu'elles sont présentes. Les sauvegardes de même seconde ont des noms de fichiers distincts afin que l'archive de sécurité avant restauration ne puisse pas écraser sa source.

Utilisez Backup / Restore lorsque vous devez récupérer l'environnement de l'installation, et pas seulement une page.

Export / Import est l'outil de portabilité des sites.

Utilisez-le pour déplacer le contenu d'un site d'une installation à l'autre.

Les paquets de transfert de site sont stockés sur le disque du système de fichiers Laravel nommé site-transfers, qui vaut par défaut storage/app/site-transfers. Les nouvelles installations consommatrices via Composer enregistrent ce disque automatiquement et webblocks:install prépare le répertoire de stockage : les applications hôtes n'ont donc pas besoin de modifier config/filesystems.php, sauf si elles souhaitent fournir un disque personnalisé.

Les imports de site exigent que les catalogues de types de bloc et de types de slot adossés à la base de données de l'installation cible contiennent les lignes référencées par le paquet. Les nouvelles installations via Composer alimentent ces catalogues pendant webblocks:install, la maintenance explicite du catalogue peut réparer les lignes fournies avec webblocks:catalog-repair, et l'exécuteur d'import effectue une synchronisation finale idempotente du catalogue de base avant validation lorsqu'un paquet référence une ligne de base fournie manquante. Si un paquet référence un bloc ou un slot personnalisé propre à une installation absent de la cible, l'erreur d'administration énumère les identifiants manquants exacts.

Le flux de travail d'administration comporte désormais deux points d'entrée liés :

• Admin -> Sites comprend une action de ligne Export par site qui ouvre une fenêtre pour le site sélectionné, affiche le nom et l'identifiant du site et peut inclure les fichiers médias avant de créer le paquet.
• Admin -> Maintenance -> Export / Import est l'écran opérationnel combiné pour l'historique et les actions de transfert. Il affiche ensemble Site Exports et Site Imports, avec les actions Run Export et Run Import dans les en-têtes des cartes de liste concernées.
• L'écran de revue d'import conserve l'action sur le paquet validé juste sous le résumé de statut et de manifeste, puis affiche les décomptes du paquet dans un tableau compact pour une lecture plus rapide.
• Les nouvelles installations consommatrices via Composer affichent les écrans Export / Import depuis l'espace de noms de vues du package : elles n'exigent donc pas de fichiers Blade à la racine resources/views/admin/site-transfers/*.

Relation entre les outils :

• L'action Export de la ligne Sites crée un paquet pour un seul site sélectionné et revient à la liste des sites avec un message de succès.
• Export / Import gère l'historique des paquets et constitue l'écran principal des opérations d'export ou d'import.
• Sites -> Promote applique un paquet d'export ou de promotion à un site cible existant, avec simulation, stratégie, sauvegarde de sécurité et règles de conservation.

Export / Import couvre le contenu à portée de site, notamment :

• l'enregistrement du site et les affectations de langue (locale)
• les variables de site stockées dans site_variables
• les pages et les traductions de page
• les ressources de page stockées dans page_assets
• les slots et les blocs
• les Shared Slots et leurs arbres de blocs
• les réglages de Page Layout au niveau de la page, tels que default et docs (toujours stockés en interne sur public_shell)
• les traductions de bloc
• les éléments de navigation, y compris les slugs d'icône facultatifs utilisés par les moteurs de rendu publics de Sidebar Navigation
• les fichiers médias facultatifs
• les fichiers canoniques de surcharge publique au niveau du site situés à public/site/{site_handle}/css/site.css et public/site/{site_handle}/js/site.js lorsque Include media files est activé et que ces fichiers existent

Les Page Assets circulent dans la portabilité de site sur deux couches :

• les lignes page_assets sont toujours incluses dans les charges utiles d'export et d'import de site.
• Lorsque Include media files est activé, les fichiers publics /site/... référencés sont eux aussi empaquetés dans l'archive d'export et restaurés dans public/site/... à l'import.
• Lorsque Include media files est désactivé, les métadonnées des ressources de page sont tout de même importées, mais les fichiers physiques référencés doivent déjà exister sur l'installation cible.
• Dans la version actuelle, les fichiers de ressources de page manquants sont signalés pendant l'export et ignorés, plutôt que de faire échouer la construction complète du paquet.

Les ressources publiques de surcharge au niveau du site sont volontairement plus limitées que les Page Assets : seuls css/site.css et js/site.js sous l'identifiant du site source sont inclus, et l'import les restaure sous l'identifiant du site cible final. Les arborescences public/site/... arbitraires, les ressources du cœur du CMS et public/storage ne font pas partie de ce chemin.

Les Shared Slots sont exportés et importés comme du contenu de site à part entière :

• Les métadonnées de Shared Slot telles que l'identifiant, le nom, la compatibilité de slot, la compatibilité de coque et l'état actif sont incluses dans le paquet.
• Les Shared Slots peuvent aussi porter une contrainte facultative de compatibilité avec un Page Layout. Le champ stocké reste public_shell pour des raisons de rétrocompatibilité, une valeur vide reste générique et les valeurs non vides exigent toujours une correspondance exacte de l'identifiant de Page Layout.
• Les arbres de blocs des Shared Slots, leur ordre imbriqué, leurs traductions et leurs références média passent par la même chaîne d'empaquetage de blocs et de médias que les pages normales.
• Les slots de page qui utilisent shared_slot exportent une référence stable à l'identifiant du Shared Slot et sont réassociés au Shared Slot importé du site cible lors de l'import.
• Les charges utiles de page conservent le Page Layout de chaque page, de sorte que les pages à coque docs conservent après import des affectations de Shared Slot de documentation compatibles.
• Les définitions de Page Layout et de Page Layout Slot au niveau de l'installation ne font pas partie de l'export/import de site en V1.
• Les identifiants public_shell personnalisés des pages sont tout de même transférés avec la charge utile de la page : les installations cibles doivent donc fournir des identifiants de Page Layout correspondants lorsqu'elles s'appuient sur des layouts personnalisés.
• Si aucun identifiant de Page Layout correspondant n'existe sur l'installation cible, le rendu public bascule sur une solution de repli sûre.
• Les pages sources masquées des Shared Slots restent internes et ne sont pas traitées dans le paquet comme des pages ordinaires visibles par les utilisateurs.
• L'historique des révisions de Shared Slot est exclu de l'export/import, conformément à la limite actuelle de portabilité des révisions de page.

Les variables de site sont également du contenu de site portable :

• les lignes site_variables sont exportées et importées avec le paquet du site.
• Les clés, libellés, valeurs, ordre de tri et état d'activation des variables sont préservés.
• Le comportement des jetons publics n'est pas évalué pendant l'export ou l'import ; les valeurs brutes sont transférées telles qu'elles sont stockées.

Il n'inclut pas les données d'exécution globales à l'installation telles que les utilisateurs, les sauvegardes, l'historique des mises à jour, les sessions ou les envois de formulaire de contact.

Il n'exige pas non plus l'index de recherche public dérivé comme contenu portable :

• public_search_index est une donnée dérivée à l'exécution
• les charges utiles d'export/import n'ont pas besoin des lignes de recherche pour recréer le site
• utilisez php artisan search:rebuild après l'import lorsque vous avez besoin de lignes de recherche fraîches immédiatement

L'import JSON d'une seule page est le flux de travail d'administration à portée de page permettant de créer une nouvelle page à partir d'un fichier JSON.

• chemin d'administration : Admin -> Pages -> Import Page
• portée : une nouvelle page dans un site sélectionné
• schéma : webblocks.cms.page.v1
• résultat : en V1, crée toujours une nouvelle page en brouillon
• en V1, il ne met pas à jour une page existante
• il n'importe pas l'historique des révisions de la page source
• il ne remplace pas le flux Export / Import au niveau du site

Ce que la V1 importe :

• les champs de base de la page nécessaires à la création du brouillon, y compris le Page Layout au niveau de la page
• les traductions de page indexées par code de langue pour les langues activées sur le site cible
• les slots de page, y compris les références shared_slot par identifiant de Shared Slot compatible du même site
• les arbres de blocs appartenant à la page, avec l'ordre imbriqué parent-enfant
• les lignes de traduction de bloc prises en charge pour les familles de blocs traduisibles
• les métadonnées de ressources de page pour les chemins locaux /site/... valides de CSS et JS

Contraintes de la V1 :

• les conflits de chemin traduit sur le site cible bloquent l'import avant toute écriture
• les références de Shared Slot doivent déjà exister sur le site cible et être compatibles par site, état actif, coque et nom de slot
• l'importateur ne crée pas de Shared Slots automatiquement
• les valeurs de schéma non prises en charge sont rejetées explicitement
• l'importateur est transactionnel et ne laisse aucune page partielle en cas d'échec de la validation

Consultez docs/examples/page-import-v1.json pour la charge utile d'exemple.

La promotion de site est le flux de travail fondé sur des paquets qui promeut du contenu appartenant à un site depuis un paquet source vers un site cible existant.

Utilisez-la lorsque :

• le site cible existe déjà
• du contenu appartenant au site nécessite une promotion contrôlée vers ce site
• les données au niveau de l'installation, propres à l'environnement et d'exécution en direct doivent être préservées

En quoi elle diffère des autres outils :

• Export / Import crée ou gère des paquets de transfert de site et crée par défaut un nouveau site local à partir d'un paquet
• La promotion de site applique le contenu d'un paquet à un site cible existant
• Le clonage de site duplique du contenu appartenant au site à l'intérieur de l'installation actuelle, sans paquet
• Backup / Restore relève de la récupération d'environnement et peut remplacer la base de données actuelle ou les fichiers téléversés
• Les mises à jour modifient le code du produit CMS et la version installée, pas le contenu appartenant au site

Flux de travail de la V1 :

• chemin d'administration : Admin -> Sites -> Promote
• commandes : site-promotion:inspect, site-promotion:dry-run, site-promotion:apply
• la simulation est obligatoire avant l'application
• l'application crée d'abord une sauvegarde de sécurité normale
• l'application reconstruit les lignes de recherche dérivées du site cible après réussite

Les zones préservées comprennent :

• les utilisateurs et les rôles
• les sessions, le cache, les jobs et les files d'attente
• les sauvegardes et l'historique des mises à jour
• les rapports de visiteurs et les envois de formulaire de contact
• les domaines en production et les enregistrements de domaine de site
• la configuration d'environnement, les secrets d'installation et les jetons internes
• les lignes dérivées de public_search_index

Stratégies prises en charge :

• additive_update : crée le contenu source manquant et met à jour le contenu cible correspondant sans supprimer le contenu supplémentaire de la cible
• mirror : crée et met à jour le contenu source correspondant, puis archive, désactive ou supprime le contenu absent appartenant au site cible lorsque cela est sûr en V1

Les flux de migration et d'import de sites web propres à une installation relèvent de project/, pas du cœur du CMS.

La recherche V1 ajoute un écran opérationnel et une commande au niveau de l'installation pour l'index de recherche public dérivé.

• écran d'administration : Admin -> Maintenance -> Search Rebuild
• commande de reconstruction : php artisan search:rebuild

L'écran Search Rebuild passe en revue la couverture de l'index de recherche public dérivé pour les pages publiées, par site et par langue, et peut reconstruire l'index en toute sécurité lorsque les lignes dérivées doivent être rafraîchies.

Portées de reconstruction prises en charge :

• l'installation entière
• un site avec --site=
• une langue avec --locale=
• une page avec --page=

La reconstruction de la recherche n'est pas destructive :

• elle supprime et recrée uniquement les lignes dérivées dans la portée demandée
• elle ne modifie pas le contenu des pages, blocs, traductions, Shared Slots ni médias
• elle n'exige pas de commandes destructrices de réinitialisation de la base de données

System Settings est l'écran compact de configuration au niveau de l'installation. Les groupes modifiables sont répartis en cartes distinctes et ciblées, dotées de leurs propres actions d'enregistrement ; Runtime Information est en lecture seule.

Il conserve :

• Project Name et Project Tagline pour le contexte de l'installation, côté administration uniquement
• la langue (locale) par défaut
• fuseau horaire, qui est la valeur par défaut à l'échelle de l'installation et la solution de secours pour tout site qui ne définit pas le sien
• le nombre de lignes par page des listes d'administration, pour les écrans de liste paginés
• le mode CMS Mail et les réglages de messagerie personnalisés pour les notifications appartenant au CMS
• les réglages de la bannière de cookies ou de confidentialité
• les informations de version du produit
• les informations d'environnement

Il ne contrôle pas :

• les libellés de marque fixes de l'administration WebBlocks CMS
• l'image de marque du site public
• les valeurs SEO par défaut du site public
• la favicon publique, la portée de la recherche publique ou le SEO des traductions de page
• la messagerie d'authentification hôte/racine ou l'acheminement du formulaire de contact du site
• le contenu du fichier .env ou les variables d'environnement

Project Identity aide à distinguer une installation du CMS d'une autre dans la barre supérieure d'administration et dans le titre du navigateur. Ces valeurs destinées au public restent portées par chaque site ou traduction de page.

Admin listing rows per page vaut 15 par défaut, accepte des valeurs numériques personnalisées telles que 10 ou 12, et ne modifie que le nombre de lignes par défaut utilisé par les écrans de liste paginés de l'administration. Cela n'affecte pas la pagination publique.

CMS Mail utilise par défaut la configuration de messagerie de l'environnement Laravel. Lorsque le mode est basculé sur les réglages personnalisés du CMS, les e-mails de réinitialisation de mot de passe appartenant au CMS et les futures notifications système appartenant au CMS utilisent les réglages de messagerie du CMS stockés en base via un mailer CMS dédié. Les champs de messagerie personnalisés ne s'affichent que lorsque le mode de messagerie personnalisée du CMS est sélectionné. Les réglages de messagerie personnalisés du CMS n'écrasent pas .env ; désactiver la messagerie personnalisée du CMS ramène la messagerie du CMS à la configuration MAIL_* existante de Laravel. Les secrets de messagerie stockés ne sont jamais affichés en clair, les mises à jour avec un secret vide conservent la valeur stockée, et les diagnostics ne rapportent les champs sensibles que comme configurés ou non configurés. Les diagnostics SMTP personnalisés avertissent désormais lorsque les réglages d'envoi requis sont incomplets ou invalides, et les échecs d'envoi du courrier de réinitialisation de mot de passe renvoient une erreur de messagerie CMS contrôlée en ne journalisant qu'un contexte technique exempt de secrets. Le tableau de diagnostics comprend une action Send Test Email réservée aux super admins, qui envoie un simple message système du CMS par le même chemin de résolution de messagerie du CMS que le courrier de réinitialisation de mot de passe appartenant au CMS, sans inclure de secrets, de jetons de réinitialisation ni de vidages bruts de configuration.

Site Clone duplique le contenu appartenant à un site vers un autre site au sein de la même installation.

Utilisez Site Clone lorsque :

• vous avez besoin d'un second site dans l'installation actuelle
• vous voulez dupliquer la structure des pages, des slots, des blocs, de la navigation et des langues (locales) sans créer d'abord un paquet d'export
• vous voulez que les Shared Slots et les affectations de slots de page adossées à des Shared Slots suivent le site cloné

Site Clone est différent d'Export / Import :

• Site Clone fonctionne à l'intérieur de l'installation actuelle
• Export / Import sert à déplacer un paquet de site d'une installation à une autre
• Site Clone comme Export / Import incluent les Shared Slots, les arbres de blocs des Shared Slots, les traductions, les références de médias et les réglages de Page Layout au niveau de la page, tout en remappant les slots de page consommateurs vers les Shared Slots du site cible plutôt que de laisser des références inter-sites
• Site Clone comme Export / Import incluent également les site_variables propres au site.
• L'historique des révisions des Shared Slots n'est pas cloné, conformément à la limite actuelle du clonage des révisions de page.

• une page doit être restaurée
• vous avez besoin d'une récupération éditoriale dans l'installation actuelle

• l'environnement doit être récupéré
• la base de données ou les fichiers téléversés doivent être restaurés ensemble

• un site doit être déplacé vers une autre installation
• vous avez besoin d'un paquet portable pour un site

• vous devez dupliquer un site vers un autre site au sein de la même installation
• vous voulez garder le travail dans l'environnement actuel

• vous appliquez une version publiée du CMS à l'installation actuelle

• les mises à jour, les sauvegardes, la restauration et les outils de transfert de site sont des fonctionnalités au niveau de l'installation
• les pages, les médias, la navigation et le flux de travail éditorial sont avant tout des fonctionnalités de contenu propres au site
• les utilisateurs sont des comptes au niveau de l'installation, même lorsque certains rôles sont restreints aux sites qui leur sont assignés
• l'empaquetage des versions et la préservation des chemins installés sont deux sujets distincts : les versions ne livrent pas project/, tandis que le contenu de project/ déjà installé est préservé d'une mise à jour à l'autre

Visitor Reports dérive désormais un graphique temporel, une comparaison de période précédente de longueur égale, une couverture de mesure et des modalités de détails de page à partir des enregistrements existants. Il n'ajoute pas de scripts publics, de cookies, d'identifiants, d'événements ou de transferts tiers. Les décisions de consentement existantes continuent de régir la collecte d’identifiants.

• Les graphiques remplissent les jours manquants avec aucune vue enregistrée. Les plages de plus de 90 jours utilisent des compartiments de plusieurs jours de taille égale, étiquetés dans le graphique et le tableau de valeurs accessibles, ouverts avec le bouton de valeurs du graphique dans un modal WebBlocks UI. Les dates utilisent le même calendrier d'application/base de données que les rapports existants.
• La période précédente se termine immédiatement avant la période sélectionnée. Un total précédent nul n’a aucun changement en pourcentage. Les périodes comprenant des dates d'aujourd'hui ou des dates futures sont qualifiées de provisoires. Les décomptes décrivent les enregistrements conservés, et non la preuve que le suivi était continuellement actif ou qu'une période historique vide n'avait aucun visiteur.
• La couverture est la part des vues avec un identifiant basé sur le consentement utilisable dans les enregistrements détaillés conservés. Il ne s'agit pas d'un taux d'acceptation du consentement. Les estimations de visiteurs/sessions décrivent ce sous-ensemble et ne constituent pas des décomptes vérifiés de personnes.
• L'état du suivi affiche le dernier enregistrement détaillé dans la portée du site sélectionné accessible, indépendamment des filtres de date, de paramètres régionaux et de trafic. Il ne prétend pas que le planificateur est en cours d'exécution ou que les enregistrements absents prouvent un échec de suivi.
• Les lignes de contenu ouvrent WebBlocks UI modaux avec les totaux de page/site/locale et les répartitions indépendantes des appareils/référents. Une répartition entière est masquée si un groupe a moins de cinq vues, évitant ainsi la soustraction directe d'une cellule supprimée. Il s’agit d’une garantie d’affichage et non d’une garantie d’anonymisation. Aucun trajet individuel n'est ajouté. Les dix plus grands groupes sont affichés lorsqu'une ventilation est disponible.

Le rapport suit le contrat de barre de filtre étiqueté WebBlocks UI, avec des mesures récapitulatives au-dessus du graphique et des onglets de rapport détaillés en dessous. La couverture des mesures, l'état de suivi, le contexte de confidentialité et la politique de conservation sont disponibles dans le modal Rapport d'informations. Les notifications de migrations manquantes, de nettoyage désactivé et d’enregistrements archivés restent visibles sur le rapport lui-même.

Le graphique utilise le composant groupé WebBlocks UI 2.26.0 wb-chart et la table visitor-chart-data du modal comme source. Les attributs numériques contiennent des décomptes non formatés ; les cellules visibles conservent un formatage localisé. UI possède SVG le dessin, les axes, le redimensionnement et l'interaction au clavier ; CMS conserve les requêtes, les autorisations, la confidentialité et l'agrégation. Aucune bibliothèque de graphiques externe ni collection de visiteurs supplémentaire n'est introduite.

Le package enregistre visitors:cleanup quotidiennement dans le planificateur 03:45 à Laravel. L'hôte doit exécuter son planificateur normal ; aucune demande publique n'effectue le nettoyage. La commande planifiée et la commande manuelle partagent un verrou de cache atomique. Utilisez un cache partagé avec verrouillage lors de la planification sur plusieurs serveurs.

Il s'agit de valeurs par défaut du produit, et non d'exigences légales de conservation ou d'une certification de conformité légale. Les propriétaires de sites peuvent choisir des périodes plus courtes en fonction de leurs besoins. Les installations existantes avec un planificateur fonctionnel commencent à appliquer cette stratégie une fois la nouvelle migration et le nouveau code installés. Il n’y a aucune suppression à l’intérieur de la migration elle-même.

Prévisualisez et exécutez localement sur l'hôte :

Le nettoyage s'exécute même lorsque la collection de nouvelles visites est désactivée. La désactivation de la collecte ne doit pas laisser les identifiants historiques stockés indéfiniment. La désactivation du nettoyage lui-même est indiquée sur le rapport. Les migrations récapitulatives manquantes bloquent le nettoyage sans supprimer les enregistrements et laissent les rapports existants opérationnels.

Les enregistrements expirés sont remplacés de manière transactionnelle, un jour à la fois, par des lignes en wbcms_visitor_daily_totals : site, paramètres régionaux (zéro pour inconnu), jour, vues totales et vues du robot. Ils ne conservent aucun chemin de page, référent, campagne, appareil, heure exacte de visite, IP hachage ou identifiant de session. Les enregistrements en retard sont fusionnés une fois dans les totaux existants. Les enregistrements plus anciens que l'horizon de conservation total, les enregistrements sans date et les enregistrements expirés dont le site a été supprimé sont supprimés sans cumul. La suppression d'un site supprime également ses totaux quotidiens. Les sauvegardes existantes ont leur propre cycle de vie de conservation ; cette commande ne réécrit pas les archives de sauvegarde.

Les totaux principaux, le graphique et la comparaison combinent les détails conservés avec les totaux quotidiens et préservent l'autorisation du site ainsi que les filtres de site/localité/trafic. Les totaux des robots incluent les deux sources. Les tableaux détaillés et les métriques de session utilisent uniquement les enregistrements détaillés restants ; un avis explicite explique la différence lorsqu'une période comprend des cumuls. Les visiteurs ou sessions uniques quotidiens ne sont délibérément pas additionnés sur plusieurs jours. Le rapport ne reconstitue jamais les historiques des visiteurs à partir des résumés conservés.

Les nouvelles installations et les migrations de mises à jour d'installations existantes créent toutes deux le tableau des totaux. Exécutez le flux normal de migration/mise à jour du package avant d’activer le nettoyage programmé. De nouvelles chaînes d’informations sont disponibles en anglais et en turc ; d'autres paramètres régionaux d'administration utilisent l'anglais normal lorsqu'une traduction d'informations n'est pas disponible.