Soosyze - CMS sans base de données

a marqué ce sujet comme résolu.
Auteur du sujet

Bonjour tout le monde,

Je m’appelle Mathieu, j’ai 26 ans et ça va faire déjà 8 ans que je développe des applications web.

Il y a 2 ans, dans le cadre de ma veille technologique je suis tombé un peu par hasard sur le concept de micro CMS sans bases de données.

Je trouvais incroyable que des développeurs puissent proposer des systèmes aussi simples et ouverts à tous avec aussi peu de contraintes.

Mais en explorant l’univers de ces CMS, de nombreux détails m’ont interpellé:

  • Manque ou même absence de documentation,
  • Si la documentation existe, elle est mal organisée ou partagée,
  • Manque de visibilité des interfaces et des fonctionnalités,
  • Peu ou pas de tutoriel ou de FAQ pour l’essentiel des CMS visités,
  • Peu ou pas de modules et thèmes complémentaires,
  • Utilisation de bibliothèques externes sous exploitée,
  • Mauvaise mise en valeur des modules et thèmes complémentaires.

Je me suis alors dit que je pouvais aussi proposer ma vision de ce que pourrait être un micro CMS. Un projet qui resterait simple, mais avec une approche plus professionnelle du développement.

Je me suis donc mis à étudier fortement (ou à revoir) les frameworks MVC et MVC objet, le fonctionnement du SQL et de la théorie des ensembles, les différentes méthodes du noSQL, les tests unitaires, les outils d’aide au développement, les concepts de micro service, les recommandations PHP (PSR), les design paterns, les hooks… et c’est ainsi que Soosyze CMS est né.

Jusqu’à présent seuls quelques amis ont pu visualiser mon projet et je viens tout juste de finir une version assez satisfaisante pour qu’il puisse fonctionner correctement.

C’est dans cette optique que je viens chercher vos avis pour continuer à améliorer mon projet. Je suis prêt à entendre toutes les critiques (un tant soit peu constructives) sur ce qui pourrait être ajouté, amélioré ou supprimé.

En espérant susciter votre intérêt ;)

+4 -0

Salut,

Clairement, il y a du boulot derrière !

Je ne suis pas utilisateur de ce genre de solutions, je n’ai donc pas vraiment d’éléments de comparaison. Mais étant développeur PHP, ça me parle quand même un peu. ;)

Plusieurs choses me font tiquer :

  • Tu parles d’un CMS sans base de données. De mon point de vue, c’est faux. Tu stockes bien des données quelque part (en JSON a priori) Ce n’est pas du SQL, mais si tu stockes des données, tu as une base de données. Tu écris d’ailleurs ceci dans la doc :

Si vous avez lu la documentation ou la présentation de SoosyzeCMS, vous ne serez pas surpris quant à l’utilisation de la bibliothèque QueryFlatFile pour nos modules.

Pour rappel, Queryflatfile est une bibliothèque de base de données NoSQL orientée documents écrits en PHP. Elle stocke les données par défaut au format JSON (flat file). L’objectif est de pouvoir manipuler des données contenues dans des fichiers de la même façon dont ont manipule les données avec le langage SQL.

  • Une doc en français. C’est cool, mais si tu veux que ton CMS rencontre un certain succès, la doc en anglais est indispensable. Alors je sais qu’on n’a pas tous un super niveau d’anglais et que c’est chronophage (déjà ta doc en français a dû te prendre un temps monstre), mais bon…
  • Pas de système de template. Pour moi, revenir à du PHP pur dans un template est impossible, ne serait-ce que parce que tu peux y faire ce que tu veux : des requêtes, de la session, etc.
  • Dans tes exemples de contrôleurs, tu ne fais pas de type hinting sur $req, et c’est dommage.
  • Ça manque d’un Docker pour tester rapidement.
  • Les URL sont moches avec le ? à l’intérieur.

Ce sont quelques points comme ça, j’avoue n’avoir pas lu la doc entièrement. Si j’ai du temps, je referais un tour.

En tout cas bravo à toi, ça représente un sacré travail !

Développeur Symfony

+1 -0
Auteur du sujet

Bonjour John est merci pour ton retour,

Tu parles d’un CMS sans base de données. De mon point de vue, c’est faux. Tu stockes bien des données quelque part (en JSON a priori) Ce n’est pas du SQL, mais si tu stockes des données, tu as une base de données.

J’ai eu également une autre remarque sur l’emploi du "NoSQL"/"Sans base de données" d’un autre utilisateur et c’est une erreur de ma part de ne pas avoir détaillé dans la documentation l’utilisation de ces adjectifs.

