Si vous avez digéré l’article précédent (ce qui peut être allé très vite, si vous êtes un vrai geek), il est temps maintenant de plonger dans la réalité de cette affirmation étonnante « un site statique, c’est mieux qu’un site dynamique ».

Et pour cela, le mieux est d’écouter cette vidéo, une présentation de Clément Delafargue, intitulée « les sites statiques, une alternative aux CMS« . La qualité est moyenne, mais elle n’est pas très longue — un quart d’heure — et très intéressante. (En dehors d’un petit WordPress Bashing).

J’avoue, au tout début, j’avais envie d’être plutôt caustique, ça ne commençait pas très bien, en réalité, même si nous sommes en désaccord sur certaines choses, je suis beaucoup plus en accord avec cette vidéo qu’avec l’article disant que le site statique était meilleur en tout !

La méthode consiste à utiliser GitHub pour générer des pages HTML qui sont ensuite publiées

Et c’est dit dès le début :

Le CMS c’est Git

Comment cela fonctionne ? C’est expliqué ici, sur l’accueil de Git Pages.

Vous utilisez un logiciel, soit GitHub pour Windows ou pour Mac, soit mieux encore un terminal.

Si vous utilisez un terminal, pour créer un fichier index.html qui dit « Hello World », vous allez d’abord générer le fichier :

copie d'écran

Créer une page qui dit « Hello World » dans Git Pages

Et ensuite vous allez le « Add, Commit, Push » pour avertir le monde que vous lui dites « Hello » … autrement dit l’enregistrer et le publier « via le FT¨ » (dans notre monde de WordPresseurs et autres amateurs de sites dynamiques).

copie d'écran

Publier une Git Page

 

L’interface est légèrement moins conceptuelle dans le cas du client Windows (on créé quand même son petit fichier .html), mais reste du même niveau d’austérité absconse.

Après, évidemment, on peut faire des sites avec des fichiers plus complexes : on va mettre des variables dans les fichiers html, par exemple pour le titre de la page. Pour créer un article de blog, on va d’abord créer un fichier dont le nom doit impérativement commencer par la date… On peut créer des templates complexes, créer des fichiers pour stocker des données. Il est impératif de respecter une structure de fichiers, de titres…

Et pour afficher une liste d’articles avec l’extrait, on fait quelque chose qui rappelle étrangement « The Loop » :

Screenshot

Liste d’article dans Jekyll, le blog de GitHub

J’arrête ici, si vous voulez voir en live ce que cela donne, le blog de Clément Delafargue est un bon exemple.

On a simplement, avec une approche « peu conviviale », un CMS, qui gère dans GitHub des contenus éditables, pour générer ensuite des pages, qui vont être publiées.

Il s’agit d’un site dynamique, et pas d’un site statique. La seule différence : on a scindé la génération dynamique et le fichier stocké sur le serveur, autrement dit, on a fait un système de cache en supprimant toute possibilité d’interaction dynamique pour le visiteur.

Voici, au cas où vous n’auriez pas écouté la vidéo, quelques citations de Clément :

C’est vraiment un Workflow fait pour les développeurs

le CMS c’est Git

La publication c’est un peu galère — sans doute la phrase que j’ai préférée, sacrée la litote de l’année, voici une partie de l’explication (en anglais)

On retombe dans les mêmes travers que les CMS qui sont basés sur des moteurs de blog, quand on commence à faire de l’internationalisation il va se péter la gueule assez rapidement

Le gros problème, c’est que si vous demandez à des gens d’éditer le contenu et que c’est pas des devs ça va leur faire vraiment tout drôle et s’il se plante dans le MakeFile il y aura des conflits à résoudre très régulièrement

Autrement dit, un outil de geek et de techos, fait pour les techos.

On est à dix mille lieux de « le client peut modifier son site statique s’il le veut facilement » de l’argumentation précédente.

