Skip to content

Intégration avec Umbraco

Un shop posé à côté d'un site Umbraco (en version 13 ou 17 chez nous) doit donner l'illusion d'un seul et même site. Tout le travail d'intégration consiste à partager le décor (header, footer) et à parler d'une seule voix aux moteurs de recherche (un seul sitemap, un seul robots). L'essentiel se passe du côté du projet Umbraco, qui joue le rôle de chef d'orchestre.

Le client n'a pas envie d'éditer son menu à deux endroits. On fait donc en sorte qu'il ne le touche qu'une fois, dans Umbraco, et que le shop aille le chercher.

Concrètement, on crée dans Umbraco deux pages techniques dédiées (une pour le header, une pour le footer) qui ne rendent que ce fragment de HTML, avec les inclusions CSS et JS dont il a besoin pour fonctionner. Côté nopCommerce, le thème va interroger ces pages et injecte leur contenu dans son propre gabarit. Pour découper et réinsérer ce HTML proprement, on s'appuie sur la librairie HtmlAgilityPack.

Deux points méritent ton attention, parce qu'ils se paient cher si on les rate :

  • Le routing Umbraco est convention-based. Pour que les pages techniques soient servies par le bon code, le nom du controller doit reprendre exactement le nom du doctype suivi de Controller. Si ça ne "matche" pas, Umbraco sert la page sans la logique attendue, sans erreur, et tu cherches longtemps.
  • Ces pages techniques ne doivent jamais finir dans le sitemap. Elles n'ont aucun sens pour un visiteur ni pour Google. Pense à les exclure dès leur création.

Un seul sitemap, un seul robots.txt

Pour le référencement, on veut présenter un site unique. L'idée tient en une phrase : quand Umbraco génère son sitemap.xml, il va aussi récupérer celui du shop nopCommerce et concatène les deux listes d'URL avant de répondre. Le moteur de recherche ne voit qu'un seul fichier, qui couvre le contenu éditorial et le catalogue.

Le robots.txt est servi par le même mécanisme, et il s'adapte à l'environnement : en production il pointe vers le sitemap, et partout ailleurs (staging, dev) il interdit toute indexation. C'est notre garde-fou pour qu'un site de recette ne se retrouve jamais dans les résultats de recherche.

Attention au multilingue

La récupération du sitemap du shop suppose en général une seule langue. Sur un site multilingue, c'est le point à revoir en premier : il faut aller chercher le sitemap de chaque culture.

Isoler les deux applications

Le site et le shop sont deux applications ASP.NET distinctes, mais l'une est imbriquée dans l'autre côté serveur web. Par défaut, la configuration web.config de l'application parente est héritée par l'enfant, ce qui provoque des conflits aussi pénibles qu'inattendus. On coupe cet héritage en enveloppant la configuration dans une balise prévue pour ça :

xml
<location path="." inheritInChildApplications="false">
    <system.web>
    </system.web>
    <system.webServer>
    </system.webServer>
</location>

C'est un réflexe à avoir dès qu'on monte un shop en sous-application : si tu vois des erreurs de configuration absurdes au démarrage, c'est souvent l'héritage du web.config qui s'en mêle.

Donner au client un accès Umbraco sans le perdre

Le back-office d'Umbraco contient des pages qui n'ont aucun intérêt pour le client final, à commencer par les pages techniques du shop (header, footer) qu'on vient de créer. Plutôt que de tout lui ouvrir, on crée un groupe d'utilisateur dédié avec les droits habituels d'un éditeur ou d'un administrateur, mais à qui on retire l'accès au dossier technique de nopCommerce et aux quelques pages qui n'existent que pour des raisons de plomberie. Le client a ainsi une interface propre, sans risque de casser quelque chose qu'il ne devait pas voir.

Étape suivante

Quand le shop et le site se parlent, il reste à régler la boutique elle-même : Paramétrer la boutique.

Contributors

The avatar of contributor named as Clément Favre Clément Favre

Changelog