Les différences entre une base de données SQL et noSQL peuvent porter à confusion. Je suis partie du principe qu’un SGBD (du type MySQL, Postgres, Oracle…) est un middleware communiquant avec un serveur HTTP stockant les données sous forme de tables relationnelles. Et d’après ce que j’ai pu lire sur le concept du noSQL (du type MongoDB, Redis ou Cassandra pour ne citer qu’eux :p ), les données peuvent être orientées objet, par clé valeur, fichier ou colonnes.

Dans le cas de Queryflatfile il s’agit d’un ensemble de scripts PHP qui normalise et stock des données dans des fichiers et non d’un logiciel applicatif, c’est pour ça que j’utilise les termes "sans base de données" et "NoSQL".

Une doc en français. C’est cool, mais si tu veux que ton CMS rencontre un certain succès, la doc en anglais est indispensable. Alors je sais qu’on n’a pas tous un super niveau d’anglais et que c’est chronophage (déjà ta doc en français a dû te prendre un temps monstre), mais bon…

Effectivement une documentation en anglais est impératif. J’ai voulu commencer par une doc en français, car mon niveau d’anglais n’est pas très glorieux (j’avoue :honte: ).

Plus sincèrement, j’attends surtout une stabilité et une gestion du multi-langage dans Soosyze CMS pour pouvoir faire une traduction de la documentation. Par exemple la version alpha5 qui est en développement va changer radicalement les derniers chapitres de la doc développeur et utilisateur.

Pas de système de template. Pour moi, revenir à du PHP pur dans un template est impossible, ne serait-ce que parce que tu peux y faire ce que tu veux : des requêtes, de la session, etc.

Je n’ai pas utilisé de système de template (comme Twig ou Smarty) bien qu’ils apportent de nombreux avantages comme la mise en cache des vues. Mais pour avoir travaillé sur Symfony (tout du moins là 2.8 et 3.x), quel que soit le système de template, si tu injectes des modèles dans les vues tu peux aussi réaliser des requêtes, je pense que tout dépend de la rigueur du développeur ^^ .

J’ai choisi de rester sobre comme Laravel avec Blade. Ça évite d’avoir une surcouche dans les vues qui peuvent ralentir l’exécution de ton affichage tout en restant propre avec la syntaxe courte des instructions PHP (comme <?php foreach() :?>< ? endforeach ;?>). Les IDE traitent cette syntaxe comme des balises à part entière et indente ton code correctement dans les vues.

Dans tes exemples de contrôleurs, tu ne fais pas de type hinting sur $req, et c’est dommage.

La variable $req est une instance de Psr/Http/Message/RequestInterface. J’aurais dû le typer dans les contrôleurs :honte: , je note ton conseil pour le corriger dans une prochaine version.

Ça manque d’un Docker pour tester rapidement.

Pour Docker c’est en cours :) je me suis loué un VPS et je me forme à son utilisation. Mais comme pour la documentation en anglais j’aimerais attendre une version un peu plus stable avant de créer une image docker (ça n’engage que moi, mais je tiens à dire que Docker est vraiment un très bon outil).

Les URL sont moches avec le ? à l’intérieur.

Pour le ? Dans les URL j’ai cherché autant que j’ai pu dans la documentation Apache pour faire un beau URL Rewriting, mais sans succès :'( .

Je poserais la question sur le forum pour voir si quelqu’un peut m’aider sur le sujet.

Merci encore pour tes suggestions et axes d’améliorations ^^ .

+0 -0

Salut,

En fait MySQL, Postgres et Oracle sont des SGBDR (R pour relationnel). NoSQL est un système de gestion de base de données non relationnelles.

Pour le choix de ne pas utiliser de templates, deux points :

  • les intégrateurs, spécifiquement les fronts pas ou peu développeurs, ne vont pas aller vers un CMS où il faut faire du code. Le pseudo code des gestionnaires de templates est parfait pour ce type de profil.
  • les développeurs qui ont pris l’habitude de travailler avec twig vont faire la moue à repasser sur du PHP pour leur front.

Concernant l’url rewriting il te faut passer par un fichier .htaccess au même niveau que ton index.php.

+0 -0
Auteur du sujet

Bonjour obedient,

En fait MySQL, Postgres et Oracle sont des SGBDR (R pour relationnel). NoSQL est un système de gestion de base de données non relationnelles.

Merci pour tes précisions :D , bien que Queryflatfile ne soit pas un système de base de données relationnel, la désignation comme étant du NoSQL est sujet à discussion. Pour vous dire, j’hésite à changer ce terme par flat-file (qui lui est plus juste pour le coup).

