Fermer

mai 13, 2022

Options de publication de page optimisées – À faire et à ne pas faire

Options de publication de page optimisées – À faire et à ne pas faire


La publication de page est la fonctionnalité la plus basique d’un CMS. C’est ce qui rend notre contenu visible au monde. Episerver CMS (maintenant connu sous le nom d’Optimizely Content Cloud) a également la fonctionnalité et une plus grande flexibilité construite autour d’elle pour aider nos auteurs de contenu. Il y a la publication de page habituelle, où vous appuyez sur un bouton et c’est là. Et il est également possible de planifier la publication d’une page afin qu’elle soit ouverte au monde à un moment précis à l’avenir, sans nécessiter d’intervention manuelle.

Pour aller un peu technique, la façon dont la page Publier fonctionne – il y a un CommencerPublier propriété sur la Page. Lorsque les auteurs cliquent sur Publier, il s’agit de la date qui est définie sur maintenant et lorsque le navigateur tente de rendre une page, il s’agit de la propriété examinée par Episerver en interne pour voir si la page a été publiée ou non.

Lors de la planification d’une page pour la publication, les auteurs choisissent généralement une date/heure dans le futur et celle-ci est stockée dans le DelayPublishJusqu’à propriété sur le type de contenu de la page. A ce moment, pour une toute nouvelle page, le StartPublish est nul. Alors maintenant on attend.

EPiServer a une tâche planifiée intégrée appelée « Publier la version de contenu retardée« , programmé par défaut pour s’exécuter toutes les heures. Ce que fait cette tâche, c’est examiner les contenus dont la date DelayPublishUntil est définie et, le cas échéant, une date passée et qui n’est pas encore publiée, la tâche publie ensuite ce contenu. Ce faisant, il copie essentiellement la date DelayPublishUntil dans la propriété StartPublish maintenant. Et puisque c’était dans le passé, maintenant, lorsque l’utilisateur navigue sur la page, il la voit comme une page publiée.

Tout est super, fonctionne comme prévu. Les deux options ont un résultat final clair.

Cependant, je suis récemment tombé sur une situation où j’ai découvert que nos auteurs de contenu avaient en fait joué avec la propriété Publié sur la page, pour la planifier pour l’avenir. Au début, ça n’avait pas de sens pour moi, mais ensuite j’ai creusé un peu plus. La propriété Publié est essentiellement la date StartPublish. Ainsi, lorsque vous modifiez cela, vous modifiez la date de début de publication de la page. Donc, si c’est une toute nouvelle page et que je fixe la date de publication à une date future et que je clique sur Publier, cela planifie essentiellement la page pour une publication future. Seulement cette fois, je n’ai pas besoin d’attendre un travail pour publier la page. Dès que cette future date de StartPublish arrive, elle est disponible.

SS1

Ce fut une révélation. Je me suis littéralement demandé pourquoi nous ne l’utilisons pas pour planifier la publication ? Pourquoi avons-nous besoin d’attendre un emploi pour le faire? Eh bien, je devais trouver les réponses, alors j’ai dépanné un peu plus.

J’ai choisi une page que je venais de publier et j’ai modifié sa date de publication à 5 minutes dans le futur. Quand j’ai regardé dans CMS DB sous tblWorkContent pour cette page, il n’a pas réellement modifié la date de début de publication de la page existante. Il a plutôt créé une nouvelle version de la page et qui a obtenu la valeur de date StartPublish modifiée. Techniquement, c’est le bon comportement. Chaque fois que vous modifiez une page existante, une nouvelle version est créée.

SS2

Maintenant, je continue et je clique sur publier sur cette page, puis je parcours la page sur le site. Que pensez-vous que j’ai vu ?

SS3

j’ai un erreur 404 Au lieu. Techniquement, cela signifie que cette page que j’essaie de parcourir n’existe pas ou n’est pas disponible. Mais ma page était déjà publiée alors que s’est-il vraiment passé ? Eh bien, ce qui s’est passé, c’est dès que j’ai édité la page et créé la nouvelle version et cliqué sur Publier, c’est la version qui sera récupérée lorsque je navigue. Et comme mentionné ci-dessus, lors de la tentative de rendu, Episerver regarde la date de StartPublish. Mais maintenant, dans cette version, ma date de StartPublish est de 5 minutes dans le futur. Elle est donc traitée comme une page non publiée, et donc la 404.

Si je fais la même chose en utilisant l’option Programmer pour publier et que la nouvelle version soit publiée 5 minutes plus tard, ma page sera toujours accessible pour la navigation. Pourquoi? Parce que maintenant, lorsque la nouvelle version a été créée, elle a copié la date StartPublish existante de la version précédente et a défini une date DelayPublishUntil à 5 ​​minutes dans le futur. Maintenant, le travail gérera la publication au moment opportun et mettra à jour le StartPublish. Jusque-là, les utilisateurs finaux peuvent toujours parcourir la version originale.

SS4

Qu’ai-je appris de cet exercice ? Ne jouez pas avec la date StartPublish directement. Cela peut avoir des implications inattendues. Et c’est pourquoi il existe une fonction de planification dédiée conçue pour gérer les planifications avec élégance et sans affecter les pages existantes lors de la navigation.

J’espère que cela t’aides!

A propos de l’auteur

Ritu Madan est un développeur certifié Optimizely CMS et Commerce avec plus de 15 ans d’expérience de travail avec .net et SQL. Elle aime explorer et se tenir au courant des technologies les plus récentes et les plus avancées, des outils en ligne/hors ligne qui facilitent le travail quotidien et partagent ces connaissances.

Plus de cet auteur






Source link