Monofony: Utiliser Sylius sans e-commerce

Pour des clients, j'ai utilisé Sylius (surtout depuis 2019) pour réaliser leur boutique en ligne. Sylius est un framework e-commerce basé sur Symfony écrit en PHP. Il utilise des bundles intéressants et suffisamment décorrélés du e-commerce pour que j'ai eu envie de tester leur utilisation en dehors de Sylius.

C'est ce que j'ai fait en direct via des Lives tweet que j'ai ensuite retranscrit ici en article.

• Début d’un projet de hack de Sylius
• Projet de hack de Sylius : SyliusUiBundle
• Utilisation de GridBundle sans Sylius
• ResourceBundle hors de Sylius ?

Lors des Lives tweet, j'ai pris connaissance (grâce à vous) de l'existence de projet permettant d'utiliser soit un Sylius sans la partie e-commerce avec le Bundle de MonsieurBiz soit utiliser les bundles de Sylius dans un projet Symfony avec Monofony.

C'est sur ce dernier que j'ai réalisé un Live tweet et dont voici la retranscription.

Découverte de Monofony

Monofony, utilise principalement le RessourceBundle et le GridBundle de Sylius. L'utilisation du ThemeBundle (c'était le premier bundle que j'ai installé dans le projet hackSylius) pour gérer les thèmes des sites est possible.

J'ai eu le privilège de tester lors du live une version alpha pleinement fonctionnelle (ce qui est un très bon signe de qualité) avec une documentation bien faite et facile à suivre.

Ha oui, une note importante, comme indiquée dans la documentation, il faut bien connaitre le framework Symfony pour utiliser Monofony.

Pour ma part, la prise en main était facilitée par mes connaissances de Sylius. Mais ne vous en faites pas, la documentation de Monofony fournis le minimum. Pour plus de détails, elle renvoie vers la documentation de Sylius (la documentation de Sylius est également bien faite).

Lors de la lecture des prés requis de Monofony, PHP 8.0 était requis. Dommage pour moi, j'ai PHP 7.4 par défaut et PHP 8.1 installés. J'ai tout simplement utilisé PHP 8.1 en m'attendant à avoir des erreurs...

Installation

Pour l'installation j'ai simplement suivi les instructions de la documentation en veillant à bien utiliser PHP 8.1. L'installation s'est parfaitement bien déroulée. Par la suite, j'ai utilisé le client Symfony en configurant mon projet pour qu'il utilise PHP 8.1.

Pour la base de données (MySQL 5.7) j'ai utilisé Docker et configurer le projet comme tout projet Symfony 5 avec le fichier .env.local.

Le premier instant de vérité était proche. Je lance le serveur Web intégré au client Symfony puis j'ouvre la page d'accueil de mon site dans le navigateur. Et là c'est la page par défaut de Symfony qui apparaît. Je suppose qu'il n'y a pas de front.

Cette supposition est confirmée par la documentation, Monofony vous laisse libre d'installer API Platfom ou un front minimal en plus de l'admin. J'aime particulièrement que le choix nous soit laissé.

Donc pour le projet actuel, je vais donc installer le front minimal en suivant la procédure de la documentation.

À ce moment-là j'ai eu une erreur liée à la version requise lors de l'installation. Lors de l'installation du projet, j'ai utilisé une version alpha, je dois donc utiliser la version dev-master pour le bundle monofony/front-pack.

Après l'installation, je devais compiler les assets (JS, CSS, images) pour le front. Mais cela ne fonctionne pas. La solution est simple pour tous ceux qui ont l'habitude d'utiliser Webpak Encore avec plusieurs configurations.

La configuration du front n'est pas active dans le fichier de configuration de Webpack webpack.config.js. Hop, quelques lignes à commenter et dé-commenter et après une nouvelle compilation, tout est rentré dans l'ordre.

Pour un front minimal, il est pas mal. Il y a même le petit oiseau bleu (pas celui de Twitter) dans la WebDebugBar.