les intégrateurs, spécifiquement les fronts pas ou peu développeurs, ne vont pas aller vers un CMS où il faut faire du code. Le pseudo code des gestionnaires de templates est parfait pour ce type de profil. les développeurs qui ont pris l’habitude de travailler avec twig vont faire la moue à repasser sur du PHP pour leur front.

Je n’avais pas vu ce problème dans ce sens :honte: . Effectivement ça peut-être problématique pour les intégrateurs front-end de repasser par la syntaxe PHP. Mais on peut prendre aussi l’inverse qui peut-être vrais. Les développeurs back-end qui ont pris l’habitude de travailler avec la syntaxe PHP vont faire la moue à repasser sur du pseudo-langage pour les vues de leurs modules. Et puis entre nous je ne vois pas de difficulté entre {{ $var }} et <?php echo $var; ?> :diable: .

Honnêtement je me fais l’avocat du diable. Mais, plus sérieusement les développeurs utilisent de plus en plus les pseudo-langages d’intégration. Le système de template fonctionne avec un service, il serait tout à fait possible de changer le système actuel par du Twig assez simplement, voir faire cohabiter les 2.

Je pense plutôt attendre de voir comment va évoluer le projet et aussi d’avoir un plus d’avis avant de prendre ce genre de décision.

Concernant l’url rewriting il te faut passer par un fichier .htaccess au même niveau que ton index.php.

J’ai bien un .htaccess à la racine du projet pour le serveur Apache HTTP et aussi un fichier .nginx.config pour NGINX. J’utilise le projet https://github.com/h5bp/server-configs-apache qui offre un bon nombre d’exemple pour la mise en place du fichier .htacess pour Apache 2,2 et 2,4+ et aussi le la documentation officielle d’Apache https://httpd.apache.org/docs/2.2/fr/howto/htaccess.html

Mon problème se situait dans la façon de récupérer la donnée fournit par le serveur à travers le routeur.

J’ai refait une tentative dernièrement et j’ai trouvé comment faire. Je mettrais en place un patch prochainement pour avoir des URLs plus propres ;) .

Merci encore pour ton retour, comme pour John, tu as soulevé des points intéressants ^^

+0 -0

les intégrateurs, spécifiquement les fronts pas ou peu développeurs, ne vont pas aller vers un CMS où il faut faire du code. Le pseudo code des gestionnaires de templates est parfait pour ce type de profil. les développeurs qui ont pris l’habitude de travailler avec twig vont faire la moue à repasser sur du PHP pour leur front.

Je n’avais pas vu ce problème dans ce sens :honte: . Effectivement ça peut-être problématique pour les intégrateurs front-end de repasser par la syntaxe PHP. Mais on peut prendre aussi l’inverse qui peut-être vrais. Les développeurs back-end qui ont pris l’habitude de travailler avec la syntaxe PHP vont faire la moue à repasser sur du pseudo-langage pour les vues de leurs modules. Et puis entre nous je ne vois pas de difficulté entre {{ $var }} et <?php echo $var; ?> :diable: .

Honnêtement je me fais l’avocat du diable. Mais, plus sérieusement les développeurs utilisent de plus en plus les pseudo-langages d’intégration. Le système de template fonctionne avec un service, il serait tout à fait possible de changer le système actuel par du Twig assez simplement, voir faire cohabiter les 2.

noelma

En tant que développeur back-end Symfony, je fais également du Twig. Au boulot, mais aussi sur des projets personnels. Je ne connais aucun développeur Symfony, même back-end, qui ne connaisse pas la syntaxe Twig.

Quant à la simplicité du langage, tu triches un peu. Car oui, {{ var }} et <?php echo $var; ?> sont faciles à écrire (encore que la syntaxe Twig est quand même bien plus rapide). Mais prenons un exemple plus complet :

# PHP
if (empty($array)) {
    echo 'Aucun résultat !';
} else {
    foreach ($myArray as $value) {
        echo '<strong>'.$value.'</strong>';
    }
}

# Twig
{% for value in myArray %}
    <strong>{{ value }}</strong>
{% else %}
    Aucun résultat !
{ %endfor %}

Et je ne parle même pas des variables disponibles automatiquement dans les boucles. Ni du reste.

Pour moi utiliser un moteur de template (quel qu’il soit) est vraiment un plus. Après je conçois que tu ne veuilles pas en utiliser un, ou que tu attendes de voir comment va évoluer ton projet afin d’en implémenter un.

Développeur Symfony

+0 -0

Je ne veux pas avoir l’air d’insister mais :

