Correction des réponses 404 pour les images versionnées dans Experience Edge / Blogs / Perficient

Introduction 📖

Mon équipe et moi avons récemment rencontré un problème alors que nous travaillions sur un projet Sitecore XM Cloud qui s’est avéré assez intéressant. Le problème était lié au fait que les images publiées sur Experience Edge ne se chargeaient pas comme prévu dans certains rendus. Les requêtes GET pour ces images dans Experience Edge renverraient un 404 code d’état plutôt que le code attendu 200. Ce problème ne semblait se produire que pour les images récemment mises à jour et les nouvelles images récemment publiées sur Experience Edge. De plus (et cela prête à confusion), des images plus anciennes et existantes (qui n’étaient pas récemment publié) toujours chargé comme prévu.

Pour le contexte, notre solution XM Cloud propose une application principale Next.js hébergée sur Vercel en utilisant la version Next.js 12.2.5 et @sitecore-jss/sitecore-jss-nextjs version 21.0.0. Notre solution utilise exclusivement la langue anglaise (en).

Enquête 🔎

Après avoir exclu les éléments typiques comme s’assurer que tout a été publié (et republié), vérifier les associations aux éléments de source de données, vérifier la réponse GraphQL du service de mise en page et même vider le cache Experience Edge, nous avons choisi d’ouvrir un ticket avec Sitecore. Je voulais voir si d’autres membres de la communauté Sitecore avaient vécu quelque chose de similaire, j’ai donc posé une question dans la communauté Sitecore Slack et j’ai finalement créé un message correspondant. question sur Échange de pile Sitecore.

Pendant que le ticket Sitecore mijotait, notre équipe a continué à dépanner les URL des images. L’URL provenant du service de mise en page ressemblait à ceci (à titre d’exemple) :

https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?h=495&iar=0&w=692&sc_lang=en ✅(200)

D’accord, cool ; cette URL a été résolue lors de la navigation directe. En regardant le balisage rendu sur les pages problématiques, il a été noté que seuls les composants utilisant des images réactives (référence) a exposé le problème. Le Image composant (du @sitecore-jss/sitecore-jss-nextjs forfait) comprend une propriété, srcSet, pour prendre en charge les images réactives. Le rendu <img> la balise ressemblait à ceci :

<img ... width="692" height="495" class="img-responsive" loading="lazy" srcset="https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?mw=991 991w" src="https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?h=495&amp;iar=0&amp;w=692&amp;sc_lang=en">

Le src L’URL de l’attribut a été résolue comme prévu. Cependant, le srcset Attribut d’URL associé au 991 largeur n’a pas résoudre comme prévu :

https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?mw=991 ❌(404)

Fait intéressant, après avoir ajouté manuellement le sc_lang paramètre à l’URL, il a fait résoudre comme prévu :

https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?mw=991&sc_lang=en ✅(200)

Pourquoi serait sc_lang être obligé de récupérer des images alors que cela ne l’était pas auparavant ? Eh bien, le support Sitecore avait une réponse : une correction de bug affectant versionné des éléments multimédias ont récemment été déployés sur Experience Edge. En regardant le journal des modifications de XM Cloud (ici), JE pense ce était la mise à jour spécifique ; cependant, je n’en suis pas sûr car il y a plusieurs entrées apparemment adjacentes dans le journal des modifications.

Si languageEmbedding est réglé sur jamais dans le urlbuilder.config déposer, mediaItem les entités renvoient désormais le sc_lang paramètre.

Le changement tel qu’expliqué par le support Sitecore :

[In Experience Edge] Lorsqu’un élément multimédia est publié, un MediaItem l’entité est générée par la méthode suivante sur CM : Sitecore.ExperienceEdge.Connector.EntityGenerator.MediaDeliveryEntityGenerator.GenerateMediaEntity(...)

Ce MediaItem l’entité comporte plusieurs champs contenant des URL et des chemins d’accès aux médias.

Pour les éléments multimédias versionnés, chacun de ces champs doit contenir le sc_lang paramètre.

