Guide complet pour activer le module complémentaire Headless Multisite pour votre solution XM Cloud / Blogs / Perficient

Le SDK Sitecore Headless Next.Js a récemment apporté la fonctionnalité qui permet d’avoir plusieurs sites Web de l’arborescence de contenu Sitecore servis par la même application JSS de levage de rendu. Il utilise Intergiciel Next.js pour servir le bon site Sitecore en fonction du nom d’hôte entrant.

Pourquoi et quand utiliser le module complémentaire multisite

Le module complémentaire Multisite est particulièrement utile dans les scénarios où plusieurs sites partagent des composants communs ou lorsqu’il est nécessaire de centraliser la logique de rendu. Il simplifie les pipelines de déploiement et réduit la complexité de l’infrastructure, ce qui le rend idéal pour les entreprises gérant un portefeuille de sites Web sous une architecture unifiée. Cette approche permet d’économiser des ressources et garantit une expérience utilisateur cohérente sur tous les sites.

Comment ça marche

L’application récupère les informations du site au moment de la constructionpas au moment de l’exécution (pour des raisons de performances). Chaque demande invoque tous Intergiciel Next.js. Étant donné que les ajouts de nouveaux sites ne sont PAS fréquents, la récupération des informations sur le site au moment de l’exécution (bien que techniquement possible) n’est pas la meilleure solution en raison de son impact potentiel sur les performances des visiteurs. Vous pouvez automatiser ce processus utiliser un webhook pour déclencher les redéploiements automatiques de votre application Next.js lors de la publication.

Sitecore fournit un schéma relativement compliqué de son fonctionnement (photo ci-dessous), mais si vous ne comprenez pas dès le premier coup d’œil, ne vous inquiétez pas, vous comprendrez après avoir lu cet article.

Mise en œuvre technique

Il y a quelques étapes à suivre pour que cela fonctionne. Commençons par l’environnement local.

Puisque le multisite fait référence à différents sites, nous devons configurer les noms d’hôtes. Le Principal le site fonctionne sur main.localhost nom d’hôte, et il est déjà configuré comme ci-dessous :

.\.env
    RENDERING_HOST=main.localhost
.\docker-compose.override.yml
    PUBLIC_URL: "https://${RENDERING_HOST}"

$renderingHost = $envContent | Where-Object { $_ -imatch "^RENDERING_HOST=.+" }
$secondHost = $envContent | Where-Object { $_ -imatch "^SECOND_HOST=.+" }
$renderingHost = $renderingHost.Split("=")[1]
$secondHost = $secondHost .Split("=")[1]

en bas du fichier, nous souhaitons également créer un certificat SSL pour ce domaine en ajoutant une ligne en bas :

& $mkcert -install
# & $mkcert "*.localhost"
& $mkcert "$xmCloudHost"
& $mkcert "$renderingHost"
& $mkcert "$secondHost"

tls:
  certificates:
    - certFile: C:\etc\traefik\certs\xmcloudcm.localhost.pem
      keyFile: C:\etc\traefik\certs\xmcloudcm.localhost-key.pem
    - certFile: C:\etc\traefik\certs\main.localhost.pem
      keyFile: C:\etc\traefik\certs\main.localhost-key.pem
    - certFile: C:\etc\traefik\certs\second.localhost.pem
      keyFile: C:\etc\traefik\certs\second.localhost-key.pem

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.rendering-secure.entrypoints=websecure"
  - "traefik.http.routers.rendering-secure.rule=Host(`${RENDERING_HOST}`,`${SECOND_HOST}`)"
  - "traefik.http.routers.rendering-secure.tls=true"
  # Add CORS headers to fix CORS issues in Experience Editor with Next.js 12.2 and newer
  - "traefik.http.middlewares.rendering-headers.headers.accesscontrolallowmethods=GET,POST,OPTIONS"
  - "traefik.http.middlewares.rendering-headers.headers.accesscontrolalloworiginlist=https://${CM_HOST}, https://${SECOND_HOST}"
  - "traefik.http.routers.rendering-secure.middlewares=rendering-headers"

Configuration de Sitecore

Attendez que Sitecore démarre, accédez à une collection de sites, cliquez dessus avec le bouton droit et ajoutez un autre site Web l’appelant Second s’exécutant sur un nom d’hôte second.localhost.

S’assurer deuxième le site utilise exactement le même nom d’application que principalvous pouvez configurer cela à partir de /sitecore/content/Site Collection/Second/Settings article, Nom de l’application champ. Cela garantit que le but de cet exercice est que les deux sites réutilisent la même application hôte de rendu.