Petit tour du projet

Bon, c'est bien tout ça, mais là je n’ai pas encore commencé. Comme pour le projet hackSylius, le but est de gérer des articles de blog. Mais avant de commencer, faisons le tour du projet.

Dans la base de données, il y a les tables pour la partie OAuth, la gestion des utilisateurs admin, de l'application et de l'API dans des tables distinctes. Très similaire à Sylius tout ça. Ce n’est pas bien compliqué les tables Sylius ont les mêmes noms que dans un projet Sylius. La base de données est minimaliste, je peux donc ajouter ce que je veux.

Pour l'arborescence des fichiers, le premier niveau est similaire à un projet Symfony 5 standard.

Dans le dossier templates, il est facile de comprendre l'organisation. Une chose m'a quand même interpelé. Il y a beaucoup de fichiers. En fait, presque tout est là. Ce sont les fichiers du projet, pas de Monofony.

J'ai également constaté qu'il a refait toute l'interface admin. Il n'utilise pas le SyliusUiBundle. Ça se comprend, il n'est pas facile à utiliser en dehors de Sylius. J'ai bien galéré lors de sont utilisation dans le projet hackSylius.

Dans le dossier src, même constat que pour le dossier templates, il y a beaucoup de choses. Les entités doctrine sont dans mon projet. Il ne sera donc pas nécessaire de surcharger des services de Monofony.