Pour un CMS, un moteur de template permet une grande facilité d’adaptation du site pour la création ou la personnalisation d’un thème sans avoir à s’embêter avec des fonctions php. Les templates offres de meilleures possibilités d’intégration des vues que le php + html. Et un moteur de template impose le respect de la séparation de la vue et du reste (la logique) ce qui est bien.

Si je dois citer un élément indispensable à utiliser dans une vue c’est extends avec les blocs.

Je trouve qu’un CMS sans moteur de template est un point négatif car il sera compliqué de créer un thème ou de le personnaliser.

+0 -0

Je trouve qu’un CMS sans moteur de template est un point négatif car il sera compliqué de créer un thème ou de le personnaliser.

Visiblement, son CMS gère déjà les thèmes. Et php n’est pas moins puissant en terme de personnalisation que twig.

Et je ne parle même pas des variables disponibles automatiquement dans les boucles. Ni du reste.

Pour ma part c’est le système d’héritage que j’apprécie dans twig.

Mon problème se situait dans la façon de récupérer la donnée fournit par le serveur à travers le routeur.

Ok, j’avais mal compris ta problématique.

il serait tout à fait possible de changer le système actuel par du Twig assez simplement, voir faire cohabiter les 2.

Pouvoir switcher d’un gestionnaire de template à un autre, ça ce serait un gros plus. Après dans la pratique, la plupart de mes services symfony implémentent des méthodes pour twig. Pour gérer cela tu devras passer par une abstraction, c’est peut-être pas la solution la plus simple que tu choisis mais donner le choix c’est assurément une bonne chose.

+0 -0
Auteur du sujet

Bonjour Zestedesavoir :),

Je reviens à nouveau sur ce post pour vous informer que la version 1.0.0-alpha5 de Soosyze CMS est disponible depuis quelques temps.

Il y a eu pas mal de nouveautés, mais principalement l’ajout de la gestion utilisateur. Si vous souhaitez en savoir plus, j’ai résumé les nouveautés avec des captures d’écran sur ce post : https://soosyze.com/blog/2019/04/29/version-soosyze-alpha5

N’hésitez pas à me faire des retours ou à me signaler des bugs ;).

+0 -0
Auteur du sujet

Salut tous le monde :)

La nouvelle version de Soosyze est actuellement disponible en alpha6.1 Quelques nouveautés viennent se rajouter au projet, mais principalement coté back-end. Vous pouvez vous renseigner directement sur ce post : https://soosyze.com/blog/2019/06/12/soosyze-cms-1–0-0-alpha6

Il est divisé en 2 parties, l’une plus accès pour les utilisateurs et l’autre pour les développeurs ^^. Toujours dans un souci d’amélioration, n’hésitez pas à me faire part de vos retours ou/et de bugs éventuels :)

Le projet continue ^^

+0 -0
Auteur du sujet

Hey ! c’est la rentrée (avec un mois de retard :D )

J’ai pas eu beaucoup de nouvelle pendant cette pause estivale mais bon, j’en est pas donnés pour autant :honte: .

Cette rentrée apporte de nombreuses nouveautés riches pour l’utilisateur, entre autre le module Bock pour disposer des contenus en drag & drop, la traduction Anglais/Français de l’interface et une installation du CMS personnalisé.

Si vous souhaitez en savoir plus sur les changements vous pouvez lire notre article : https://soosyze.com/blog/2019/09/24/c-est-rentree-alpha8

Et si vous êtes du genre minutieux et que vous voulez tous savoir, il y a aussi le Changelog sur Github : https://github.com/soosyze/soosyze/releases/tag/1.0.0-alpha8

Sinon nous avons suivie le retour d’un utilisateur pour traduire le CMS. Il reste encore pas mal de travail à ce sujet comme la traduction du site et des autres bibliothèques conçues pour le projet, mais c’est en de bonne voie.

Vous pouvez aussi participer à la traduction (si le coeur vous en dit) sur l’instance Zanata de Framasoft (logiciel de traduction de projet) à cette adresse : https://trad.framasoft.org/project/view/soosyze?dswid=-66

La traduction n’est pas parfaite, si vous trouvez quelque chose à en dire faites-le-nous savoir

Ah sinon ça sera la dernière version alpha du projet.

Tout sera fait pour que la prochaine version possède toutes les fonctionnalités voulues à la base de Soosyze. Nous passerons donc la prochaine version en bêta à la recherche des bugs et autre faille de sécurité ;)

Sinon n’hésitez pas à nous faire vos retours d’utilisateurs/développeurs :)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte