Bonjour tout le monde ! Je viens partager mon premier retour d’expérience sur Pagekit avec vous. Je vais essayer de poser les pour et les contres de ce CMS de la façon la plus objective possible.

Ok Guillaume, mais Pagekit c’est quoi ?

Comme dit ci-dessus c’est… un CMS. Il aurait pu être comme les centaines de solutions qui existent, mais il se démarque par les technologies sur lesquelles il repose. On ne va pas se mentir, c’est l’une des premières raisons qui nous a poussé à essayer cette solution.

Pagekit repose sur deux technos :

• PHP avec du Symfony 3.x : c’est toujours une bonne chose de préférer un framework robuste comme Symfony pour faire du PHP.
• JS (ES6) avec du Vue.js : ça c’est très sexy pour les développeurs… et les utilisateurs !

Bon passons sur le PHP, tout le monde sait pourquoi il est la, mais attardons-nous sur Vue.js. Pour ceux qui ne connaissent pas Vue.js ou React.js (c’est quasiment la même chose), il s’agit d’un framework front permettant de créer des interfaces utilisateurs dynamiques et réactives. Ce framework créer un lien très fort entre l’interface et les données. Il permet ainsi d’améliorer l’interface et l’expérience utilisateur simplement, tout en nous facilitant le travail pour y arriver et pour corréler une action utilisateur avec une modification de données. Que du positif !

Pagekit est livré avec un back-office fonctionnant parfaitement avec du PHP et du Vue.js. Pour le rendu front nous avons le choix entre du bon vieux HTML + PHP ou du twig.

Pagekit est d’une simplicité monstre dans son utilisation, il ne s’embarrasse pas avec une quantité astronomique de fonctionnalités : il existe dans le but de gérer de petits sites grâce à une gestion de contenu rapide et efficace.

Encore un bon point qui nous a poussé à tester cette solution en condition réelles.

Maintenant passons au vif du sujet ! Vous noterez que cet article est structuré de manière originale et inédite : nous étudierons les avantages dans un premier temps, puis… les inconvénients…

Avantages

Nous avons déjà parlé de la simplicité d’utilisation et de VueJS qui font que PageKit est un CMS agréable fonctionnellement parlant.
Le BO propose une interface beaucoup plus plaisante qu’un WordPress ou un Drupal, c’est rapide et réactif et encore une fois on ne s’embarrasse pas de fonctionnalités farfelues. Bref, Pagekit va à l’essentiel et ça fait du bien.

Côté développement, l’architecture est correcte, l’utilisation de Symfony est limitée au routing, à la gestion des requêtes et des réponses, à l’injection de dépendances ainsi qu’aux événements. En bref : l’essentiel sans que l’on ne s’embarrasse de choses inutiles.
Pour gérer les modèles de données on retrouve Doctrine ainsi qu’une surcouche développée par Pagekit pour la gestion des modèles et des interactions.

Dans Pagekit, tout est module ou packages. Il s’agit sensiblement de deux terminologies pour designer la même chose : un ensemble de fonctionnalités ayant un dénominateur commun. La création d’un module (ou d’un package donc) est très simple. Une fois assimilée, il est très facile d’alimenter Pagekit de nouvelles fonctionnalités. Chaque package peut avoir ses dépendances PHP et JS qui seront gérer respectivement par Composer et NPM.

Un package est défini par un simple fichier PHP retournant un tableau contenant clés et valeurs, on trouvera dans ce fichier :

– Le nom du package et son type
– Un entry point permettant d’initialiser le package
– Un tableau d’autoload permettant d’ajouter des namespaces et donc de travailler correctement
– Un tableau de configuration qui permet de définir les options du packages
– Un tableau de routes
– Un tableau gérant les entrées dans le menu
– Un tableau d’events, définissant les actions à mener en fonction de tel événement ou de déclarer ses propres événements

Il y a d’autres clés qui permettent d’affinéer un peu plus la définition du package et son interaction avec le Core mais les principales sont listées ci-dessus.

Par convention un package aura l’architecture suivante :

– /app : un dossier destiné aux composants et vues de VueJS ainsi qu’aux sources compilées
– /src : un dossier bundle classique de Symfony, si ce n’est qu’en racine, il prendra un fichier MonPackageModule.php
– /views : qui contiendra les vues front et back.
– index.php contenant les définitions expliquées un peu plus haut
– scripts.php destiné à gérer les événements d’ajout, de suppression, d’activation et de désactivation du package
– composer.json pour les dépendances PHP
– webpack.config.js pour gérer les dépendances JS ainsi que les compilations des sources JS.

Si vous avez déjà fait du Symfony 2.8+ et que vous connaissez à minima VueJS vous ne serez absolument pas déboussolé.

Inconvénients

Comme on l’a vu, Pagekit, en surface c’est cool. Cependant, quand on gratte un peu, on se rend compte qu’il est adapté à des types de projets bien précis et, dans notre cas, ça n’a pas été concluant…

Tout d’abord sur la partie Devops. Chez Adfab, nous faisons de l’intégration continue, ce qui se signifie que nous possédons plusieurs environnements plus ou moins différents et effectuons plusieurs déploiements par jours. Or, Pagekit intègre mal le concept de dépendance : nous avons du versionner certaines sources qui n’auraient jamais du l’être, nous avons du jouer des commandes spécifiques à des instants T du développement (par exemple jouer le script d’installation obligatoire au premier deploy sur chaque machine). Dans l’absolu, ce n’est pas le plus grave. Mais la gestion interne des paquets notamment avec les modules et les composer.json couplés aux webpack.config ne nous a vraiment pas simplifié la tâche et a multiplié les temps de déploiements.

Comme dit dans la première partie, Pagekit est simple… trop simple malheureusement. Ajouté un contenu dans une page se résume à un pseudo wysiwyg dans lequel la mise en forme passe par des balises HTML et c’est tout. Ce qui veux dire simplement que pour un CMS classique ayant 2 ou 3 gabarits de pages, vous devez connaître par coeur le code HTML et vos users aussi, s’il veulent ajouter des nodes correctement mises en pages.

Pour ceux qui ont travaillé sur des CMS, nous savons tous très bien que nous préférons travailler par blocs de saisie qui seront reconnus et formatés par le système puis insérés à une position précise dans le template. Si vous voulez le faire avec Pagekit il vous faudra le développer.

Et nous l’avons développé, ce qui nous a permis de soulever d’autres problèmes…

Le premier, et certainement le plus frustrant, est l’ORM maison de Pagekit. Ils ont développé une sur-couche qui est beaucoup trop simpliste. Autant vous dire qu’il sera plus simple sur des opérations complexe d’écrire directement vos requêtes en SQL…
Un petit point aussi sur les modèles : vous n’avez pas de gestion de Repository et ce qui sert d’Entity ressemble à ce que vous avez pu faire mais ne possède pas toutes les fonctionnalités de Doctrine… Du coup pour l’hydratation ou les valeurs calculés c’est du système D alors qu’il aurait été mille fois plus simple d’intégrer complètement Doctrine sans sur-couche.

Le deuxième, est que Pagekit ne dispose pas nativement d’une gestion multilangue, il vous faudra la développer. Le système de routing de Pagekit repose sur deux fondamentaux : Les routes inscrites en BDD et les routes annotés ou déclarés dans les configurations des packages.
J’étais sidéré de voir qu’une demande pour une feature de gestion du multilangue a été ouverte en 2014 et… l’est toujours !

Une fois que vous avez maîtrisé L’ORM et la gestion des dépendances de pagekit ça deviens plus ou moins simple de développer, mais ça reste fastidieux tout de même. Sans compter que vous ne pouvez pas vous reposer sur la documentation car tout comme le CMS, elle est minimaliste.

Nous pourrions aborder de nombreux autre points mais nous devrions écrire un livre et non plus un article.

Un petit dernier pour la route :

Si vous développez sous Pagekit, vous devrez rapidement connaître tout les événements du Core comme ceux des packages développés ou installés via le market, et ce pour une raison simple : ils ont un ordre de priorité et comme Pagekit est friand d’événements il n’est pas rare que votre code n’est pas l’effet escompté.

Pour conclure je ne peux pas qualifier Pagekit de CMS, au mieux c’est un framework servant de base pour développer une solution CMS personnalisée pour un client, mais ce qui est certain, c’est que Pagekit a encore besoin de travail et de maturité avant de pouvoir réellement mériter l’appellation de CMS.