Ce guide traite de la migration graphique de vos chartes d'une version Ametys 4.3.x à 4.4.0.
Reportez-vous également au guide de migration technique.
Tous les appels à resolver.resolveXXX qui ont en dur le premier argument à 'metadata' doivent être modifiés pour mettre 'attribute' à la place.
Par exemple, le code suivant:
<xsl:variable name="imgPath" select="concat('illustration/image?contentId=', $orgunitId)" /> <xsl:variable name="imgUrl" select="resolver:resolveCroppedImage('metadata', $imgPath, $imgHeight, $imgWidth)"/>
devra être remplacé par:
<xsl:variable name="imgPath" select="concat('illustration/image?contentId=', $orgunitId)" /> <xsl:variable name="imgUrl" select="resolver:resolveCroppedImage('attribute', $imgPath, $imgHeight, $imgWidth)"/>
Pour retrouver ces appels, le plus simple est de rechercher 'metadata' dans toutes vos XSL.
Les événements SAX générés pour les données de type geocode ont changé. Les latitudes et longitudes sont mis dans des attributs et non plus dans des sous-noeuds.
Par exemple, le code suivant :
<xsl:variable name="geocode" select="ametys:contentAttribute(@id, 'geocode')"/> <xsl:if test="$geocode"> <marker title="{@title}" holder="{local-name()}" lat="{$geocode/latitude}" lng="{$geocode/longitude}"/> </xsl:if>
devra être remplacé par :
<xsl:variable name="geocode" select="ametys:contentAttribute(@id, 'geocode')"/> <xsl:if test="$geocode"> <marker title="{@title}" holder="{local-name()}" lat="{$geocode/@latitude}" lng="{$geocode/@longitude}"/> </xsl:if>
Suite au passage à ExtJS 7, le noyau importe FontAwesome 5 et plus FontAwesome 4 par défaut ; en conséquence, dans la partie "personnalisée" de la page de connexion au backoffice, il est possible que vous ayez perdu vos icônes.
Le plus simple si vous n'aviez pas de modification c'est de repartir du template https://code.ametys.org/projects/WEB/repos/template-web/browse/webapp/cms/WEB-INF/param/login.xsl?at=refs%2Fheads%2F4.4.x
La version compliquée c'est de changer les appels à la font FontAwesome par Font Awesome 5 Free Solid ; mais cela peut ne pas suffire si vous utilisiez des icônes de marque comme facebook... dans ce cas là, il faut charger Font Awesome 5 Brands...
En cas de doute, reportez-vous au template web https://code.ametys.org/projects/WEB/repos/template-web/browse/webapp/cms/WEB-INF/param/login.xsl?at=refs%2Fheads%2F4.4.x
Attention : risque de régression important
Notamment si vous faites du découpage de date à la volée pour des comportements très particuliers (substring).
Suite à un changement de stockage des dates, elles sont maintenant stockées en UTC et non plus dans le fuseau horaire du serveur. Ce qui signifie concrètement que si vous saisissez une date à 14:30 de notre heure d'été, elle est stockée en réalité comme 12:30 UTC. Et si c'est stocké 01:30, c'est stocké 23:30 de la veille.
La plupart des rendus actuels avec <i18n:date> ignorent les fuseaux horaires donc il peut y avoir pas mal de soucis.
Dans toutes vos XSL, il faut rechercher l'utilisation de <i18n:date> et <i18n:date-time> qui concernent des dates venant d'attributs de contenus, et prendre en compte le fuseau horaire.
Dans la pratique, ça consistera souvent à remplacer src-pattern="yyyy-MM-dd'T'HH:mm:ss" par src-pattern="yyyy-MM-dd'T'HH:mm:ss.SSSXXX".
Même procédure pour <i18n:time>.
Les types rich_text et multilingual_string ont été renommés en rich-text et multilingual-string. Recherchez et remplacez toutes les occurrences dans les XSL.
Attention, la casse est importante : les occurrence de "RICH_TEXT" doivent être remplacées par "RICH-TEXT"
Dans vos XSL l'utilisation de ametys:sitemap() doit maintenant avoir obligatoirement un argument pour limiter la profondeur:
Voir la documentation de AmetysXSLTHelper
Les chartes du noyau (ODF, Workspaces et Doc) ont été améliorées pour faciliter les surcharges des XSL.
Voir Workspaces Import des XSLs ou ODF Import des XSLs.
Depuis la 4.4.1, pour corriger un ticket bloquant, concernant les liens vers les ressources (explorateur ou pièces jointes) les liens fournis dans la balise <uri> sont déjà préfixés par le site. Il faut donc à minima retirer ce préfixe qui est ajouté par la XSL de rendu du moteur de recherche (sauf si vous utilisez les XSL noyau).
Test fonctionnel pour savoir si vous êtes impactés
Insérez un moteur de recherche, en sélectionnant le type Document.
En prévisualisation, essayez de télécharger un document renvoyé par ce moteur de recherche.
Si le lien ne fonctionne pas avec le contexte en double dans l'adresse c'est que vous êtes impactés. (par ex /cms/preview/www/cms/preview/www/_attachment/XXX.png)
Il est même recommandé de ne plus utiliser le contenu textuel de la balise <uri> mais de résoudre soit même l'adresse avec les attributs type et id fournis désormais sur <uri>.
Test technique pour savoir si vous êtes impacté
Si vous avez surchargé en XSL le template "hit-resource-title-link-href" vous êtes impactés.
Sinon vous n'êtes probablement pas affectés : vous pouvez faire le test fonctionnel ci-dessus pour être sûr.
Dans le template hit-resource-title-link-href :
Si vous aviez une surcharge dans le but de corriger le ticket CMS-9900 votre template devient simplement
<xsl:template name="hit-resource-title-link-href">
<xsl:value-of select="resolver:resolve(uri/@type, uri/@id, false())"/>
</xsl:template>
Suivant les plugins Ametys que vous utilisez, vous devez suivre les migrations graphiques propres à chaque plugin :