Transition vers ProcessWire pour Spiria.com

Après plusieurs sites faits avec le système de gestion de contenus ProcessWire pour ses clients, Spiria a décidé qu’il était temps de se débarrasser de son encombrant site en Drupal. Pour être honnête, ProcessWire est encore difficile à vendre auprès des clients, car ce CMS/CMF n’est pas aussi connu que les plus populaires.

La migration de Spiria.com vers ProcessWire servait donc plusieurs objectifs :

1. Éliminer les frustrations vécues avec Drupal (notamment avec la gestion des images et certains problèmes structuraux).
2. Permettre aux intégrateurs d’apprendre le CMS durant les périodes calmes, quand ils ne sont pas sollicités sur d’autres projets.
3. Promouvoir le CMS en l’adoptant.

Les défis furent nombreux, mais nullement insolvables grâce à la très grande polyvalence de ce cadre de programmation. En effet, si on peut considérer ProcessWire comme un CMS à part entière, il offre également tous les avantages d’un CMF. Contrairement avec d’autres solutions, le programmeur n’est pas contraint de suivre le modèle proposé et peut intégrer ses manières de faire.

Le blogue

Le site comprend un blogue très actif où les visuels abondent. Il était primordial de mettre en cache les diverses composantes dynamiques. Par exemple, dans toutes les sections du blogue, il y a une liste d’articles récents, une liste de « nouvelles brèves », une autre liste de textes du même auteur, une classification par catégories. Bref, ces listes évoluent indépendamment. Le système de cache de ProcessWire, et notamment sa capacité de classer par « namespace », a permis d’améliorer considérablement la vitesse de chargement. La gestion des fichiers de cache a été placée dans un « hook » de type « saved » dans l’utile fichier « ready.php ».

Migration des données

L’importation des données du blogue fut complexe, car à l’époque de la conception du site en Drupal, les programmeurs n’avaient pas su utiliser les « entities » facilement traduisibles, si bien que chaque article résidait dans deux « noeuds » (pages) différents. Nous aurions aimé nous servir du module d’importation de ProcessWire, mais celui-ci ne tient pas encore compte des champs multilingues. Nous nous sommes inspirés toutefois de ce code pour bâtir notre propre module d’importation. C’est une des très grandes qualités de ProcessWire, en tant que cadre de programmation (Content Managing Framework), il est aisé de se baser sur du code existant pour concevoir ses propres solutions.

Reproduire la maquette

La maquette actuelle du site a été reproduite à l’identique, car elle sert bien les besoins de la compagnie. ProcessWire a permis de simplifier le travail à bien des égards. En dehors du blogue qui est très structuré, les autres sections du site sont plus libres, notamment la section des études de cas (« Réalisations »). L’utilisation de champs de type « Page reference » a particulièrement aidé les développeurs. Comme tout est page dans ProcessWire, on peut créer une pseudo base de données relationnelle à l’intérieur même du site. L’utilisateur-administrateur prend davantage conscience de la hiérarchie des données et possède un meilleur contrôle sur ces données.

Architecture de la programmation

La séparation entre contrôleurs et fichiers de visualisation Twig facilite la gestion des multiples composantes du site. Nous n’avons pas vraiment exploré les « régions » de ProcessWire, car nous préférons ne pas mélanger ces aspects de la programmation. Cela facilite grandement l’arrivée ponctuelle de programmeurs dans notre département, habitués à une structure MVC, car ils comprennent mieux ainsi quoi fait quoi.

La recherche

Encore une fois, nous avons pu simplifier ce qui avait été fait dans Drupal. Il existe deux types de recherche sur le site, celle du blogue et la recherche plus générale de la page 404. La recherche de l’ancien site était mue par un serveur Apache Solr dans Drupal. Nous avons décidé de tabler sur l’aisance de ProcessWire et de la librairie Typeahead (pour le blogue), car nous n’avions pas besoin, de toute manière, de la puissance de SOLR (ou d’Elasticsearch). Un travail d’amélioration de la performance est encore à faire de ce côté. Nous aurions aimé que l’excellent outil de recherche offert du côté administratif soit disponible du côté « frontend ». Nous n’avons pas encore eu le temps d’explorer la possibilité de harnacher ce code du cœur de ProcessWire. Notre souhait ici est que le concepteur du CMS, Ryan Cramer, y voit ici une possibilité d’offrir une nouvelle excitante fonctionnalité à son CMS !

Des modules puissants

Nous possédons les excellents modules ProCache (mise en cache statique), ProFields (champs qui améliorent grandement les fonctionnalités des champs existants) et ListerPro (outil de recherche et de traitement des données). Comme le site est installé sur un serveur Nginx, nous avons écarté ProCache pour le moment et la seule utilisation de la fonction « cache() » nous satisfait. Les champs ProFields sont une bénédiction tout comme ListerPro. Ce dernier module est fort utile pour corriger, par exemple, des erreurs d’importation (nous avions plus de 800 articles de blogue dont certains datent de 2013).

Nous nous sommes servis d’un champ de type functional pour rassembler les traductions de termes qui normalement seraient restés codés à la dure et difficilement accessibles dans l’interface de traduction (un aspect à améliorer dans ProcessWire, selon nous). En regroupant les traductions dans une seule page, les administrateurs du site peuvent changer ou corriger facilement les termes.

La gestion des langues

Ce qui demeure un tout petit irritant pour nous est la gestion des langues pourtant fantastique à maints égards. Le fait qu’il existe une langue par défaut est à la fois une bénédiction et un problème. Par exemple, en 2013, les articles du blogue n’étaient pas systématiquement traduits. Nous avons vécu la même situation avec un site d’un client. Si l’article n’est qu’en anglais, aucun problème, nous n’avons qu’à ne pas cocher le français comme actif. Toutefois, si l’article n’est qu’en français, nous sommes quand même obligés de créer la page en anglais et de faire des entourloupettes dans le code, avec notamment une case à cocher du genre « Pas présent en anglais » pour reproduire le comportement naturellement présent pour l’anglais (ou toute langue jugée par défaut). Peut-être y a-t-il ici une solution plus élégante que nous n’avons toujours pas découverte. Ce n’est pas grand-chose, mais certains clients ne voient pas pourquoi il y a deux façons de faire ici.

En conclusion

Quoi qu’il en soit, les grandes qualités de ProcessWire continuent de plaire tout autant aux programmeurs, intégrateurs, graphistes qu’aux utilisateurs. La solidité du CMS/CMF, ses fonctionnalités toutes traduites en objets/variables ($pages, $page, $config, $sanitizer, $input… la liste est longue) nous permet de systématiser notre flot de travail, de récupérer facilement du code et de réduire ainsi les coûts de production.

Bien qu’il soit risqué de n’offrir qu’une solution CMS à nos clients (le syndrome du marteau qui ne voit que des clous), il est tentant de considérer ProcessWire comme le couteau suisse par excellence de la programmation Web. Comme il a été dit plus haut, le CMF se prête à toutes les situations, possède de très bons outils sécuritaires et son concepteur a réussi à bonifier PHP pour rendre la programmation très agréable et intuitive.

Pour nous, migrer le site de l’entreprise vers cette plateforme était le plus bel hommage que nous pouvions faire à son concepteur, Ryan Cramer.