Flat-file CMS : votre préféré ?
il y a 7 ans par VeroniqueFritiere

Il existe plus de 400 générateurs de sites statiques.

Le XML, bien qu'éprouvé, est loin d'être simple à utiliser pour le béotien. En revanche le Markdown, pensé pour écrire et mettre en page facilement n'importe quel texte, est de plus en plus utilisé partout où l'on propose à l'utilisateur (administrateur ou visiteur) de contribuer.

En effet @EtienneZulauf, le XML est une solution technique, toutefois l'utilisateur lambda et donc par définition béotien utilise une interface graphique.

Plus celle-ci est aisée à utiliser et mieux c'est pour lui.

L'avantage d'un tel système c'est de respecter le principe du modèle Vue-Controleur.

Certains CMS proposent des modules "Full Page Cache" qui génèrent effectivement des versions pré-compilées des pages. (J'ai pas trouvé sur Prestashop, vous avez un nom ?). Mais cela n'est pas possible partout, surtout sur une boutique en ligne, car dès lors qu'on a des articles dans le panier ou qu'on est connecté à son compte, plusieurs parties des pages sont spécifiques à VOTRE visite. Elles doivent donc rester dynamiques.

L'intérêt d'un site statique est sa rapidité ! Vraiment, c'est époustouflant. Et c'est bon pour le référencement et pour l'expérience utilisateur. 

Accessoirement (ironie), cela limite aussi les attaques : pas de code interprété, pas d'accès en direct à une base de données : pas de possibilité de hacking.

Enfin, la charge peut être grandement accrue à puissance d'hébergement égale, bien entendu, ce qui peut faire faire de grosses économies pour un site très fréquenté. On peut avoir beaucoup d'argent, mais le mettre à des postes plus intéressants.

Je t'invite à lire l'article que j'ai partagé, il est plein d'enseignements à ce sujet.

Je connais assez bien les fichiers plats pour avoir codé dans le passé de petites moulinettes permettant de convertir des fichiers ASP/PHP reliés à une base de données (SQL, MySQL, PostgreSQL, etc.) en fichiers HTML. De plus, je n'utilise que très rarement les modules commerciaux ou gratuits permettant de faire ce type de job, sachant que si j'ai cité Prestashop, c'est pour avoir développé ce genre d'outils pour plusieurs de mes clients qui avaient justement choisi ce CMS.

D’ailleurs, cela doit faire 15 ans que j'essaye de faire la promotion des fichiers plats. Mais à cette époque, la mode était plus au "tout dynamique", avec des sites 100% en PHP ou en ASP, reliés à des bases de données situées sur le même serveur. Manque de bol, dès qu'un site de ce type arrive à 3000/5000 visiteurs, il faut impérativement envisager, soit l'évolution du serveur, soit l'utilisation d'une autre technologie beaucoup moins consommatrice de ressources. Et comme nous sommes dans une société qui pousse inévitablement à la consommation, il n'est pas rare que les hébergeurs soient complices de certains développeurs, poussant leur clientèle à faire évoluer leur serveur, au lieu d'envisager de migrer vers une technologie moins hype, mais beaucoup plus adaptée à une consultation intensive d’un même site web par une multitude d’internautes. 

Tu retombes toujours sur tes pattes hein ? ;-)

C'est pas une question de mode mais de quoi on a besoin et de ce qui est disponible :  On ne peut pas faire une boutique en ligne avec des fichiers plats, les générateurs de sites statiques sont pérennes et évolués depuis peu, il y a 15 ans naissaient les premiers CMS et cela a permis à des gens de contribuer leur site sans savoir faire de HTML, ne mélangeons pas tout !

C'est pas un aspirateur de site qui permet de comprendre l'intérêt d'un générateur de site statique, faut essayer !

Quant à la théorie du complot sur la puissance des serveurs, faut juste regarder le temps qu'on donne aux développeurs pour se former et faire le job. Avec moins de dumping social, ils sauraient et auraient le temps d'optimiser leurs requêtes et mettre du cache, et tout irait bien. Tu mets WP Super Cache sur ton Wordpress et tu fais 5K visites/jour avec un RaspberryPi ! Après y a aussi ceux qui croient tout savoir et font de la grosse M§!$# mais là y a pas de solution.

Je n'ai jamais dit que je savais tout. Mais sur ce coup-là, j'ai réellement une certaine expérience, ce qui explique pourquoi je suis intervenu lorsque @VeroniqueFritiere a posé sa question.

Après, il existe plusieurs manières de développer une boutique en ligne utilisant des fichiers plats. Dans la mienne, j'utilise deux serveurs : un pour le frontoffice et un pour le backoffice. Le frontoffice est en fichiers plats avec une toute petite pointe de fichiers dynamiques (par exemple, pour l'accès au compte client). Quant au backoffice, il est purement dynamique. C'est lui qui va générer les fichiers plats à partir des éléments contenus dans sa base de données. L'ensemble des fichiers plats est ensuite uploadé, soit de manière automatique, soit via un programme tiers (ex: FileZilla), sur le serveur distant.

Cette manière de faire a plusieurs intérêts. La première, c'est qu'avec des fichiers immédiatement accessibles, elle favorise grandement le référencement naturel (surtout si le frontoffice, présent sur un serveur en HTTPS, est régulièrement mis à jour). Ensuite, elle est hautement sécuritaire, car le hacking est quasi-impossible. Je dis quasi-impossible, car il faut tout de même que la petite partie dynamique du frontoffice soit correctement codé. Pour finir, elle se base sur une règle d'or en matière de sécurité informatique, où c'est le serveur le plus sécurisé qui doit se connecter au serveur le moins sécurisé (par exemple, pour aller récupérer les commandes des clients).

Pour finir, je pense que c'est maintenant à @VeroniqueFritiere de voir si nous avons répondu correctement à sa question.