Seb's blog

Un site statique et pourquoi choisir Pelican.

J'ai eu un mail aujourd'hui qui m'a un peu surpris, la personne toute sympathique, me demande donc pourquoi s’embêter en 2020 avec un site statique, quelles sont les véritables raisons qui m'ont poussé vers ce genre de sites, puis pour finir pourquoi avoir changer pour être sur Pelican, pourquoi lui et pas un autre? Autre question, puis-je essayer de donner des raisons qui pousseraient un utilisateur de PluXml comme lui à tenter de migrer sur de tels sites... Entre autre, si ça prends pas trop de mon temps et que je peux le faire, voir pour pondre un tuto de comment ça marche, de l’installation à la mise en ligne.

Ça m'a surpris car oui, je pensais avoir déjà donner tout un tas de raisons pour passer de sites dynamiques à la Wordpress vers ce genre de sites statiques nouvelles générations. C'est comme ça, je pensais avoir bien saouler tout le monde avec ce genre de billets mais non, je vais donc redonner les raisons, les avantages, les défauts, de ce genre de sites. Mais je vais aussi faire une sorte de tuto, j'espère le faire dans ce billet même mais c'est pas sûr, ou du moins ça ferait publier ce billet plus tardivement.

On pourra lire les nombreux sites qui en causent:

https://regisphilibert.com/fr/note/pourquoi-hugo/

https://www.sylvaindurand.fr/static-website-with-jekyll/

https://www.ionos.fr/digitalguide/hebergement/blogs/jekyll/

https://blog.victor-hery.com/2017/07/passage-blog-statique.html

https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-184/Utiliser-Pelican-comme-moteur-de-blog

https://shadoware.org/post/migration-to-pelican

https://www.bortzmeyer.org/generateurs-web-statiques.html

https://zestedesavoir.com/tutoriels/2497/creer-un-site-web-statique-avec-pelican/presentation-de-pelican/pelican-pourquoi/

Deux superbes tutos:

https://eskimon.fr/tuto-pelican-102-pelican-comment

https://zestedesavoir.com/tutoriels/2497/creer-un-site-web-statique-avec-pelican/

Pourquoi s’embêter en 2020 avec un site statique? #

C'est alors que sont apparus les sites dynamiques : les langages de programmation exécutés côté serveur, tels que PHP, ont permis de voir apparaître les CMS, qui rendaient possible la création de sites et la modification de leur contenu directement depuis un navigateur, permettant ainsi l'émergence de sites, blogs, forums accessibles au plus grand nombre. C'est par exemple le cas de Spip, Dotclear ou WordPress. Pourtant, ces systèmes ne sont pas dénués d'inconvénients :

Depuis quelques années, les sites statiques font leur retour en grâce avec l'apparition des générateurs de sites statiques. Sur la base de simples fichiers textes, un programme génère un site composé uniquement de pages statiques qu'il suffit ensuite d'héberger. Ainsi, les problèmes de sécurité sont presque inexistants, il est possible de s'héberger sur un serveur très modeste ou au contraire d'obtenir d'excellentes performances et de supporter de très fortes montées en charge

Il y a trois points où un site statique est gagnant: la rapidité, la sécurité et la fiablité.

La rapidité: #

Comme expliqué parfaitement et simplement, lors d’une visite:

un site dynamique classique:

Site statique:

ou dit autrement:

En effet, puisque toutes les pages sont pré-générées, le serveur n’a rien d’autre à faire que de les envoyer. Aucun travail de traitement n’est effectué. Si Bob demande la page A, le serveur ne se pose pas de question et renvoie la page A.html. C’est tout. C’est rapide.

Ce qui en découle, c'est de la vitesse donc un site statique pour une même page et sur le même hébergement, sera bien plus rapide.

la sécurité: #

Il n’y a pas de base de donnée, ni de PHP, ni de scripts, ni de code d'administration car séparation de la partie publique (visible c'est le site) de celle de l'édition (qui est sur notre PC), pas d’injection SQL possible,... le site statique n'exécutant aucun code et étant constitué de simples fichiers, n'a pas de failles de sécurité. Pas besoin de mettre à jour comme on le fait avec les CMS car pas de failles possible (exemple avec SPIP ou avec Wordpress).

