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 reste le groupe d'outils opérationnels pour :

• Search Rebuild
• Backups
• Export / Import
• Update

Visitor Reports est un rapport opérationnel respectueux de la vie privée sur l'activité des pages publiques. Les vues de page anonymes peuvent être comptabilisées sans identifiants soumis au consentement. Le rapport stocke également des informations uniquement agrégées sur les référents, les campagnes, les appareils et les bots :

• 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.

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 intégré à l'application télécharge le paquet de la version, applique les règles de chemins protégés, exécute les migrations de mise à jour requises, vide 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.

La disponibilité d'une mise à jour repose sur le fait que la dernière version publiée soit plus récente que la version du code du CMS en cours d'exécution. Les exécutions de mise à jour ayant échoué par le passé et les valeurs obsolètes de version installée enregistrée restent consultables via la fenêtre modale de la dernière exécution, le rapport de support, la CLI des exécutions conservées ou Update Readiness, mais elles ne rendent pas à elles seules une installation actuelle actionnable.

L'écran affiche par défaut deux cartes : Install Update d'abord et Update Details ensuite. Install Update est la seule zone d'action principale. Lorsqu'une mise à jour compatible est disponible, elle affiche le chemin de la version actuelle vers la dernière, l'état de compatibilité, l'appel à l'action d'installation et un accordéon Package Safety Details replié. Lorsqu'aucune mise à jour n'est disponible, elle affiche un message discret indiquant que l'installation est à jour ou que le service est indisponible, et omet les détails de sécurité du paquet.

Update Details contient des lignes d'accordéon WebBlocks UI pour Release Notes, Update Readiness et Last Update Run. Update Readiness décrit l'installation actuelle et les contrôles du service de mise à jour ; il ne s'agit pas du contenu des notes de version pour la version cible. Last Update Run n'affiche sur l'écran principal que le résumé de l'exécution pertinente la plus récente, les détails étant disponibles dans une fenêtre modale. Les super administrateurs peuvent télécharger un rapport de support depuis la même carte pour les flux d'assistance en hébergement mutualisé ; le rapport évite les jetons, les secrets, les chemins locaux absolus et les traces de pile brutes, tout en incluant la version actuelle et la dernière version, l'état de préparation, les détails de la dernière exécution et les résumés des exécutions conservées.

Update History n'est plus rendu sous forme de tableau sur l'écran principal et la suppression de lignes ne fait pas partie de l'interface d'administration. Les enregistrements d'exécutions de mise à jour sont purgés automatiquement, en conservant par défaut les cinq dernières exécutions. La dernière exécution en échec est conservée jusqu'à ce qu'une exécution réussie plus récente existe. Les opérateurs disposant d'un 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 lancer une purge contrôlée avec php artisan webblocks:updates:prune-runs --keep=5.

Le client de mise à jour prend en charge des métadonnées structurées issues 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 fichiers, les notes destinées à l'opérateur et les notes techniques. Ces valeurs sont rendues sous forme de texte brut échappé, dans des groupes orientés opérateur, à l'intérieur de l'accordéon Release Notes. Les versions plus anciennes qui ne fournissent que release_notes affichent toujours ces notes correctement, et les versions sans notes affichent No release notes were provided for this release. Les contrôles de préparation, la version installée enregistrée et les valeurs de bas niveau du serveur de mise à jour restent dans Update Readiness.

La synchronisation du catalogue core ne fait plus partie de la chaîne d'application normale de System Update. Les paquets de version appliquent le code, les fichiers, les migrations de mise à jour requises, le vidage des caches, la vérification de version après application, l'historique des exécutions et la persistance de la version installée ; la réparation étendue du catalogue est un flux de maintenance explicite.

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, --slot-types, --page-layouts, --icons et --all. Il rend compte des lignes créées, mises à jour, inchangées et ignorées, préserve les lignes de catalogue personnalisées propres à l'installation et peut être exécuté à plusieurs reprises. block-types:sync-core subsiste comme commande de compatibilité de plus bas niveau pour le catalogue des types de bloc.

Les paquets de version publiés sont des paquets produit core. Ils livrent du code source CMS réutilisable, des fichiers, des migrations, des vues, des routes, de la configuration, de la documentation et des tests, mais ne livrent pas de contenu de la couche projet propre à l'installation provenant de project/.

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

release:prepare construit localement le ZIP à racine de paquet, la somme de contrôle et la charge utile destinée au publieur. release:publish-update envoie le paquet et les métadonnées au point de terminaison de publication par défaut appartenant au paquet https://publisher.webblocksui.com/api/updates/publish, puis vérifie les dernières métadonnées du serveur de mise à jour pour webblocks-cms sur le canal stable. Les sites CMS installés ne configurent pas de clés d'environnement pour le Publisher/serveur de mise à jour, le produit ou le canal dans les fichiers .env ordinaires ; le code produit du CMS possède le serveur de versions par défaut, la clé de produit, le canal stable, le chemin de la dernière version et le chemin de publication via ReleaseDefaults. En temps normal, la publication ne nécessite que WEBBLOCKS_PUBLISHER_TOKEN. Les exécutions avec configuration en cache ne rafraîchissent que ce jeton depuis le .env du projet, et les diagnostics indiquent uniquement s'il est configuré ou non. L'ancienne passerelle updates.webblocksui.com n'a plus qu'une valeur historique et ne doit pas servir de chemin de configuration actif. Les commits et les tags Git ne sont que des étapes de l'historique du code source. GitHub Actions, les releases GitHub, les URL d'assets GitHub, l'API GitHub et la CLI gh ne font pas partie de la publication des mises à jour du CMS, et les workflows .github sont volontairement absents.

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 envois du Contact Form sont enregistrés avant la remise de la notification. L'état de la notification par e-mail ne reflète que le comportement de la notification et ne modifie ni le statut éditorial ni la classification en tant que spam. Sent signifie que Laravel a accepté l'envoi via un transport de messagerie réel configuré, sans exception ; cela ne garantit pas la remise en boîte de réception. Failed signifie qu'un envoi réel a été tenté et a produit un échec assaini. Skipped ou Not configured signifie qu'aucun envoi réel n'a été tenté parce que la notification était désactivée, qu'aucun destinataire n'a été résolu, que le mailer est log, array ou null, ou que la configuration SMTP est incomplète. Le spam noté est volontairement stocké/mis en quarantaine pour examen par l'administrateur ; seuls les envois dont le champ de contrôle généré est rempli ou qui sont trop rapides peuvent être écartés avant stockage, avec la redirection de succès générique. Un futur seuil configurable tel que CONTACT_SPAM_AUTO_DISCARD_SCORE pourra être envisagé lorsque suffisamment de données de production existeront pour le régler sans risque.

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. Exécutez php artisan contact:mail-diagnose --block=ID si la résolution du destinataire n'est pas claire.
6. 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
• fichiers téléversés gérés par le CMS depuis storage/app/public
• 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

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
• le fuseau horaire
• 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