Graphics migration 4.3 to 4.4

This guide covers the graphic migration of your charts from Ametys 4.3.x to 4.4.0.
Please also refer to the technical migration guide.

  1. Image resolution
  2. Geocode data
  3. Login page
  4. Rendering dates
  5. Renaming rich_text and multilingual_string types
  6. Using ametys:sitemap()
  7. Core skins
  8. Search engine
  9. Plugins

Image resolution

All calls to resolver.resolveXXX that hard-coded the first argument to 'metadata' must be changed to 'attribute' instead.

For example, the following code:

<xsl:variable name="imgPath" select="concat('illustration/image?contentId=', $orgunitId)" /> 
<xsl:variable name="imgUrl" select="resolver:resolveCroppedImage('metadata', $imgPath, $imgHeight, $imgWidth)"/>

should be replaced by:

<xsl:variable name="imgPath" select="concat('illustration/image?contentId=', $orgunitId)" /> 
<xsl:variable name="imgUrl" select="resolver:resolveCroppedImage('attribute', $imgPath, $imgHeight, $imgWidth)"/>

The easiest way to find these calls is to search for 'metadata' in all your XSL files.

Geocode data

SAX events generated for geocode data have changed. Latitudes and longitudes are now set in attributes rather than sub-nodes.

For example, the following code :

<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>

should be replaced by :

<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>

Login page

Following the switch to ExtJS 7, the kernel imports FontAwesome 5 and no longer FontAwesome 4 by default; as a result, in the "customized" part of the backoffice login page, you may have lost your icons.

The easiest way, if you haven't made any changes, is to start from the template https://code.ametys.org/projects/WEB/repos/template-web/browse/webapp/cms/WEB-INF/param/login.xsl?at=refs%2Fheads%2F4.4.x

The complicated version is to change the FontAwesome font calls to Font Awesome 5 Free Solid; but this may not be enough if you use brand icons like facebook... in that case, you have to load Font Awesome 5 Brands...

If in doubt, refer to the web template https://code.ametys.org/projects/WEB/repos/template-web/browse/webapp/cms/WEB-INF/param/login.xsl?at=refs%2Fheads%2F4.4.x

Rendering dates

Warning: significant risk of regression
Particularly if you're cutting dates on the fly for very specific behaviors (substring).

Following a change in the way dates are stored, they are now stored in UTC and no longer in the server's time zone. This means that if you enter a date at 14:30 UTC, it's actually stored as 12:30 UTC. And if it's stored as 01:30, it's stored as 23:30 of the previous day.

La plupart des rendus actuels avec <i18n:date> ignorent les fuseaux horaires donc il peut y avoir pas mal de soucis.

In all your XSL, look for the use of <i18n:date> and <i18n:date-time> that concern dates from content attributes, and take time zone into account.

In practice, this will often involve replacing src-pattern="yyyy-MM-dd'T'HH:mm:ss" by src-pattern="yyyy-MM-dd'T'HH:mm:ss.SSSXXX".

Même procédure pour <i18n:time>.

Renaming rich_text and multilingual_string types

The types rich_text and multilingual_string were renamed in rich-text and multilingual-string. Search and replace all occurrences in XSL.

Note that case is important: the occurrences of "RICH_TEXT"should be replaced by "RICH-TEXT" 

Using ametys:sitemap()

In your XSL the use of ametys:sitemap() must now have an argument to limit the depth:

  • 0 when you just want info on the page you want or on the sitemap root
  • 1 when you want the page and its direct child pages
  • ...

View AmetysXSLTHelper documentation

Core skins

The kernel charters (ODF, Workspaces and Doc) have been improved to facilitate overloading XSL.

See Workspaces Importing XSLs or ODF Importing XSLs.

Search engine

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).

Functional test to see if you're affected
Insert a search engine, selecting the Document type.
In preview mode, try downloading a document returned by this search engine.
If the link doesn't work with the duplicate context in the address, you're affected. (e.g. /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>.

Technical test to see if you're affected
If you've overloaded the"hit-resource-title-link-href" template at XSL , you're affected.
If not, you're probably not affected: you can run the functional test above to be sure.

In the hit-resource-title-link-href template:

  • En continuant à utiliser <uri> (déconseillé) 
    <xsl:value-of select="ametys:absoluteSiteUriPrefix(siteName)"/>/<xsl:value-of select="uri"/>
    becomes
    <xsl:value-of select="uri"/>
  • Using the resolver (xmlns:resolver="org.ametys.cms.transformation.xslt.ResolveURIComponent")
    <xsl:value-of select="ametys:absoluteSiteUriPrefix(siteName)"/>/<xsl:value-of select="uri"/>
    becomes
    <xsl:value-of select="resolver:resolve(uri/@type, uri/@id, true())"/>

If you had an overload to correct the ticket CMS-9900 your template simply becomes
<xsl:template name="hit-resource-title-link-href">
    <xsl:value-of select="resolver:resolve(uri/@type, uri/@id, false())"/>
</xsl:template>

Plugins

Depending on the plugins Ametys you use, you must follow the graphic migrations specific to each plugin :

Back to top

Update manual