Un autre atout : La maintenance. Une fois votre site en ligne, rien d’autre à faire si ce n’est de le faire vivre en ajoutant de nouveaux articles / nouvelles pages de temps en temps. Pas de base de données à gérer, peu de risque de sécurité, voire même pas de serveur tout court à gérer si vous optez pour une offre d’hébergement mutualisée (nous y reviendrons).

La fiabilité: #

Contrairement à un site dynamique, le serveur ne travaille pas lors d’une visite. Il sert juste des fichiers HTML qui seront téléchargés comme de simples images. En cas de forte affluence, pas de risque de ralentissement ni de surchauffe des serveurs.

Le principal est de performance et de résistance à la charge : un site Web dépendant d'un CMS doit exécuter des milliers de lignes de PHP ou de Java à chaque requête. Cela le rend lent et, surtout, une attaque par déni de service, même modérée (par exemple avec un outil primitif comme LOIC) suffit à le rendre inutilisable. Même pas besoin d'attaque, d'ailleurs, parfois, une simple utilisation un peu intense (une mention sur Mastodon, par exemple) peut le rendre inaccessible. Un site Web dynamique doit donc être hébergé sur de grosses machines coûteuses, alors qu'un site statique peut tenir une charge bien plus élevée. Tous les serveurs HTTP savent servir des fichiers statiques très rapidement.

Un deuxième avantage est de dépendance. Le site statique ne dépend que du serveur HTTP. Au contraire, un site dynamique dépend de plusieurs logiciels supplémentaires (comme par exemple MariaDB) dont la panne peut le rendre inutilisable, souvent avec des messages d'erreur incompréhensibles.

Pas de base de donnée, pas de scripts, pas de PHP, on a juste besoin d'un serveur HTTP et rien d'autre. En fait, même pas besoin d'un serveur HTTP, il suffit d'héberger son site sur Github.

Résumons: #

Avantages: #

Défauts: #

Pourquoi pas PluXml ou tout autre CMS Flat-Files ? #

PluXml est un excellent moteur de blog sans base de donnée, il est léger, rapide, avec une interface admin simple, rapide et efficace, mais ça reste un CMS qui a sur le même serveur sa partie publique et sa partie admin... Il nécessite PHP qui apporte son lot de failles. On dit sans base de donnée mais c'est simplement faux, c'est sûr qu'il n'a pas de BDD à la MYSQL ou SQLite mais sa base est simplement la somme des fichiers XML contenue dans un dossier. Il y a une interface admin donc possibilité de cracker le site.

Je peux continuer, il n'a pas d'éditeur par défaut autre que le HTML, un truc super lisible... Les plugins d'éditeurs sont merdiques. Je suis pas là pour dégommer quoique ce soit, surtout que je tiens en haute estime ce projet, je finirai donc par juste rappeler que PluXml c'est avant tout un développeur, qu'il faut que ça soit mit à jour en amont et appliquer les dites mises-à-jour...

Pelican, pourquoi lui et pas un autre? #

logo Pelican SVG{width=15%}

Pourquoi Pelican et pas un autre ? C’est une bonne question, à laquelle j'ai une réponse possible. Les goûts et les couleurs sont dans la nature. Je vais rester le plus impartial possible... Pour en choisir un, mon cahier des charges était logiciel libre, prévu pour des blogs, avec une chronologie et disponible dans la version stable de Debian/Ubuntu et openSUSE.

Parce que python #

Python est un langage que j’aime beaucoup et qui du reste, m'attire de plus en plus, au point que je m'y mettrai bien. C’est donc évidemment vers ce langage que je me suis tourné. Python est le langage que je comprends le mieux, je ne touche pas encore mais je pense m'y investir prochainement, ce qui me permettra de faire des modifications ou des plugins au besoin.

Ruby est un langage que je trouve bien trop lent. Go est vraiment rapide, mais je le trouve assez complexe et trop récent. Quant à JavaScript, je trouve que ça prends beaucoup de ressources pour pas grand chose, en plus d'être lourdingue.