Vous devez également vous assurer que les valeurs de Hôte de rendu d’application prédéfini domaines de /sitecore/content/Site Collection/Second/Settings/Site Grouping/Second et /sitecore/content/Site Collection/Main/Settings/Site Grouping/Main articles.

Un autre domaine important ici est Nom d’hôteassurez-vous de définir ces champs pour les deux sites Web :

Maintenant vous êtes prêt à éditer Maison article de Deuxième site. Le middleware multisite n’affecte pas le mode d’édition de Sitecore, donc à partir de là, vous ne verrez aucune différence.

Dépannage

Si vous avez tout fait correctement, mais second.localhost résout le site Web principal, résolvons les problèmes. Le tout premier endroit à vérifier est .\src\rrh\src\temp\config.js déposer. Ce fichier contient la variable sites avec le tableau de sites et les noms d’hôtes associés à utiliser pour la résolution du site. Le fait important est qu’un fichier donné est généré au moment de la constructionpas le temps d’exécution.

Donc, vous l’ouvrez et voyez un tableau vide (config.sites = process.env.SITES || '[]'), cela signifie qu’il vous suffit d’initialiser la build, par exemple en supprimant et en recréant simplement le conteneur hôte de rendu :

docker-compose kill rendering
docker-compose rm rendering -f
docker-compose up rendering -d

De plus, avant d’exécuter ce qui précède, il est utile de vérifier Responsable du site SXAqui est disponible dans la boîte à outils PowerShell dans Sitecore Desktop. Vous devez y voir les sites et les noms d’hôtes pertinents et dans le bon ordre – assurez-vous de les déplacer le plus haut possible, car cette chaîne de sites fonctionne selon le principe « premier arrivé – premier servi ».

config.sites = process.env.SITES || '[{"name":"second","hostName":"second.localhost","language":""},{"name":"main","hostName":"main.localhost","language":""}]'

DEBUG=sitecore-jss:multisite

sitecore-jss:multisite multisite middleware start: { pathname: '/', language: 'en', hostname: 'second.localhost' } +8h
sitecore-jss:multisite multisite middleware end in 7ms: {
  rewritePath: '/_site_second/',
  siteName: 'second',
  headers: {
  set-cookie: 'sc_site=second; Path=/',
  x-middleware-rewrite: 'https://localhost:3000/_site_second',
  x-sc-rewrite: '/_site_second/'
},
  cookies: ResponseCookies {"sc_site":{"name":"sc_site","value":"second","path":"/"}}
} +7ms

Par souci d’expérimentation, faisons Deuxième site Web pour utiliser les conceptions de pages du Principal site. Après l’autorisation de partage ci-dessus, ils sont automatiquement disponibles sur /sitecore/content/Site Collection/Second/Presentation/Page Designs article.

Configuration du cloud

Une fois que nous avons bien fait fonctionner le module complémentaire multisite, faisons le même travail dans le cloud.

1. Tout d’abord, vérifiez toutes les modifications apportées au référentiel de code et déclenchez le déploiement, soit depuis Deploy App, CLI ou votre CI/CD préféré.
2. Une fois vos modifications arrivées dans l’environnement XM Cloud, apportons les modifications requises à Vercel, en commençant par définir les noms d’hôte des sites :
3. Après avoir défini les noms d’hôte dans Vercel, modifiez le nom d’hôte sous Regroupement de sites élément pour cet environnement cloud particulier afin qu’il corresponde au nom d’hôte ci-dessus configuré précédemment dans Vercel.
4. Enregistrez les modifications et publiez intelligemment la collection de sites. La publication prend un certain temps, alors restez patient.
5. Enfin, vous devez également faire un redéploiement complet de Vercel, pour forcer la régénération \src\temp\config.js fichier avec les noms d’hôtes d’Experience Edge publiés à l’étape précédente

Essai

Si tout est bien fait dans les étapes précédentes, vous pouvez accéder au site Web Second publié depuis Vercel par son nom d’hôte, dans notre cas, ce serait https://dev-second.vercel.app. Assurez-vous que toutes les mises en page partielles partagées sont vues comme prévu.

Lors du test des versions 404 et 500, vous verrez qu’elles sont automatiquement partagées entre les deux sites, mais vous ne pouvez pas les configurer individuellement par site. Cela se produit parce que les deux sont situés à .\src\rrh\src\pages\404.tsx et .\src\rrh\src\pages\500.tsx de la même application hôte de rendu et utilise des mécanismes internes différents plutôt que du contenu générique servi par Sitecore tout au long .\src\rrh\src\pages\[[...path]].tsx itinéraire. Ces pages d’erreur pourraient cependant être multilingues, si nécessaire.

J’espère que cet article vous sera utile !