Je dirais même que le client normal, celui à qui on a déjà du mal à apprendre comment utiliser TinyMce qui ressemble tellement à Word, s’il quitte son développeur, il va regarder les fichiers .html, et il va venir sur le forum de support demander s’il ne peut pas récupérer automatiquement son contenu pour alimenter son thème Artisteer.

Une bonne âme va lui répondre que oui, il y a un outil pour faire ça…. un outil qui reprend tout le contenu de la page et la met dans le post_​content, marquage html incompatible avec le thème inclus !

Les limitations d’un système de site statique généré automatiquement

L’absence (quasi totale) d’interactivité

C’est la construction du système qui le veut : l’absence totale d’interactivité, puisque le CMS est uniquement en « push » (envoi à partir du système central). Pour avoir malgré tout un système de commentaires sur son blog, Clément Delafargue est obligé d’utiliser Disqus, un outil externe.

Disqus a été très à la mode, il l’est encore beaucoup, plus dans le monde anglo-​​saxon que francophone. Comme tous les outils tiers, je n’aime pas, parce que les données ne sont pas « chez moi », et parce que l’intégration de Disqus génère un grand nombre de liens dofollow vers la plateforme.

Le mailto au lieu du formulaire de contact

L’absence d’interactivité, c’est aussi l’absence de formulaire de contact. Tout dépend de ce que gère le site, vous pouvez considérer que les données de vos contacts sont confidentielles et que vous ne voulez pas leur faire courir de risque. Reste donc ce bon vieux mailto, un attrape-​​robots leecheurs de mail, votre boite sera inondée. Pire, si vous faites le site pour un client pas très calé en informatique, vous lui faites courir un autre risque : que sont adresse email, récoltée par des robots, soit ensuite utilisée pour un phishing qu’il ne saura pas identifier.

Markdown

Une partie du système repose sur l’utilisation de Markdown à la place du code html.

Markdown, qui va être ensuite interprétée comme du HTML, soit par un plugin dans un CMS (genre Jetpack pour WordPress), soit par le générateur de contenu statique, dans le cadre de Github.

Elle a l’avantage très important d’être beaucoup plus lisible qu’un code source (pas de balises ouvrantes, fermantes…) et d’être utilisable dans un grand nombre d’outils.

Elle a deux inconvénients : contrairement à HTML, elle n’est pas standardisée. Et la syntaxe Markdown d’origine est très minimaliste. En conséquences, diverses versions de Markdown ont été développées, et si vous n’avez pas la bonne, votre document ne sera pas bien interprété.

Retour aux sources, à l’époque des grosses incompatibilités entre les navigateurs… dommage pour un outil de simplification.

L’optimisation pour le référencement

Or, dans la syntaxe Markdown manque tout ce qui est relatif aux données structurées, que ce soit sous la forme microdata ou schema.org (si vous trouvez une version de Markdown qui permette de rajouter des itemscopes par exemple, ça m’intéresse).

Si vous utilisez le gestionnaire de GitHub, vous avez la possibilité de créer vos documents en HTML, et donc d’insérer un marquage sémantique. Simplement, vous devrez le faire en code, sans éditeur de texte visuel, avec tous les risques d’erreurs… et une lisibilité largement inférieure à Markdown !

La sécurité ?

Là encore, j’attends le prochain article pour vraiment développer sur la sécurité. Mais en résumé :

  • oui, une solution purement statique est difficilement hackable
  • non, cela ne supprime pas les problèmes de sécurité, cela les déplace, notamment sur GitHub ou, éventuellement, au niveaux des scripts embarqués comme Disqus
  • la complexité de l’outil, les risques de problèmes lors de la publication génèrent aussi de nombreuses possibilités de montrer un site « cassé ». S’il ne s’agit pas d’un piratage, l’effet sur le visiteur qui arrive au mauvais moment n’est pas bon non plus.

J’aurais pas aimé le faire sous WordPress … chiche ?