Pelican est écrit en Python (utile pour étendre les fonctions, même les fichiers de configuration et de fabrication du site sont en Python).

Parce que Pelican! #

Hugo, Jekyll, Pelican, Publii et bien d'autres, j'en ai essayé et je les ai testé sur le long terme, mais celui qui me sembla le plus simple, performant et complet, a été Pelican.

A la lecture de sa documentation, ça m’a semblé simple (comme la rédaction des métadonnées des articles). Le support du markdown a été primordiale étant très fan de ce langage de rédaction.

hugo-logo{width=80%}

Pour commencer, Hugo ne vient avec aucun thème, il faut en choisir un, de plus si on change de thème il faut aussi changer pratiquement 80% de son fichier config. Je trouve aussi que les templates sont bordéliques. Pour finir, il est vraiment complet mais si il manque des choses on ne peut rajouter de plugin dû à sa nature. De plus je trouve qu'il ne donne pas de liberté, c'est assez carré, on a les mains liées, exemple si vous prenez un thème, n'allez pas penser qu'on pourra faire n'importe quoi avec, on ne peut pas aller à l'encontre de ce que le thème à été prévu sans passer par une grosse part de modifications du thème. Un thème pensé pour faire des pages uniques, ne pourra pas faire un blog sans faire au préalable des changements dessus, si le thème n'a pas été prévu pour avoir une page archives, il faudra la créer (page, layout, ect,...). Tout est carré, ou sinon j'ai vraiment mal regardé, par exemple, il faut dater les articles d'une certaines manière (pas de 2020-01-20 18:16 ou inversement) sans quoi la date sera pas prit en charge. Toujours dans la datation, si on ne met pas de date, Hugo n'est pas assez géniale pour prendre comme date, la datation de la création du fichier. Obligé d'indiquer les pages dans le fichier de configuration pour qu'elles apparaissent dans la barre de menu, selon le thème utilisé la façon de les indiquer change ce qui est assez chiant... Il reste qu'il est le plus rapide lors de la compilation du site.

Indication de pages dans le fichier de conf d'Hugo (menu.main):

baseURL = "https://passiongnulinux.tuxfamily.org/"
languageCode = "fr"
title: "Seb's blog"
theme = "twentynineteen-hugo"

# Pagination
paginate = 10

# Output formats (for search index)
[outputs]
Home = ["HTML", "RSS", "JSON"]

# Site params
[params]
privacy_link = "/mentions-legales/" # Relative URL to privacy page, if there is one. This enables a Privacy Policy link in the footer. The link doesn't display if this isn't specified.
description = "PassionGNU/Linux, la passion du Libre..." # Adds tagline next to the site title.
accent_color = "#C70136" ##649600 pour mon vert openSUSE Set a custom accent color for links and image filters, if enabled. Defaults to blue.
disable_image_filters = true # Setting to true disables the color filter feature on images. Defaults to false.

# Menus
[menu]
[[menu.main]]
    name = "Accueil"
    url = "/"
    weight = 1
#  [[menu.main]]
#    name = "Posts"
#    weight = 2
#    identifier = "post"
#    url = "/post/"
[[menu.main]]
    name = "Tags"
    identifier = "tag"
    url = "/tags/"
    weight = 3
[[menu.main]]
    name = "Forum"
    weight = 4
    identifier = "forum"
    url = "/forum/"
[[menu.main]]
    name = "À propos"
    identifier = "about"
    url = "/about/"
    weight = 5
[[menu.main]]
    name = "Contact"
    weight = 6
    identifier = "contact"
    url = "/contact/"
[[menu.main]]
    name = "Licence"
    weight = 7
    identifier = "licence"
    url = "/licence/"
[[menu.main]]
    name = "Liens"
    weight = 8
    identifier = "liens"
    url = "/liens/"
[[menu.main]]
    name = "Mentions légales"
    weight = 9
    identifier = "mentions-legales"
    url = "/mentions-legales/"
#[[menu.main]]
    #name = "Archive-Jekyll"
    #weight = 10
    #url = "https://passiongnulinux.tuxfamily.org/jekyll/"

[[menu.social]]
    identifier = "github"
    name = "Github"
    url = "https://github.com/passionlinux"