Sortie nette : Depuis environ 2 mois, si vous le souhaitez versionné images publiées sur Experience Edge pour se charger correctement, vous avoir pour inclure le sc_lang paramètre. Experience Edge n’est pas par défaut en et n’inclut pas de solution de secours dans le cas contraire, si sc_lang n’est pas présent, vous obtiendrez un 404.

Ce changement, associé au fait que le Image composant dans le @sitecore-jss/sitecore-jss-nextjs emballer se déshabille le sc_lang paramètre lors de la résolution des différents srcset Les URL signifiaient que nos images versionnées utilisées comme images réactives ne se chargeaient pas correctement sur le front-end.

C’était en quelque sorte une tempête parfaite compte tenu des éléments suivants :

• Le correctif Experience Edge pour les éléments multimédias versionnés a probablement été publié fin février.
• Notre équipe de développement et les auteurs de contenu n’avaient pas mis à jour, ajouté ou publié des éléments multimédias depuis un certain temps, le problème n’a donc pas été immédiatement remarqué. En d’autres termes, peu d’images versionnées ont été publiées sur Experience Edge.
• Le Image Composants srcSet la propriété était utilisée, ce qui transformait en conséquence l’URL provenant du service de mise en page, mais, ce faisant, supprimait le (maintenant requis) sc_lang paramètre. 😑

La solution ⛑

Forts de la connaissance qu’à l’avenir, les images versionnées publiées sur Experience Edge exiger le sc_lang paramètre, j’ai commencé à implémenter un correctif pour nos rendus en utilisant le srcSet propriété du Image composant. J’ai fini par créer une petite fonction d’assistance pour faire abstraction de l’analyse de la chaîne de requête et de l’inclusion conditionnelle du sc_lang paramètre dans le tableau passé dans le srcSet propriété (comme recommandé par le support Sitecore). La fonction d’assistance ressemblait à ceci :

export const buildSrcSetParams = (imageSizeParameters: ImageSizeParameters[] | undefined, image: ImageField): ImageSizeParameters[] | undefined => {
  let retVal = imageSizeParameters;
  if (!image?.value?.src) {
    return retVal;
  }
  const queryParams = new URLSearchParams(image.value.src.split('?')[1]);
  const scLangParam = queryParams.get('sc_lang');
  if (retVal && scLangParam) {
    // add sc_lang parameter
    retVal = retVal.map((isp) => ({
      ...isp,
      sc_lang: scLangParam,
    }));
  }
  return retVal;
};

Auparavant, le Image les composants ressemblaient à ceci :

<Image field={props?.fields?.Image} srcSet={ [ { mw: 991 } ] } ... />

En utilisant la nouvelle fonction d’assistance, ils ressemblaient à ceci :

<Image field={props?.fields?.Image} srcSet={buildSrcSetParams([ { mw: 991 } ], props?.fields?.Image) } ... />

Maintenant, au lieu du srcset URL résolue en :

https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?mw=991 ❌(404)

Il a résolu de :

https://edge.sitecorecloud.io/<tenant>/media/foo.jpg?mw=991&sc_lang=en ✅(200)

Pensées finales 💭

De toute évidence, devoir apporter, tester et déployer une modification de code en production en réponse à un correctif de bogue Experience Edge n’était pas génial. On peut soutenir que Experience Edge reviendrait à une langue par défaut configurable (par exemple en) ou vers une image non versionnée, si disponible.

Depuis le 17/04/2024, le support Sitecore a confirmé que ce scénario était reproductible en utilisant la version 21.6.0 de la @sitecore-jss/sitecore-jss-nextjs package et que l’équipe produit examinerait plus en détail.

Le 23/04/2024, le support Sitecore a reconnu ce problème comme un bug et a émis un numéro de référence : JSS-1902.

Les produits SaaS de Sitecore tels que XM Cloud et Experience Edge évoluent et s’améliorent constamment, ce qui est formidable ; en fait, c’est un argument de vente majeur lorsqu’il s’agit d’adopter XM Cloud. Idéalement, notre équipe aurait eu connaissance ou aurait été informée de ce changement radical à l’avance. Comment aurions-nous fait cela ? Je ne suis pas sûr, sauf peut-être en suivant d’un peu plus près le journal des modifications de XM Cloud 😅.