Cette page décrit la procédure de migration des sites et des modules pour être compatibles avec JPlatform 10.
1. Environnement Java et Java EE
1.1 Java 8 et serveurs d'applications
JPlatform 10 requiert l'utilisation de Java 8 (JCMS-5786). Si vous utilisez des certificats de sécurité, pensez à les reporter dans la nouvelle version.
Les versions des serveurs d'applications certifiés ont également évolué.
Procédez à la mise à jour de votre environnement applicatif.
1.2 web.xml
Reprenez les mises à jour du fichier web.xml
fourni dans la webapp 10.
Notamment :
- JPlatform 10 requiert désormais un serveur d'application supportant la spécification Servlet 3.0 (cf JCMS-5580)
- JPlatform 10 utilise un nouveau
ServletFilter
:PluginAccessFilter
2. Modification de comportement
2.1 Configuration par défaut de C3P0
La configuration par défaut du pool de connexion C3P0 a été revue pour proposer des réglages plus en adéquation avec les installations standards de JPlatform 10.
Tous les réglages de C3P0 sont désormais fournis dans le fichier WEB-INF/data/custom.prop
(Le fichier WEB-INF/classes/c3p0.properties ne contient plus de valeurs).
Reprenez les nouvelles valeurs par défaut de JPlatform 10. Pour cela, reprenez la section concernée du fichier custom.prop
standard.
Si vous aviez personnalisé la configuration du pool, comparez vos valeurs avec les nouvelles valeurs fournies.
2.2 Portlet Requête Itération et types non sélectionnés pour la recherche
Le correctif JCMS-5753 modifie le comportement des Portlets Requête/Itération vis-à-vis des types décochés dans l'onglet "Recherche" des propriétés du site.
- Dans JPlatform 9 : les types décochés étaient exclus des résultat affichés par une PQF
- Dans JPlatform 10 : les types décochés sont inclus dans les résultats affichés par une PQF
Le comportement est configurable avec la propriété query.default.types-off.apply-to-pqf
2.3 Suppression des alertes
La propriété alert.trigger-deletion
qui permettait d’empêcher la suppression des alertes n'est plus supportée.
2.4 Resources et propriétés pour Topbar
Dorénavant, pour surcharger la topbar, on peut soit :
- Surcharger la topbar pour toutes les zones du site (les zones étant Front, Admin et Work) via la propriété
jcms.resource.topbar
- Surcharger indépendamment la resource topbar pour une zone dédiée via les propriétés suivantes (vides par défaut) :
jcms.resource.topbar.site
jcms.resource.topbar.admin
jcms.resource.topbar.work
Les clients ayant fait une surcharge de topbar devront adapter leur code pour utiliser cette nouvelle mécanique.
Les propriétés pour désactiver la topbar restent inchangées.
2.5 Ajax : plus de propagation automatique des paramètres
Les paramètres HTTP d'une requête (non Ajax) ne sont plus propagés aux requêtes Ajax effectuées par la suite.
Ce comportement était source de nombreux bugs, tous référencés en lien de l'issue JCMS-4951 qui décrit cette modification.
Cette modification ne devrait pas avoir d'incidence sur vos développements Ajax.
Dans le cas contraire, étudiez avec précision les paramètres qu'attend le JSP/handler invoqué en Ajax, et assurez-vous de les transmettre de façon explicite depuis les formulaires ou URLs.
2.6 [Sécurité] Algorithmes retirés pour les digests (mots de passe/cookie)
Pour des raisons de sécurité, suite à l'évolution JCMS-4769, tous les digests de sécurité utilisant l'algorithme Unix crypt ou MD5 sont désormais considérés comme invalides. Jalios n'utilise plus ces formats depuis JPlatform 7.1, diffusée en février 2012.
Cette modification concerne tous les digests de sécurité : hash de mots de passe stockés sur les Membres, tokens de sécurité utilisés pour les cookies ou les authkey.
La conséquence pour les utilisateurs n'ayant jamais mis à jour leur mot de passe depuis 2012 sera l'obligation de procéder à une réinitialisation du mot de passe.
2.7 [Sécurité] Cookie d'authentification renforcé
Pour des raisons de sécurité, suite à l'évolution JCMS-5813, tous les cookies d'authentification sont désormais soumis à des validations supplémentaires.
La conséquence est que les cookies précédemment émis sont considérés comme invalides.
Tous les utilisateurs (dont l'authentification a été mémorisée par un cookie) devront procéder à une nouvelle authentification lors de leur premier accès à la plateforme, après migration à JPlatform 10.
2.8 Codes de retour HTTP 401 et 403
2 évolutions modifient les codes de retour HTTP envoyés aux clients HTTP "type ligne de commande" (pas depuis les navigateurs donc) :
- JCMS-5942 : Lorsqu'une page nécéssite des autorisations/habilitations spéciales, le code de retour 403 forbidden est envoyé directement (au lieu d'une redirection vers la page de login avec message "Forbidden")
- JCMS-5648 : Lorsque le site est privé (eg : nécessite une authentification) et qu'un client sans authentification tente d'y accéder, un code de retour 401 "Unauthorized" est envoyé directement (au lieu d'une redirection vers la page de login avec message "Forbidden")
Dans le détail :
- Quand un client HTTP envoie le header
Accept: text/html
, c'est un navigateur capable de récupérer du HTML et de l'afficher, le comportement existant n'est pas changé, et une redirection vers une page HTML a lieu. - Quand un client HTTP n'envoie pas ce header, c'est généralement un client HTTP programmatique, type ligne de commande, API REST, outil de supervision, etc.
Pour ces clients HTTP "techniques", il est plus utile (pour eux) de renvoyer directement un code d'erreur 401/403. Il s'agit en effet de codes techniques standardisés, facilement interprétables par ces clients (ce qui n'est pas le cas d'une page HTML "forbidden ou login", dont l'unique but est de fournir une expérience utilisateur convenable quand il y a un humain derrière le client, cad quand il s'agit d'un navigateur Web).
Vérifiez le comportement de vos sondes/scripts de monitoring et autres clients externes.
2.9 Changement dans la politique de droits d'un espace collaboratif
Pour gérer l'évolution un changement notable a été apporté aux publications des espaces collaboratifs : toute publication qui a un parent (eg Commentaire, FAQ Entry, Glossary Entry, une opportunité) a comme droit celui de son parent.
2.10 [Sécurité] Wysiwyg : nettoyage renforcé des attributs HTML
Afin d'assurer une sécurité accrue sur l'utilisation des champs Wysiwyg, un nettoyage accru des balises HTML est effectué en standard dans JPlatform 10 (évolution JCMS-6170).
Chaque attribut HTML bénéficie d'une règle de nettoyage spécifique, configurée dans les propriétés JCMS, et dans laquelle est configuré au moins un des éléments ci-dessous :
- une liste blanche de valeurs autorisées (préfixe
.whitelist
dans les propriétés). - une expression régulière permettant d'identifier des valeurs autorisées (préfixe
.whitelist-regex
). - une liste noire de valeurs interdites (préfixe
.blacklist
). - une expression régulière permettant d'identifier les valeurs interdites (préfixe
.blacklist-regex
).
Le éléments identifiés en liste blanche sont prioritaires sur les éléments en liste noire (un élément présent dans les 2 listes sera donc autorisé).
Une configuration supplémentaire permet de déterminer le comportement par défaut à appliquer pour les valeurs identifiées ni en liste blanche, ni en liste noire (préfixe .default-behavior
dans les propriétés).
Dans tous les cas, les valeurs non autorisées sont supprimées à l'enregistrement.
JPlatform 10 applique en standard un nettoyage sur les 3 attributs suivants :
id
: l'utilisation de certains identifiants réservés à l'applicatif est désormais interdite. Afin d'assurer la plus grande compatibilité possible avec les contenus existants, le comportement par défaut de ce nettoyage est de conserver les balises inconnues, non explicitement mises en liste noire ou en liste blanche.class
: l'utilisation de certaines classes internes à JPlatform est désormais interdite. Pour garantir l'absence de régression sur vos contenus existants, cette régle de nettoyage fonctionne comme la précédente : les valeurs non explicitement exclues sont conservées.style
: contrairement aux deux précédentes règles, le nettoyage des styles est plus complet : seules les propriétés CSS explicitement présentes dans la liste blanche sont autorisées. Toutes les autres propriétés CSS non référencées sont supprimées à l'enregistrement.
Si vous autorisiez vos contributeurs à saisir des identifiants, classes ou styles avancés :
- Consultez les configurations des règles, via les propriétés suivantes du fichier
jcms.prop
:
wysiwyg.sanitize-html.attributes
wysiwyg.sanitize-html.inline-styles
- Assurez-vous que ces configurations sont compatibles avec vos usages en terme de contribution. Dans le cas contraire, vous pouvez personnaliser les règles dans le fichier
custom.prop
ouplugin.prop
de votre module de site :- Enrichissez les règles, en ajoutant ou retirant des éléments en liste blanche.
- En dernier recours, désactivez chacune des règles, avec les propriétés suivantes :
wysiwyg.sanitize-html.attributes.id.enabled: false
wysiwyg.sanitize-html.attributes.class.enabled: false
wysiwyg.sanitize-html.inline-styles.default.enabled: false
- Vous pouvez également désactiver les règles fournies en standard, et créer des règles de liste blanche plus strictes.
2.11 Editeur de texte riche : abandon des styles globaux et d'espace
JCMS 9 incluait une fonctionnalité qui permettait aux intégrateurs/développeurs, de proposer dans l'éditeur wysiwyg des classes spécifiques par espace de travail. Mécanique parfois connue sous le nom "style globaux/locaux".
En synthèse, cette mécanique fonctionnait de la façon suivante :
- un fichier de css,
wysiwyg.css
(respectant un formatage bien spécifique), peut être modifié par les intégrateurs ; - il est parsé au démarrage de JCMS pour en extraire une liste de styles "globaux et locaux" ;
- cette liste peut être modifiée via une
WysiwygPolicyFilter
; - chaque espace de travail peut ensuite être édité pour sélectionner les styles qui seront proposés dans l'éditeur ;
- l'éditeur wysiwyg (dans sa configuration la plus avancée) propose 2 menus de sélection avec ces styles.
Tout cela est décrit dans l'article suivant : https://community.jalios.com/jcms/jc_87257/fr/definir-des-styles-css-pour-l-editeur-wysiwyg
Lors de la conception de l'éditeur texte riche de JPlatform 10, cette mécanique nous est apparue comme trop complexe et superflue :
- il est préférable de proposer des classes sémantiques, communes à tout le site, quitte à ce que des feuilles de styles propres à chaque espace de travail en personnalisent le rendu ;
- l'éditeur wysiwyg de JPlatform 10 est configurable de façon très aisée et modulaire, et permet donc de personnaliser rapidement les styles qui peuvent y être proposés.
JPlatform 10 abandonne ainsi définitivement cette mécanique des styles globaux et des styles d'espace. JCMS-6052
3. Modification d'API et de librairies
3.1 Librairies externes mises à jour ou supprimées
Les librairies externes suivantes ont été mises à jour :
Apache Derby 10.13.1.1
-- JCMS-6132Apache Lucene 6.4.2
-- JCMS-5562Apache PDFBox 2.0.7
-- JCMS-3672JSoup 1.9.2
-- JCMS-5563OWASP ESAPI
supprimé,OWASP Encoder 1.2.1
ajouté -- JCMS-5568Jaxen 1.1.6
Log4j 1.2.17
slf4j 1.7.22
commons-codec 1.10
commons-collections 3.2.2
-- JCMS-5801commons-logging 1.2
-- JCMS-5801 + JCMS-3672commons-fileupload 1.3.3
commons-httpclient 3.1
commons-io 2.5
yuicompressor (build custom)
-- JCMS-5517Xalan Serializer 2.7.2
UnboundID LDAP SDK 3.2.1
Les librairies externes suivantes ont été supprimées :
Plusieurs modules livrés avec JPlatform 10 ont également mis à jour les librairies qu'ils utilisent, notamment :
- Module d'Indexation des documents (Document Indexer Plugin) :
Apache POI
-- DOCIDX-8Text-Mining Extractor
- Module d'Authentification Windows (Waffle Plugin) :
Waffle
-- WAFFLE-23
- Module SAML
- OpenSAML -- SAML-11
- ...
Si vous les utilisez dans le cadre de développement(s) spécifique(s), vous devrez migrer ces développements vers les nouvelles versions.
Consultez les documentations respectives de ces librairies pour les procédures de migration destinées aux développeurs.
3.2 Mise à jour de jquery et jquery-ui
JCMS-5501 - Passage de jquery 1.11.1
à jquery 3.2.1.
De nombreuses fonctions sont maintenant dépréciées. Les APIs obsolètes restent fonctionnelles grâce au plugin jquery-migrate
, mais des warnings peuvent apparaître dans la console développeur des navigateurs.
jQuery fournit un "upgrade guide" pour vous aider dans votre migration : https://jquery.com/upgrade-guide/3.0/
JCMS-5540 - Passage de jquery-ui 1.10.4
à jquery-ui 1.12.1.
Procédures de migration disponibles dans la page suivante : https://jqueryui.com/upgrade-guide/1.12/
Les fonctions supprimées ou dépréciées sont maintenues grâce à la présence de jquery-migrate
.
3.3 Mise à jour de librairies de Glyph Fonts
JCMS-6129 - Glyphicons a été mis à jour, certaines icônes ont changé de nom.
Procédez à une mise à jour des icônes suivantes en utilisant leurs nouveaux noms (extrait du changelog de Glyphicons) :
------------ Renamed icons: souncloud -> soundcloud (in Social set) hotspot -> paired (in basic set) airplane -> plane (in basic set) bed -> bed-alt (in basic set) bed-alt -> bed (in basic set) remove-2 -> remove (in basic set) remove -> remove-circle (in basic set) ok -> ok-circle (in basic set) ok-2 -> ok (in basic set) circle-remove -> remove-sign (in basic set) circle-plus -> plus-sign (in basic set) circle-minus -> minus-sign (in basic set) circle-ok -> ok-sign (in basic set) circle-question-mark -> question-sign (in basic set) circle-info -> info-sign (in basic set) circle-exclamation-mark -> exclamation-sign (in basic set) ban -> ban-circle (in basic set) google-maps -> map-marker (in basic set) left-arrow -> arrow-left(in basic set) right-arrow -> arrow-right(in basic set) down-arrow -> arrow-down (in basic set) up-arrow -> arrow-up(in basic set) ruller -> ruler (in basic set) paragraph -> paragraph-alt (in basic set) note -> music-alt (in basic set) mosquito-net -> mosquito (in basic set) glyph-lock -> lock (in Halflings set, only change of CSS class) glyph-bookmark -> bookmark (in Halflings set, only change of CSS class) glyph-camera -> camera (in Halflings set, only change of CSS class) glyph-fire -> fire (in Halflings set, only change of CSS class) glyph-calendar -> calendar (in Halflings set, only change of CSS class) glyph-bell -> bell (in Halflings set, only change of CSS class) glyph-wrench -> wrench (in Halflings set, only change of CSS class) glyph-briefcase -> briefcase (in Halflings set, only change of CSS class) glyph-paperclip -> paperclip (in Halflings set, only change of CSS class) glyph-pushpin -> pushpin (in Halflings set, only change of CSS class) (To explain changes above: it may seems crazy to rename such an amount of icons, but I had to sync these names between Basic and Halflings set - my apology, I should have done this long time before. On top of that, I've found a better way how to optimize certain icon names for older browsers inside the font file itself, so these tweaks with names are no longer necessary)
JCMS-6130 - Icomoon a été mis à jour avec de nouvelles images. Certaines images ont été supprimées, d'autres ajoutées.
- Icones supprimées :
icomoon-apple2
icomoon-chess-rock
icomoon-coffee-baen
icomoon-deviantart2
icomoon-dribbble2
icomoon-dribbble3
icomoon-facebook3
icomoon-feed2
icomoon-feed3
icomoon-feed4
icomoon-forrst
icomoon-forrst2
icomoon-github2
icomoon-github3
icomoon-github4
icomoon-github5
icomoon-html5
icomoon-html52
icomoon-paypal2
icomoon-paypal3
icomoon-picassa
icomoon-picassa2
icomoon-twitter2
icomoon-twitter3
icomoon-vimeo3
icomoon-wordpress2
icomoon-youtube3
icomoon-youtube4 - Icones ajoutées :
icomoon-500px
icomoon-amazon
icomoon-appleinc
icomoon-basecamp
icomoon-behance
icomoon-behance2
icomoon-calendar-day
icomoon-calendar-empty
icomoon-calendar-week
icomoon-chess-rook
icomoon-coffee-bean
icomoon-edge
icomoon-google2
icomoon-google3
icomoon-hackernews
icomoon-hangouts
icomoon-html-five
icomoon-html-five2
icomoon-npm
icomoon-renren
icomoon-rss
icomoon-rss2
icomoon-sina-weibo
icomoon-spotify
icomoon-telegram
icomoon-trello
icomoon-vine
icomoon-vk
icomoon-whatsapp
icomoon-wikipedia
icomoon-yahoo2
3.4 Mise à jour des templates d'alertes web
Issue correspondante : JCMS-5978
Si vous aviez surchargé la jsp d'alerte web pour vos propres alertes, vous devez mettre à jour votre jsp, et utiliser le code suivant :
<%@ include file='/jcore/alert/web/doInitWebAlert.jspf' %> <div data-jalios-alert-id="<%= alert.getId() %>" class="<%= alertCss %>"> <%@ include file='/jcore/alert/web/doWebAlertHeader.jspf' %> <%@ include file='/jcore/alert/web/doWebAlertBody.jspf' %> <%@ include file='/jcore/alert/web/doWebAlertFooter.jspf' %> </div>
Cette modification a été faite pour éviter d'avoir des jspf qui ouvrent une balise, et une autre jspf qui la ferme. Par ailleurs le rendu a aussi été changé pour pouvoir définir si on veut afficher le résumé de l'alerte.
3.5 Field/Control
Dans JPlatform 9
Si on n'indiquait pas de type sur le tag <jalios:control>
ça rattrapait de la manière suivante :
- Si le tag
<jalios:field>
déclarait un FormHandler (celui généré pour un type), le contrôle était automatiquement résolu, c'est-à-dire que le type de contrôle, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... était résolu à partir duTypeFieldEntry
associé.
<jalios:field name="myField" formHandler="<%= formHandler %>">
<jalios:control />
</jalios:field>
- Si le tag
<jalios:field>
NE déclarait PAS de FormHandler, le contrôle rattrapait par défaut sur le typeTEXTFIELD
.
<jalios:field name="myField" value="<%= myValue %>>
<jalios:control />
</jalios:field>
Dans JPlatform 10
Si on n'indique pas de type sur le tag <jalios:control>
ça rattrape de la manière suivante :
- Si le tag
<jalios:field>
déclare un FormHandler (celui généré pour un type), le contrôle est automatiquement résolu, c'est-à-dire que le type de contrôle, la valeur précédemment saisie, le fait qu'il soit multivalué, multilingue... est résolu à partir duTypeFieldEntry
associé.- (Cela est identique au comportement présent dans JPlatform 9)
<jalios:field name="myField" formHandler="<%= formHandler %>">
<jalios:control />
</jalios:field>
- Si le tag
<jalios:field>
NE déclare PAS de FormHandler, le contrôle NE rattrape PLUS sur le typeTEXTFIELD
.
Il est donc obligatoire de déclarer l'attribut "type" ou "settings" pour afficher correctement le contrôle.
<jalios:field name="myField" value="<%= myValue %>>
<jalios:control type="<%= ControlType.TEXTFIELD %>" />
</jalios:field>
3.6 Wiki / Wysiwyg
3.6.1 Changement de package
Plusieurs APIs ont été déplacées dans des packages dédiés.
Procédez à la mise à jour des imports et signatures des méthodes dans vos développements (notamment WikiPolicyFilter
et WysiwygPolicyFilter
).
com.jalios.jcms.wiki
. Pour le wiki, des classes assurant une compatibilité partielle sont toujours présentes dans les anciens packages :com.jalios.jcms.WikiRenderingHints
->com.jalios.jcms.wiki.WikiRenderingHints
com.jalios.jcms.WikiRenderer
->com.jalios.jcms.wiki.WikiRenderer
com.jalios.jcms.wysiwyg
.com.jalios.jcms.WysiwygManager -> =com.jalios.jcms.wysiwyg.WysiwygManager
com.jalios.jcms.WysiwygMediasRewriter
->com.jalios.jcms.wysiwyg.WysiwygMediasRewriter
com.jalios.jcms.WysiwygRendererr
->com.jalios.jcms.wysiwyg.WysiwygRenderer
3.6.2 Migration vers le wysiwyg
JPlatform 10 introduit l'usage exclusif de l'éditeur de texte riche, en lieu et place des champs wiki.
Si vous aviez développé des WikiPolicyFilter
pour introduire des syntaxes personnalisées :
- A l'affichage des anciens champs wiki : un rendu wiki doit toujours être assuré. Hormis les signatures de package évoquées ci-dessus, aucun changement de votre
WikiPolicyFilter
n'est nécessaire. - A l'édition des anciens champs wiki : une conversion automatique du texte wiki en HTML a lieu. Votre
WikiPolicyFilter
est également invoqué à ce moment, ce que vous pouvez déterminer viaWikiRenderingHints.isWiki2JHTML
. Adaptez éventuellement votre policy pour générer un HTML spécifique.
Pour vos nouveaux développements, les APIs wiki sont dépréciées et le Wysiwyg doit être utilisé :
- Côté éditeur : Développement de plugins TinyMCE (en remplacement des
WikiPolicyFilter.handleWikiToolbar
permettant la modification des barres d'outil de l'éditeur wiki) - Côté rendu : Développement de
WysiwygPolicyFilter
pour adapter le HTML si besoin.
3.6.3 Modification du DOM généré
Le DOM généré pour le rendu des textes wiki et JHTML a été modifié par rapport à celui des versions précédentes.
Si vous aviez personnalisé des feuilles de style avec vos propres CSS, vous devrez les modifier.
Voici les changements notables. Ils concernent principalement le rendu des fonctionnalités disponibles auparavant via le plugin Wiki (pour les WikiPage), qui sont désormais proposés par le coeur :
Résumé (tag wiki [jalios:abstract]
, tag JHTML <jalios:abstract/>
) :
- rendu JPlatform 9 :
<p class="abstract">...</p>
- rendu JPlatform 10 :
<div class="abstract">...</div>
Table de matières et identifiant sur en-tête :
- rendu JPlatform 9 : via des
table/tr/td
etul/li
, - rendu JPlatform 10 : via les balises sémantiques
nav, h1
etul/li
3.7 Publication en base : signature des setter de champs primitifs monovalués
Dans le cadre de l'issue JCMS-5940, les setters des champs primitifs monovalués des publications en base ont changé. Il reçoivent désormais un type de wrapping au lieu du type primitif.
Exemple, sur le type DBMailMessage
, le setter du champ priorité :
- Avant :
setPriority(int)
- Après :
setPriority(Integer)
Grâce à l'autoboxing, c'est transparent mais moins souple qu'avec les types primitifs. Un setter primitif de type double
accepte aussi bien un double
, un long
ou un int
. Ce n'est pas le cas avec le type de wrapping Double
. Il faut impérativement lui fournir une valeur de type double
ou Double
. Ainsi, l'appel au setter suivant ne compile plus :
jlearnResource.setDuration(240);
il faut désormais écrire :
jlearnResource.setDuration(240L);
Si cette évolution devrait avoir peu d'impact sur le code spécifique durant les migrations, elle peut avoir un impact sur les performances lors des premiers démarrages après la migration. Si un type de données (coeur ou module) est livré dans sa nouvelle version avec un nouveau champ primitif, toutes les anciennes instances vont être ré-enregistrés dès qu'elles seront chargées (au moment du commit de la transaction).
3.8 FriendlyURLSet pour les DB Content
Les types DB Content peuvent désormais définir des URLs intuitives (aka FriendlyURL), à l'instar des contenus du Store.
Ceci a nécessité l'ajout d'une déclaration de la collection friendlyURLSet
dans les fichier HBM. Ceci est pris en charge par le générateur de type.
Il n'y a pas de migration particulière à prévoir sur les types de données de Jalios.
Si vous avez développé des DB Content spécifiques à votre site avec un fichier HBM personnalisé, modifiez le fichier HBM pour ajouter la déclaration suivante :
<!-- COLLECTIONS FOR FRIENDLYURL -->
<set name="friendlyURLSet" table="G_MYCUSTOMDEBTYPE_FURLSET" lazy="true">
<cache usage="read-write" />
<key>
<column name="ITEM_ID" index="IG_MYDEBTYPE_FURLSET_I"></column>
</key>
<element type="string">
<column name="VALUE"/>
</element>
</set>
Si ce n'est pas fait, le message suivant apparaîtra lors du démarrage de JPlatform :
The friendlyURLSet collection is not declared in mapping file (HBM) for class MYDEBTYPE. This HBM should be updated to add this new collection.
Issue JCMS-5941.
3.9 Form Handler / Edit Handler : setters de champ texte (mono/multivalué, mono/multilingue)
Les APIs utilisées dans les setters des EditHandler ont étés revues.
- Afin de simplifier leur usage ;
- Afin de garantir le traitement approprié des valeurs textuelles reçues de l'utilisateur (encodage ou nettoyage selon le type de champ concerné) ;
- Notamment pour la gestion des valeurs wiki et wysiwyg.
Les APIs suivantes de la classe com.jalios.jcms.handler.JcmsFormHandler
sont dépréciées :
protected String getMainLangValue(String[] array, boolean trim, boolean escape)
protected HashMap<String,String> getMLMap(String[] array, boolean trim, boolean escape)
protected String[] getMainLangValueArray(String[] array, boolean trim, boolean escape)
protected HashMap<String,String[]> getMLMapArray(String[] array, boolean trim, boolean escape)
Elles sont remplacées par les méthodes suivantes :
protected static String getMonolingualValue(TypeFieldEntry tfe, String[] array)
protected static String[] getMonolingualValueArray(TypeFieldEntry tfe, String[] array)
protected static String getMultilingualMainValue(TypeFieldEntry tfe, String[] array)
protected static HashMap<String,String> getMultilingualMLMap(TypeFieldEntry tfe, String[] array)
protected static String[] getMultilingualMainValueArray(TypeFieldEntry tfe, String[] array)
protected static HashMap<String,String[]> getMultilingualMLMapArray(TypeFieldEntry tfe, String[] array)
Pour une gestion correcte des champs wiki et wysiwyg, vous devez impérativement migrer vos handler spécifiques pour utiliser les nouvelles APIs.
Utilisez le tableau de correspondances ci-dessous, et consultez la Javadoc de ces méthodes pour des exemples et plus d'informations.
Dans JPlatform 9
Mono lingual | Mono lingual | Multi lingual | Multi lingual | |
---|---|---|---|---|
Mono value | Multi value | Mono value | Multi valued | |
String | getMainLangValue | - | - | - |
HashMap<String,String> | - | - | getMLMap | - |
String[] | - | {foreach+escape}+trim | - | getMainLangValueArray |
HashMap<String,String[]> | - | - | - | getMLMapArray |
Dans JPlatform 10
Mono lingual | Mono lingual | Multi lingual | Multi lingual | |
---|---|---|---|---|
Mono value | Multi value | Mono value | Multi valued | |
String | getMonolingualValue | - | getMultilingualMainValue | - |
HashMap<String,String> | - | - | getMultilingualMLMap | - |
String[] | - | getMonolingualValueArray | - | getMultilingualMainValueArray |
HashMap<String,String[]> | - | - | - | getMultilingualMLMapArray |
3.10 Form Handler : méthode validate "final"
La méthode com.jalios.jcms.handler.JcmsFormHandler.validate()
est désormais final
.
Si vous aviez développé des handler personnalisés dérivant de la classe JcmsFormHandler (ou de l'une de ses sous-classes), et que vous aviez surchargé la méthode JcmsFormHandler.validate()
, vous devez maintenant surcharger - à la place de cette dernière - la méthode JcmsFormHandler.processAction()
(le code lui-même de votre méthode ne nécessite aucune adaptation).
Issue JCMS-6004.
3.11 Évolution de MenuInfo et MenuInfoFilter
Les classes MenuInfo
et MenuInfoFilter
(aidant à réaliser des menus de navigation) ont évolué. Elles n'utilisent plus de type générique.
Recherchez l'utilisation de ces classes dans vos JSPs et/ou classes Java, et remplacez par exemple MenuInfo<Category>
et MenuInfoFilter<Category>
respectivement par MenuInfo
et MenuInfoFilter
tout court.
4. Configuration et Données
4.1 Index lucene
- Supprimez le répertoire
WEB-INF/data/lucene
. Sans cette étape, vous observerez l'erreur suivante au démarrage :
org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource BufferedChecksumIndexInput(MMapIndexInput(path="C:\....\WEB-INF\data\lucene\PublicationsIndices\en\segments_vb"))): -9 (needs to be between 1071082519 and 1071082519). This version of Lucene only supports indexes created with release 5.0 and later. at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:295) at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:284) at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:910) at com.jalios.jcms.search.LuceneDataSearchEngine.<init>(LuceneDataSearchEngine.java:210) at com.jalios.jcms.search.LucenePublicationSearchEngine.<init>(LucenePublicationSearchEngine.java:178) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at java.lang.Class.newInstance(Class.java:442) at com.jalios.jcms.QueryManager.initEngine(QueryManager.java:107) at com.jalios.jcms.QueryManager.<init>(QueryManager.java:79) at com.jalios.jcms.QueryManager.getQueryManager(QueryManager.java:67)
- Démarrez
Une réindexation complète aura lieu au démarrage (en application de l'évolution JCMS-1612 introduite dans JPlatform 6.1).
Si vous ne le souhaitez pas et préférez faire une réindexation manuelle, changez la propriété suivante :
search-engine.auto-indexing-on-first-startup:false
puis lancez l'indexation depuis l'interface d'administration.
4.2 Portail des Applications
Pour bénéficier du portail des applications (portail utilisé par défaut pour l'affichage d'une application), il faut ajouter la déclaration de ce portail dans les propriétés (channel.app-portal
).
Dans une application JPlatform 10 vierge, un portail des applications par défaut est proposé (j_231
).
Vous pouvez le reprendre et éventuellement l'adapter lors d'une migration. Vous pouvez aussi en définir un nouveau et le déclarer dans l'éditeur de propriétés. Ce portail doit avoir la classe CSS jaliosAppPortal
.
Pour bénéficier du portail des applications par défaut, ajoutez les lignes suivantes dans le store.xml
(positionnez-les correctement selon leurs stamps respectifs) :
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- |||||||||||||||||||||| App Portal ||||||||||||||||| -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<generated.PortletColumn stamp="j_230" id="j_230" op="create" abilities="" adate="" alignH="center" alignHorizontal="" alignTable=" " alignV="middle" alignVertical="" author="j_2" authorDBID="" authorizedGroupSet="" authorizedMemberSet="" backColor="" backImage="" backgroundColor="" backgroundImage="" backgroundRepeat="" behaviorCopy="true" border="0" borderColor="" cacheSensibility="None" cacheType="None" categories="" cdate="1495373583125" cellPadding="0" children="@|j_205" childrenBindings="" colSpacing="0" condition="@|None" cssClasses="" cssId="" dbFriendlyURLSet="" description="" descriptionML="%|java.lang.String/fr=java.lang.String/" displayCSS="" edate="" extension="" extraDataMap="" friendlyURLSet="" importMap="" insetBottom="0" insetLeft="0" insetRight="0" insetTop="0" invalidClass="" invalidTime="60" isTracked="false" mainInstance="" mainLanguage="en" majorVersion="1" mdate="1495373583125" mergeDate="" mergeId="" opAuthor="j_2" opDelegate="" originalPortlet="" pdate="" portletImage="" portletImageML="" pstatus="0" roleMap="" sdate="" templates="@|box.default|query.default" title="App Portal - Main Column" titleML="%|java.lang.String/fr=java.lang.String/Portail App - Colonne Principale|java.lang.String/en=java.lang.String/App Portal - Main Column" udate="1495373583125" updateGroupSet="" updateMemberSet="" width="100" workflowId="" workspace="j_4" />
<generated.PortletPortal stamp="j_231" id="j_231" op="create" abilities="" adate="" author="j_2" authorDBID="" authorizedGroupSet="" authorizedMemberSet="" behaviorCopy="true" cacheSensibility="None" cacheType="None" categories="@|j_5" cdate="1495373583131" child="j_230" cssClasses="jaliosAppPortal" cssFile="css/portal/jalios.css" cssId="" dbFriendlyURLSet="" description="The HomePage Portal of the JCMS Channel" descriptionML="%|java.lang.String/fr=java.lang.String/Portail Page d'Accueil du canal JCMS" edate="" exactCategory="false" extension="" extraDataMap="" friendlyURLSet="" importMap="" invalidClass="" invalidTime="60" isTracked="false" mainInstance="" mainLanguage="en" majorVersion="1" mdate="1495373583131" mergeDate="" mergeId="" opAuthor="j_2" opDelegate="" pageTitle="" pageTitleML="" pdate="" portletImage="" portletImageML="" pstatus="0" roleMap="" sdate="" templates="@|box.default|query.default" title="App Portal" titleML="%|java.lang.String/fr=java.lang.String/Portail Application|java.lang.String/en=java.lang.String/App Portal" udate="1495373583131" updateGroupSet="" updateMemberSet="" workflowId="" workspace="j_4" />
Issue : JCMS-5979
4.3 Type Média
Le type Média est par défaut le nouveau type destiné à accueillir les fichiers de type Image, Vidéo et Audio déposés sur la plateforme.
Bien que ce ne soit pas obligatoire, il est recommandé de :
- Activer ce type (ou un autre type destiné à ces types de fichier) dans TOUS les espaces dans lesquels ces types de fichiers peuvent être déposés ;
- Donner les droits de contribution sur ce type à l'ensemble des contributeurs qui ont le droit sur le type FileDocument ou l'un de ses sous-types.
4.4 Sélection automatique du type de documents
Des nouvelles propriétés permettent de sélectionner automatiquement un type de document en fonction du Mime Type de son fichier (et des droits de l'utilisateur qui fait le dépôt).
En standard ces propriétés sont définies ainsi :
file-document.upload.class.image: generated.Media file-document.upload.class.video: generated.Media file-document.upload.class.audio: generated.Media
Une propriété permet aussi de sélectionner un type de document par défaut. En standard cette propriété est définie ainsi :
file-document.upload.class.default: com.jalios.jcms.DBFileDocument
Il est recommandé de reporter ces propriétés standards dans le custom.prop
de la plateforme.
4.5 Add-pack : limite sur les invités
JPlatform 10 contrôle le nombre d'invités (issue JCMS-5924)
C'est une nouvelle dimension disponible sur les add-packs. Si la dimension n'est pas renseignée, la limite est à 3 invités.
En conséquence, les dimensions "Member" et "DBMember" ignorent désormais les comptes invités.
Donc pour un site n'ayant que 3 ou moins invités, les anciens add-packs sont corrects. Si le site a 3 ou plus invités, il est nécessaire d'obtenir un nouvel add-pack avec la dimension "Nombre d'invités" renseignée correctement.
4.6 Alerte : dénormalisation du champ Workspace
Une colonne WORKSPACE_ID
a été ajoutée à la table J_ALERT
. Pour toutes les alertes ayant une Data
de type Publication
(donc un workspace), il faut mettre à jour le workspace de l'alerte.
Appelez la JSP suivante en tant qu'administrateur : http://localhost:8080/jcms/jcore/alert/updateAlertWorkspace.jsp.
Les alertes mises à jour seront loguées dans la console.
4.7 Recommandation : dénormalisation du champ Workspace
Une colonne WORKSPACE_ID
a été ajoutée à la table J_RECOMMENDATION
. Pour toutes les recommandations ayant une Data
de type Publication
(donc un workspace), il faut mettre à jour le workspace de la recommendation.
Appelez la JSP suivante en tant qu'administrateur : http://localhost:8080/jcms/jcore/alert/updateRecommendationWorkspace.jsp
.
Les recommendations mises à jour seront loguées dans la console.
4.8 Modification du processus de stockage des données Analytics
JCMS-6082 apporte la possibilité de choisir un système de stockage des données Analytics (EventData).
Plusieurs stockages sont possibles, mais un seul pourra être utilisé pour effectuer les analyses.
Les stockages sont à configurer via des propriétés ayant le prefixe jcms.analytics.storage-handler.
.
Exemple de configuration :
jcms.analytics.storage-handler.1.classname: com.jalios.jcms.analytics.storage.impl.FileSystemStorage jcms.analytics.storage-handler.1.directory: $DATA_DIR/analytics jcms.analytics.storage-handler.1.isAnalysisProvider:true
Note : il s'agit de la configuration par défaut, si aucune propriété n'existe avec le préfixe indiqué ci-dessus.
Aucune modification du custom.prop
n'est nécessaire pour assurer la compatibilité ascendante. Toutefois vous pouvez reprendre le paramétrage désormais fourni dans le fichier custom.prop
livré par défaut.
5. Modules
5.1 Module DBComment
DBCP-154 - Renommage de la classe .comment
en .dbcomment
sur la vue desktop des commentaires, pour éviter un conflit avec le SyntaxHighlighterPlugin.
5.2 Module Blog
Passage du type BlogPost
en Content
(issue BLOG-176).
Ce changement implique que les utilisateurs, pour pouvoir publier des billets de Blog, devront faire partie d'un groupe qui peut publier ce type de contenu dans l'espace concerné.
Auparavant, le type BlogPost
était un UserContent
; la simple appartenance à l'espace suffisait donc pour pouvoir publier des billets.
Il existait cependant des règles permettant de limiter ce droit, via le groupe bloggers défini sur le Blog. On vérifiait aussi que le membre appartenait aux "Workers" de l'espace.
5.3 Module Organigramme
5.3.1 Relâchement des dépendances
Plusieurs modules ont besoin d'accéder à la structure de l'organisation (département, responsable, équipe, ...) Jusqu'à présent, ces notions étaient fournies par le Module Organigramme (FlowChart).
Toute cette gestion a été introduite dans le coeur de JPlatform 10, voir JPlatform 10 - API de gestion de l'organisation et des responsables de département.
Le Module Organigramme n'assure donc plus que son rôle de rendu graphique de la structure de l'organisation.
Aussi les modules tels que JLearn ou VacationRequest, dans leurs versions spécifiques à JPlatform 10, n'auront plus besoin de la présence du Module Organigramme pour fonctionner.
5.3.2 Migration
Dans le fichier custom.prop
, la propriété jcmsplugin.flowchart.root.id
pouvait désigner soit un groupe, soit une catégorie.
Le groupe doit désormais être déclaré par la propriété $channel.organization-root-group
, qui est éditable dans le gestionnaire des propriétés du site (onglet Utilisateurs
).
Si vous utilisiez une catégorie, elle doit désormais être déclarée par la propriété jcmsplugin.flowchart.root-cat.id
, éditable dans les propriétés du module.
Les données du Module Organigramme (ExtraData/ExtraDBData) présentes sur les membres et les groupes sont automatiquement migrées (en "lazy" lors des ré-enregistrements des objets).
6. UI
6.1 Réécriture du menu Topbar admin
Ce menu a été réécrit en "slide menu".
Si vous vous branchiez via l'une des targets suivantes : SITE_TOPBAR_ADMIN_MENU
, WORK_TOPBAR_ADMIN_MENU
, ADMIN_TOPBAR_ADMIN_MENU
, vérifiez et adaptez au besoin votre rendu.