[[menu.social]]
    identifier = "rss"
    name = "rss"
    url = "index.xml"

Publii, est un programme graphique qu'on lance sur notre machine, c'est comme si on avait une interface à la Wordpress en application JavaScript, c'est bien, c'est chouette, c'est accessible, mais pour être franc c'est du JavaScript donc c'est bien plus lourd, l'éditeur n'est pas markdown, ça plante, ça enregistre nos fichiers sources dans une base de donnée SQLite et donc on a aucun contrôle des fichiers en dehors du programme...

Lecktor

Un autre projet très intéressant en Python est celui de Lecktor qui lui aussi possède une interface graphique, tout en permettant de l'utiliser classiquement comme Pelican. Je ne l'ai pas testé, n'aimant pas la hiérarchie du dossier de travail.

Lecktor-admin{width=80%}

Jekyll, il vient avec un thème par défaut minimaliste mais suffisant et est donc opérationnel de suite sans rien faire.

jekyll-logo

thème-defaut{width=80%}

A part la nomination obligatoire à sa façon, il nous laisse la main mise sur le reste. Dans son installation de base, on n'a pas le droit à grand chose comme la pagination manquante, tout n'est que plugin, sauf que c'est moins simple de charger des plugins ou des thèmes. C'est aussi du Ruby, donc assez lent pour la compilation du site, il met facilement deux fois le temps que Pelican demande sans cache pour faire la compilation et trois à six fois ce que Pelican met comme temps avec le cache d’activé. Seul point vraiment positif, son fichier de conf qui pour produire un site demande peu de chose, une adresse, un auteur, et rien d'autre...

Voila en exemple, mon fichier entier de configuration pour mon site sous Jekyll:

# Site settings
title: Seb's blog / PassionGNU/Linux, la passion du Libre...
email: passiongnulinux/@/gmail/./com
description: Le site d'un passionné contributeur/testeur/emmerdeur du Libre et de l'OpenSource
baseurl: "/jekyll" # the subpath of your site, e.g. /blog
url: "https://passiongnulinux.tuxfamily.org/" # the base hostname & protocol for your site
twitter_username:
github_username: Passionlinux

# Build settings
markdown: kramdown

#plugins:
#  - jekyll-feed

Autre bon point, on créé une page, on l'enregistre à la racine de notre dossier /mon_site et la page sera visible dans le menu, pas besoin de remplir un fichier pour les annoncer, comme sur la capture qui suit, les pages about.md, contact.md, forum.md, licence.md, liens.md, mentions-legales.md, tuto.md sont à la racine de mon dossier Jekyll et seront prises en considération dès la prochaine compilation.

mon_site et les pages

logo-pelican.png{width=50%}

Pelican est facile à personnaliser et il est simple d'avoir le rendu voulu. Tout n'est que paramètre dans notre fichier de conf, que ce soit les URL, les tags, les pages, les archives, la façon d'enregistrer notre site (sa hiérarchie),... Tout se contrôle depuis ce simple fichier. Il a un système de cache qui évite de recompiler tout les fichiers à chaque build donc gain de temps vis-à-vis d'autres GSS...

Il vient de base avec deux thèmes très simples, notmyidea et simple, le premier qu'on peut voir sur le site du projet et le second comme son nom l'indique est un minimaliste sans CSS. Il est comme Jekyll, de suite opérationnel, pas besoin d'aller chercher un thème pour commencer contrairement à Hugo.

Je trouve qu'a part sa configuration très complète, c'est le plus simple à prendre en main, il vient avec au minimum un thème (en faite deux mais bon) donc pas besoin d'en chercher un, les pages sont comme avec Jekyll, c'est-à-dire qu'on les met dans un dossier /page et pas besoin de les annoncer dans le fichier de conf (contrairement à Hugo), sa config de base est simpliste mais fonctionnelle...

Voila, je sais pas si j'ai répondu en partie ou totalement à la demande qui m'a été faite mais je vois pas ou peu ce que je peux dire de plus. Prochainement je ferai un tuto sur comment installer Pelican (ou Hugo ou bien Jekyll), son utilisation et ma config.

Commencer la discussion: Venez écrire un commentaire dans le forum