Enfin, dans le dossier config (oui, j'ai exploré de bas en haut), ça ressemble encore à un projet Symfony standard avec quelques petits ajouts tel que le dossier sylius qui contient les routes et la configuration des ressources. Dans le dossier config/packages il y a 3 fichiers de configuration préfixée par monofony_, surement la config du framework. Le reste des dossier et fichier est connu si vous avez l'habitude de Symfony.

Bon, sans la documentation, j'ai quand même une bonne idée de ce qu'il faut faire pour ajouter une entité et la configurer en tant que ressource. Mais je préfère suivre la documentation, Loïc (l'auteur de Monofony) m'a prévenu que cette version utilisait la dernière version du GridBundle. Franchement, je n'ai pas encore regardé les nouveautés à venir dans ce bundle.

Ajout de l'entité Doctrine

Allez, j'entre dans le code, en ajoutant l'entité Article dans le dossier src/Entity/Blog avec uniquement le titre. Puis je configure le ResourceBundle pour qu'il gère l'entité.

Comme pour tout projet qui utilise Doctrine, il est nécessaire d'utiliser les migrations pour modifier la base de données. La première étape est la génération de la différence entre la configuration Doctrine présente dans le code et le schéma actuel de la base de données.

J'exécute la commande symfony console doctrine:migrations:diff, qui termine sur un constat étonnant : "Pas de changement détecté dans la configuration du mapping".

Pourquoi ? Je vais lire la configuration de doctrine dans le fichier, config/packages/doctrine.yaml et je constate que le type de mapping à utiliser est attribute. J'ai tout mis en annotation ! Il ne trouve rien ! Reste à convertir la configuration. Ce qui n'est pas très long.

La seconde tentative de génération du fichier de migration est la bonne. Comme toujours, je vérifie la conformité de ce que la machine a généré (oui, il ne faut pas lui faire confiance, parfois elle se trompe, ou vous montre que la configuration à un problème).

Puis, j'exécute la migration avec la commande symfony console doctrine:migrations:migrate.

Maintenant que la base de données est correcte, il reste à configurer :

• les routes de l'admin pour gérer les articles,
• la grille pour afficher la liste des articles,
• Ajouter un item dans le menu de gauche.

Configuration des routes

En suivant la documentation, il est nécessaire de configurer les routes. Pour cela, rien de plus simple, la documentation donne un exemple qui configure toutes les routes nécessaires pour la ressource.
Je change tout de même le nom de la ressource et de la grille. Puis je vérifie dans la console si tout est correct avec la commande symfony console debug:route | grep article.

D'habitude dans Sylius, je configure la grille avant les routes. La documentation ne propose pas le même ordre, ce n'est pas bien grave. Si vous tentez d'accéder à la page index de la ressource, vous aurez droit à une erreur.

Configuration de la grille

Pour la configuration de la grille, je m'attendais à un fichier YAML. Et bien non, l'une des nouveautés de la prochaine version du GridBundle est l'utilisation de PHP pour gérer la configuration des grilles.

Un avantage que je vois tout de suite est la possibilité de rendre la configuration des grilles dynamique grâce à la base de données. Attention quand même, cet avantage peut se retourner contre vous et devenir une belle usine à gaz.

Bon, pour mon projet, je configure ma grille dans la classe PHP et l'autoconfiguration de Symfony fera le reste.

Configuration du menu de l'administration

J'ai bien avancé, il me reste le menu de gauche à configurer. Le bundle utilisé pour ce menu est le KnpMenuBundle (comme dans Sylius).

En plus, je n'ai même pas besoin d'ajouter une classe, elle est déjà existante et configurée. J'ajoute donc quelques lignes de code pour ajouter un élément racine dans le menu et un élément enfant pour accéder à la liste des articles.

Tiens, ici, c'est la première fois que j'ai une clé de traduction, je vais donc l'ajouter dans les fichiers prévus à cet effet. Il y en a d'autres à ajouter pour l'admin, mais je m'en passerai pour le moment.

Ai-je terminé ? Il semblerait. Les templates sont ceux par défaut, le formulaire également, il est temps d'aller dans l'admin.

Où est l'admin et comment s'y connecter ?

Mais je n'ai aucune information sur l'URL à utiliser pour y accéder (même si je suppose que c'est /admin). Je cherche la route de l'admin avec la commande symfony console debug:routes qui affiche toutes les routes connues du projet. Et la confirmation ne se fait pas attendre... C'est bien /admin.

Maintenant, les identifiants de connexion. Lors de l'installation, une commande chargeait des fixtures (données d'exemple prédéfinies pour remplir la base de données). Je vais donc chercher les données correspondant à l'administrateur.

Visite de l'admin pour admirer le travail

Aller hop, dans le navigateur, direction l'administration. Connexion avec les identifiants trouvés dans les fixtures.

Ho ! Quel beau dashboard ! Et dans le menu de gauche, il y a bien mon menu !

Que se passe-t-il si je tente le chargement de l'index ? Tout va bien ! L'ajout d'un article fonctionne également, et une fois de retour sur l'index, le titre de mon article est bien affiché.

C'est génial, j'ai fait mieux et plu vite avec Monofony. Le projet hackSylius n'a pas de front et pas d'authentification.

Conclusion

Voici venu le temps de la conclusion. En premier, merci, Loïc, pour ton travail de qualité ! Maintenant les constats, le projet fonctionne parfaitement en PHP 8.1. Il est basé sur Symfony 5.4 LTS car les bundles ne sont pas encore disponibles pour Symfony 6.0.

Avec cette première approche de Monofony, j'ai pu constater la puissance de Symfony et des bundles Sylius. Le concept reste le développement rapide d'application. Mais vu la souplesse du ressource Bundle, vous pourrez toujours ajouter des events listener ou surcharger le contrôleur pour réaliser tout ce qui est nécessaire sans grand problème. En comparant mon expérience avec Sonata ou EasyAdmin, j'ai une préférence pour le ResourceBundle et GridBundle.

Il me reste une question : comment se passent les montées de version ? Pour répondre à cette question, il est nécessaire de l'expérimenter. Peu être un projet ? Si vous avez une idée, contactez-moi pour en parler.

Jean-Baptiste Nahan

Consultant Expert Web, j'aide les entreprises ayant des difficultés avec leur projet Web (PHP, Symfony, Sylius).

@jbnahan69 | Macintoshplus | Linkedin | JB Dev Labs