C’est un commentaire de Clément en montrant un site réalisé avec ce système, pour un événement un peu similaire à un WordCamp.

Voici le site : http://scala.io/2013/

Fonctionnalités assez simples, une liste des séances, des orateurs, la langue des orateurs.

Un fichier Markdown par Talk, un fichier Markdown par Speaker et tout est lié

Oui, mais lié comment ?

Parce que lier les orateurs aux séances, avec WordPress, c’est extrêmement simple !

  • option 1 : on a un seul orateur ? C’est un « user« , qui va être considéré comme l’auteur du post décrivant la séance. Après, archive d’auteur (core de wordpress), archive des articles par auteur…
  • option 2 : on a le risque d’avoir plusieurs orateurs pour une séance ? On peut utiliser des champs personnalisés (custom meta), avec une metabox qui présente la liste des « user », et permet une sélection multiple. Uniquement des fonctions du core de WordPress et une connaissance du HTML et du PHP. Une heure pour faire ça avec la belle interface user-​​friendly, celle qu’on n’a pas dans GitPages.

Les autres éléments, que ce soit au niveau des séances (lieux, horaire, niveau, langue, etc) peuvent parfaitement être gérés par des taxonomies et des champs personnalisés, en standard de WordPress. Là encore, le plus gros du travail, si on n’utilise pas un framework comme WP ALCHEMY, sera de développer les métabox qui permettront à n’importe quel utilisateur de saisir les données sans risque d’erreur, et de faire le template d’affichage.

Les metas sur les horaires permettent de faire un calendrier.

Les metas permettent même aussi, via WP Query et quelques petites listes déroulantes très simplement faites avec la fonction standard de WordPress « Get Terms » de faire des formulaires de recherche en Front End.

Les sponsors seraient un article, éventuellement un custom post type, leur logo étant stocké dans l’image à la une, le niveau de sponsoring dans une taxonomie… possibilité de faire un affichage automatique très facilement.

Temps de travail estimé : de quelques heures à deux jours, tout dépend de l’importance de l’événement et de la nécessité de former /​ cadrer /​ contrôler les utilisateurs, avec un joli templating comme ici :  https://montreal.wordcamp.org/2014-fr/

Ensuite, plus besoin de former l’utilisateur non totalement technicien à Git, ni de s’inquiéter de la procédure de publication. Et si on veut, on peut mettre un cache en place !

Le modèle de données de base de WordPress permet de faire cela très simplement.

On peut même, en poussant un peu sur le templating et les archives par catégories s’offrir le luxe de faire tout cela avec uniquement les taxonomies standard (catégories et mots clés) et les types de contenus standard (articles et pages), et uniquement les champs personnalisés.

A mon avis, c’est idiot, parce que cela voudrait dire classer les types d’articles par les catégories (mauvais), et faire plus de requêtes et tests basés sur les catégories pour faire l’affichage. C’est aussi mauvais, car cela impacte la performance en front-​​end beaucoup plus que la création, lors de l’init, de types de posts et de taxonomies personnalisées.

Un Workflow de développeur, un outil de développeurs pour les développeurs

En fait, ce type d’outil, qui génère et remplace un site statique par un contenu mis à jour en back end est réservé à des développeurs.

Ce qui est un défaut pour les autres, et en particulier mes clients, est un avantage pour eux. Parce qu’ils font du développement, des commit toute la journée, utiliser le même outil pour la documentation, un wiki ou leur propre blog est un gain de temps et de productivité.

Je comprends aussi très bien que, lorsqu’on ne veut rien de plus qu’un blog extrêmement simple, sans aucune fioriture stylistique, où on publie 25 articles en deux ans, grosso modo un par mois, un CMS dynamique, qu’il s’agisse d’un WordPress, d’un Dotclear ou d’un CMS Made Simple, semble trop lourd.

Mais cela reste des exceptions.

Pour tous les autres, un site dynamique est, sur le moyen terme, nettement préférable à un site statique.

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire