Comment concevoir un thème personnalisé et léger sous Liferay ?

Cet article survient suite à la réalisation, par notre équipe Plateformes d’intégration et Intelligence Artificielle, d’un site informationnel pour l’un de nos clients, une grande entreprise canadienne de télécommunication et de médias, en utilisant Liferay 7 (la dernière version du portail Liferay).

Alexis, développeur front-end, vous partage son expérience sur ce projet afin de vous expliquer comment il est possible de créer un thème léger et rapide à charger avec Liferay.

En 2015, nous avons découvert le site de Bugaboo, réalisé sous Liferay 6.2. Une chose nous a surpris : l’absence des librairies front-end du thème Liferay.
Depuis l’idée a fait son chemin et un mandat similaire est arrivé à Savoir-faire Linux : Réaliser le site web informationnel d’une grande entreprise canadienne de télécommunications et média, avec Liferay.

Avant toute chose, nous devons nous accorder sur un point, la vitesse de chargement d’un site web est un élément déterminant de la rétention des utilisateurs : après 3 secondes [de chargement], jusqu’à 40% d’entre eux vont quitter le site » (Gomez Inc., 2010, en anglais). Pour plus d’informations, voir Lara Callender Hogan (en anglais).

Liferay n’est pas en soi une solution technique qui peut répondre à tous les besoins. Il est tout à fait possible de faire des sites web avec, mais malheureusement la méthode « recommandée », c’est-à-dire étendre le thème Liferay par défaut, aurait été un échec technique pour le site informationnel de notre client à cause d’un allongement considérable du temps de chargement. C’est alors que, basé sur nos expériences avec nos précédents projets, il a été choisi d’adapter en profondeur le thème Liferay afin de pouvoir répondre aux besoins précis de notre client. Dans ce qui va suivre, nous partageons avec vous notre retour et nos résultats.

Le portail Liferay, un outil puissant qui a besoin d’accompagnement

Liferay est un gestionnaire de contenu (CMS) et un portail écrit en Java fournissant de nombreuses fonctionnalités spécifiques aux développeurs comme une gestion avancée des utilisateurs, des droits d’accès, des documents, etc. Dans notre cas, en tant que société de services, nous avons la possibilité de l’adapter autant que nous le voulons aux besoins de nos clients. Par contre, étant pensé pour être un portail modulaire, il y a quelques défauts liés aux thèmes et aux performances à considérer avant de concevoir un site web avec. En voici la liste :

  • Le thème de base de Liferay charge par défaut toutes les librairies front-end ainsi que l’ensemble des styles que Liferay et ses portlets ont besoin. Cependant, une grande partie du code et des dépendances s’avère inutile pour un visiteur non-connecté (soit la majorité de nos utilisateurs dans le cadre de ce projet). De nombreux problèmes de performance apparaissent donc à cause de cette surcharge inutile de code.
  • Liferay impose la présence de son Design Language, Lexicon (ou plutôt, sa seule implémentation: Clay). Cela provoque également plusieurs problèmes :
    • Manque de correspondance entre le Design Language et les besoins visuels requis pour ce projet, limitant grandement les designs réalisables et ou en compliquant grandement la personnalisation,
    • Conflits au sein des règles CSS, augmentant le temps de développement,
    • Les mises à jour et corrections du thème de base de Liferay peuvent briser les styles développés provoquant alors une augmentation significative du temps de maintenance,
    • L’administration des contenus étant à même les pages, les styles développés peuvent briser le comportement des styles d’administration participant aussi à l’augmentation du temps de développement et de maintenance.

Comment alors réaliser un thème léger sous Liferay ?

La solution pour bénéficier de la puissance de Liferay tout en gardant le contrôle de la vitesse de chargement des pages est de créer un thème léger ne contenant aucune des librairies Liferay front-end comme senna.js, AlloyUi, Lexicon/Clay, etc.

Cependant, dans Liferay 7, ce n’est pas aussi facile que cela n’y paraît, notamment dû à l’impossibilité d’avoir une vue d’administration (indépendante) pour le site. Pour échapper à cela, nos fantastiques développeurs back-end de l’équipe ont développé un module, le « Theme Switcher », qui permet de forcer l’affichage d’un thème en fonction du rôle d’un utilisateur. Dans notre cas, cela nous permet d’afficher un thème classique Liferay uniquement aux administrateurs du site. Voici le lien vers le GitHub du « Theme Switcher » : savoirfairelinux/liferay-theme-switcher

5 étapes pour la mise en place d’un thème léger sous Liferay

Un exemple de thème léger pour Liferay disponible sur notre GitHub : savoirfairelinux/lightweight-liferay-theme. Ce thème utilise une architecture Maven, mais libre à vous de le modifier.

Étape 1 – Nettoyage du thème

Retirez les inclusions du fichier portal_normal.ftl, principalement: <@liferay_util["include"] page=top_head_include />. Mais aussi <@liferay_util["include"] page=body_top_include /> et j’en passe…

Étape 2 – Réparation du thème

Malheureusement la variable top_head_include ne contient pas que les librairies CSS et javascript de Liferay, mais aussi beaucoup d’autres choses. Il est donc nécessaire de ré-inclure les balises du head qui nous intéressent.

Par exemple,

  • Les meta-tags que l’utilisateur peut définir dans chaque pages (keywords, description, etc…):

<@liferay_theme["meta-tags"] />

  • La définition des urls canoniques:
<#if !is_signed_in && layout.isPublicLayout() > 
  <#assign completeURL = portalUtil.getCurrentCompleteURL(request) > 
  <#assign canonicalURL = portalUtil.getCanonicalURL(completeURL, themeDisplay, layout) > 

  <link href="${htmlUtil.escapeAttribute(canonicalURL)}" rel="canonical" /> 

  <#assign availableLocales = languageUtil.getAvailableLocales(themeDisplay.getSiteGroupId()) > 

  <#if availableLocales?size gt 1 > 
    <#list availableLocales as availableLocale> 
      <#if availableLocale == localeUtil.getDefault() > 
        <link href="${htmlUtil.escapeAttribute(canonicalURL) }" hreflang="x-default" rel="alternate" /> 
      </#if> 
      <link href="${htmlUtil.escapeAttribute(portalUtil.getAlternateURL(canonicalURL, themeDisplay, availableLocale, layout)) }" hreflang="${localeUtil.toW3cLanguageId(availableLocale)}" rel="alternate" /> 
  </#list> 
  </#if> 
</#if> 

Pour savoir quoi aller chercher, et comment, basez-vous sur la jsp qui est utilisée pour générer la variable top_head_include : https://github.com/liferay/liferay-portal/blob/7.0.x/portal-web/docroot/html/common/themes/top_head.jsp

Étape 3 – Organisation

Un des problèmes, et vous l’aurez peut-être deviné : les tâches liferay-theme-tasks fonctionneront difficilement.

Cependant, bonne nouvelle : Vous pouvez organiser votre futur thème de la manière dont vous le souhaiter et selon les standards de développement de votre équipe (sass, less, es6, etc.). Dans le cas de notre client, nous avons utilisé et agrémenté le gulpfile habituel pour nos projets web. Le tout chapeauté par Maven et des modules front-end.

Étape 4 – Automatisation du déploiement du thème léger

Cette partie a été la plus longue, je vous avoue, mais elle vous est maintenant disponible clé en main, dans la tâche gulp ‘deployLocal:syncTheme’ du thème d’exemple !

Il s’agit de la mise en place d’un déploiement « live » des fichiers du thème.

D’un point de vue global, le but est de ne pas avoir à compiler ni à attendre le déploiement du thème pour chaque modification de CSS ou de javascript (fonctionnalité normalement présente dans les liferay-theme-tasks). Dans le contexte OSGI de Liferay 7, il n’est pas facile d’accéder directement aux fichiers du thème (CSS, javascript, templates, etc.).

L’idée est alors de modifier la manière dont le thème est déployé dans OSGI, en le faisant pointer non pas vers le fichier .war du thème compilé (en mode webbundle, celui par défaut), mais plutôt vers le dossier extrait de ce .war (en mode webbundledir).

Étape 5 – Profitez

Vous avez maintenant un thème Liferay, qui contient uniquement ce que vous désirez pour votre projet, et qui est déployable comme n’importe quel autre thème Liferay.

Tests et résultats

Dans le but d’évaluer les avantages en terme de performances de la mise en place d’un thème léger, vous pouvez lancer un test, sur une même page avec le même contenu, avec 3 cas possibles de choix de thème. De notre côté, nous avons lancé ces tests sur un serveur Liferay configuré pour la production avec 8 CPU, 28Go de RAM et un disque SSD. Ci-dessous les 3 cas pour lesquels nous avons lancé le test.

Les 3 cas possibles de choix de thème

  1. Utilisation d’un thème vanille de Liferay, un thème classique
  2. Utilisation du thème léger que nous avons développé pour le site informationnel de notre client
  3. Utilisation du thème classique avec l’ajout des styles CSS et javascript du thème que nous avons développé pour notre client

Pour réaliser les mesures, nous avons utilisé une instance locale de speedtest.io (6.0.3) avec Chrome 62. Pour chacun des cas, 10 appels ont été réalisés. Ci-dessous un résumé des résultats :

Résultat du cas 1 : Le thème classique de Liferay

  • 52 requests
  • 1064.77 kb
  • DOMContentLoaded : 1.24s (±31.95ms)
  • Chargement : 2.06s (±52.89ms)
  • speedIndex : 1349 (±34.99)

Nous considérons ces résultats comme corrects car ils se trouvent dans la moyenne que l’on peut trouver actuellement sur le web. Néanmoins, il y a tout de même un grand nombre de requêtes, dépassant le seuil des 40, habituellement recommandé.

Résultat du cas 2 : Le thème léger

  • 37 requests
  • 800.38 kb
  • DOMContentLoaded : 588ms (±42.96ms)
  • Chargement : 1.17s (±55.17ms)
  • speedIndex : 863 (±39.57)

Moins de requêtes, une page plus légère, ce thème personnalisé est plus performant que le thème classique de Liferay !

Résultat du cas 3 : Le thème classique avec les CSS et javascript du thème léger de notre client

  • 56 requests
  • 1214.59 kb,
  • DOMContentLoaded: 2.22s (±457.34ms),
  • Load: 2.97s (±458.11ms)
  • speedIndex: 2475 (±456.71)

Ce résultat est très important, car il s’agit d’un cas qui pourrait être réel. Un thème Liferay, avec un visuel complètement personnalisé mais plus que deux fois plus lent à charger…

Conclusion

Dans l’ensemble, cette expérience fut instructive et nous a fourni, ainsi qu’à notre client, des résultats à la hauteur de nos espérances.

Néanmoins, la mise en place d’un thème léger ne peut pas s’appliquer pour n’importe quel type de site web et devenir une solution unique pour vos projets web. De plus, avec cette méthode, certaines fonctionnalités (front-end) de plusieurs Portlet Liferay se trouvent inaccessibles.

 

Érudit, un savoir à cultiver… librement

Premier diffuseur de ressources francophones en sciences humaines et sociales en Amérique du Nord, Érudit s’est refait une beauté en 2017. Fruit d’un travail d’un an et demi, cette refonte technique et visuelle offre de nouvelles fonctionnalités, auxquelles notre expert Python Morgan Aubert s’est fait un grand plaisir de contribuer.

En accès libre
Avant d’aborder cette refonte, revenons un petit peu en arrière. En 1998, les Presses de l’Université de Montréal lancent Érudit, plateforme de ressources pour les sciences humaines et sociales. Six ans plus tard, en 2004, elle bénéficie du soutien d’un consortium unissant l’Université de Montréal, l’Université Laval et l’Université du Québec à Montréal. Cette union renforce Érudit dans sa mission de diffuser en accès libre du contenu de haut niveau dans plus de 30 disciplines : des revues savantes et culturelles, des livres, des actes, des mémoires, des thèses ainsi que des rapports de recherche.

Ce volume conséquent de plus de 200 000 documents fait de la plateforme un acteur de référence pour la recherche francophone, contribuant au partage du savoir et encourageant par là même la publication scientifique en français sur le territoire nord-américain. En 2016, le compteur des consultations est monté 21 millions !

Par ailleurs, Érudit s’est engagé dès sa création envers l’utilisation des logiciels libres : son environnement de travail, son infrastructure et ses services reposent sur des logiciels libres. Directeur des technologies du consortium, Davin Baragiotta insiste sur le fait d’avoir «la capacité d’utiliser des technologies développées/maintenues par des tiers, d’y contribuer au besoin -comme on a pu le faire- et de mettre à disposition notre propre code en vue d’une réutilisation complète ou partielle par des tiers. C’est une culture technique de partage et de collaboration qui permet d’avoir une meilleure capacité de développement et de maintenance de nos TI. Aussi, d’un point de vue organisationnel, cette approche technique s’inscrit dans une culture plus large d’ouverture, de collaboration et de partenariat. Essentiellement, Érudit met en valeur des contenus scientifiques et culturels que l’on veut voir d’avantage diffusés en Open Access. »

Lors des travaux préliminaires de la refonte, le projet visait à doter Érudit d’une plateforme moderne qui permettra une évolution continue et une extension des fonctionnalités. Il s’agissait donc de réécrire la plateforme en Python/Django en remplacement de Cocoon/Drupal/WordPress, mais en gardant la même couverture fonctionnelle. C’est dans ce contexte que notre expert Morgan Aubert a travaillé en tant consultant développeur Python. Il y a fait du développement back end et front end, en utilisant le framework web Django, alors que les développements front end impliquaient Javascript et Sass.

Bonjour Morgan, quels ont été les défis techniques auxquels tu as confronté pour cette plateforme ?
L’un des principaux défis technologiques était lié au gros volume de données à importer, traiter, présenter et servir sur la plateforme. En effet, la plateforme Érudit met à disposition plus de 200 000 documents savants et culturels. Avant d’être visibles sur la plateforme Erudit.org, ces documents doivent être importés depuis différentes sources de données – ce qui implique plusieurs protocoles sous-jacents (par exemple Fedora Commons, un système de gestion de bibliothèques numériques, ou encore OAI-PMH, Open Archive Initiative Protocol for Metadata Harvesting, un protocole permettant l’échange de métadonnées provenant de sources diverses). Gérer un tel volume de document impliquait également d’anticiper les différents usages de la plateforme afin d’assurer une navigation fluide et performante pour les utilisateur d’ Erudit.org.

Il y avait également d’autres défis : assurer une certaine rétro-compatibilité entre l’ancienne plateforme et la nouvelle, qu’il s’agisse de redirections entres les anciennes URLs et les nouvelles, ou des techniques de conservation de l’indexation des documents Érudit dans Google et Google Scholar (https://scholar.google.ca/). Un autre défi consistait à permettre la collecte de métriques de consultations de documents en vue de produire des statistiques dans divers formats, et ainsi représenter ces statistiques de consultation de documents savants ou culturels avec des outils tel que COUNTER, ou des webservices, qui implémentent plusieurs normes de webservices liés à la récupération de données de consultation de documents savants ou culturels tel que Schemas for the Standardized Usage Statistics Harvesting Initiative (SUSHI).

Et quelle fut la partie de ton travail la plus intéressante ?
L’objectif de la plateforme Erudit.org s’inscrit dans une dynamique très vertueuse; le fait d’effectuer des travaux de conception et de développement sur la nouvelle version de cette plateforme était ainsi très valorisant. Outre les travaux liés à la mise en place de cette nouvelle application avec le cadriciel Django, l’un des aspects les plus intéressants de cette mission de plusieurs mois était lié aux spécificités mêmes de la plateforme : le fait de découvrir les spécificités techniques et exigences du milieu universitaire/bibliothécaire était particulièrement intéressant. Qu’il s’agisse de protocoles d’échange de métadonnées, de technologies de gestion de bibliothèques numériques ou de normes de présentation de citations, c’est un milieu qui vient avec son lot de problématiques techniques, d’enjeux technologiques… et de solutions libres. J’ai d’ailleurs été amené à réaliser plusieurs contributions lors de mon mandat, notamment dans le cadre de l’utilisation d’outils Python proposant des mécanismes d’interactions avec des technologies de gestion de bibliothèques numériques tels que eulfedora pour Fedora Commons .

Christophe Villemer, vice-président de Savoir-faire Linux, rebondit sur ces contributions : «en apportant notre expertise Python/Django à ce projet d’envergure, nous avons pu à la fois participer au développement d’un moteur de recherche important pour la communauté scientifique et offrir de nouvelles ressources à celle des technologies open source destinées à la gestion documentaire. Ce qui correspond parfaitement à la philosophie de notre entreprise».


Une version bêta

Complété à l’interne, le nouvel Érudit est encore en version bêta, et au cours de l’année de nouvelles fonctionnalités seront graduellement intégrées au site. Dans l’esprit des technologies ouvertes, vous pouvez contribuer à l’amélioration de la plateforme en signalant tout bogue à l’adresse bogue@erudit.org, et vous pouvez aller consulter le projet sur github, où Érudit a même son propre dépôt.

En attendant ces améliorations, libre à vous d’aller consulter la plateforme de recherches et trouver une multitude de ressources sur le logiciel libre, entre les thèses, les mémoires de maîtrise, les articles de revue savante ou culturelle, vous aurez l’embarras du choix…