… dans sa catégorie ! :)
En fait, un assemblage de quelques scripts shell et Web (un script Web c’est du JavaScript, non ?), qui permet de gérer des sites Web statiques.
Un nain posé sur les épaules de géants : Apache httpd, hugo (mais cela serait modifiable), cron et incron, git, tinymce et ace.
Une plate‐forme pour générer des sites et un éditeur Web minimaliste pour les modifier, afin de permettre à des non‑techniciens d’interagir avec des outils qui leur sont généralement inaccessibles.
Il y avait du HTML, du CSS et du JavaScript, un assemblage de trois langages disparates, mais qui permettent :
Leur mise en place peut cependant se révéler compliquée, surtout parce que les pages d’un site Web comportent souvent des éléments communs ou répétitifs. Un en‑tête, un menu ou pied de page, par exemple. Il peut aussi y avoir des problématiques de traduction, si une même page existe en plusieurs langues.
Dans ce contexte, un générateur de site Web statique devient presque indispensable. Avec lui, on automatise les tâches qui permettent la mise en place du fond, de la forme et des comportements, ces fameux HTML, CSS et JavaScript. Cela fonctionne assez bien pour les techniciens, ceux qui vont directement éditer leur site Web avec vim ou emacs, par exemple, puis lancent manuellement la génération et le déploiement. Le générateur statique peut tourner en fond, en attendant un changement quelconque dans un des fichiers source. Et avec livereload le navigateur va même tout de suite afficher les changements !
Dans simpleWeb l’édition se fait avec l’éditeur WYSIWYG nommé tinymce, et aussi avec ace qui, lui, est plus orienté code. Le choix se fait en fonction du type de fichier édité.
incron détecte cette édition et lance le générateur statique en tâche de fond pendant trente minutes. Cela permet une génération presque instantanée tout en conservant la mémoire système en évitant qu’un générateur soit continuellement en fonctionnement pour chaque site Web.
La sauvegarde git se déclenche après chaque édition.
Il y a plusieurs « tours » (au sens étapes ou pas). En effet, comment modifier un site statique à l’aide d’un éditeur Web statique. Sans base de données, ni serveur applicatif ?!
Avec le module webdav d’Apache httpd !
C’est une extension du HTTP, qui permet d’interagir avec les fichiers d’un serveur (lire, créer, modifier, supprimer…). Le client peut être n’importe quel navigateur Web qui sait utiliser les verbes HTTP appropriés, à l’aide de JQuery (cela pourrait fonctionner avec d’autres bibliothèques JavaScript, bien sûr).
Un deuxième tour repose sur incron, qui surveille les fichiers journaux du serveur Web Apache. Ces journaux sont rattachés à chaque site Web, et sont configurés afin que les verbes HTTP de consultation et les verbes de modification aboutissent à des fichiers séparés. incron peut ensuite surveiller ces fichiers et lancer le générateur statique et la synchronisation Git. cron va ensuite arrêter le générateur au bout d’un certain temps d’inactivité (à l’aide d’un fichier contenant l’identifiant du processus correspondant).
Un troisième tour dépend d’Apache, qui permet facilement de modifier la page listant un répertoire. C’est ainsi que l’on peut y injecter un script qui organise la page et permet l’édition.
C’est un petit projet, mais il est utilisé sur des sites comportant des milliers de pages. Dans ce contexte, le lancement du générateur hugo (il a été choisi car c’est actuellement le plus rapide) prend une minute. Une fois lancé, il reflète une modification presque instantanément.
Les utilisateurs n’ont accès qu’au contenu « pur », c’est‐à‐dire l’un des sous‐répertoires nommé content, et pas les squelettes de pages ou la mise en forme.
L’édition des méta‐données disponibles en Markdown, sous la forme de clés‐valeurs dans un en‑tête YAML ou TOML, reste spartiate, et sera probablement améliorée dans le futur. Une remontée des erreurs possibles du générateur est aussi en place dans l’éditeur, mais reste cryptique, car ces erreurs sont souvent plutôt techniques et cryptiques. :) Il y a du travail à faire de ce côté‑là !
Cet éditeur statique est en fait généré avec un autre outil : middleman, qui n’est plus guère maintenu mais permet facilement d’écrire en utilisant les syntaxes alternatives : Haml, Sass et CoffeeScript. Il faudra sûrement revoir cela à un moment donné. Peut‑être tester un générateur statique fait en Rust (donc plus rapide ?), ou assembler un générateur en utilisant incron et d’autres outils système.
En théorie, on peut éditer l’éditeur avec l’éditeur, si si !!!
Le générateur hugo est vraiment très bien, et il a été utilisé comme base pour les scripts existants. Il faudrait faire un gros travail pour le rendre interchangeable aisément, surtout parce que les arborescences de fichiers ne sont pas les mêmes d’un générateur à un autre…
Eh oui, un éditeur de site Web se doit de limiter les accès à seulement ceux qui y sont autorisés. Pour cela, inutile de réinventer la roue, Apache httpd sait très bien gérer ce genre de choses, par exemple avec :
Autant de mécanismes déjà mis en place pour certains sites.
Le code source d’un projet GitLab peut déclencher une synchronisation Git et une régénération du site à chaque push. Là encore, avec les journaux d’Apache et incron, en surveillant une adresse HTTP prédéfinie, que l’on configure dans GitLab.
Cela offre un grand confort au technicien qui veut éditer et tester un site sur son propre ordinateur, avant de le pousser sur un autre environnement. En théorie, il serait ainsi possible de multiplier à l’infini les environnements d’édition : développement, recette, préproduction, production, etc., tout en gardant un historique plutôt fin (mais l’historique ne reflète pas les auteurs, c’est une limite technique qui cherche encore sa solution).
Bref, c’est un assemblage que l’on pourrait qualifier de bricolage système, mais basé sur des concepts et des outils tellement simples et efficaces, que je voulais vous en parler ! :)
Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 19/04/20 à 23:06.
Quand je fais une page web ou quand je la modifie, je la teste toujours avec https://validator.w3.org/ fourni par le W3C, l’organisme de standardisation du web.
Alors, je l’ai fait sur les pages proposées. Le résultat n’est pas bon, je dirais même plutôt mauvais.
Quand je vois des sites faits avec WordPress, c’est pareil sauf que c’est plus lourd.
Je viens de tester https://linuxfr.org et c’est loin d’être parfait.
Alors, est-ce inéluctable de ne faire que du code pourri avec des générateurs de code ? Je me le demande.
Pourtant https://abul.org/ fait avec le vénérable SPIP est valide !
Posté par  . Évalué à 2.
Et à part https://abul.org/, il y a d’autres exemples ?
Parce que là, je viens de tester une série de sites qui étaient dans mon historique de navigation et … la plupart ont plein de warning, error voir fatal error. Ce sont des sites qui pourtant ont l’air de bien vivre.
Surtout, ne pas tout prendre au sérieux !
Posté par  (site Web personnel) . Évalué à 7. Dernière modification le 20/04/20 à 12:15.
Parce que là, je viens de tester une série de sites qui étaient dans mon historique de navigation et … la plupart ont plein de warning, error voir fatal error. Ce sont des sites qui pourtant ont l’air de bien vivre.
Si ça marche, c’est bon… C’est un raisonnement qui ne peut être généralisé.
Beaucoup testent leur site sur plusieurs navigateurs et en sont satisfaits.
Pour ma part je fais du code valide et c’est tout, quand c’est valide, c’est bon partout.
Les navigateurs seraient plus légers si ils n’incluaient pas des algorithmes de gestion des erreurs. Maintenant, ceux qui créent des sites web comptent sur la présence de ces algorithmes pour cacher leur code pourri et en venir à bout.
Il fut une époque où un navigateur indiquait si la page était valide ou codée avec les pieds. J’ai l’impression que les pages valides sont l’exception, malheureusement.
L’usage du “validator” n’est pas souvent connu de ceux qui devraient l’utiliser ou même l’enseigner.
On peut faire le parallèle entre les fautes de grammaire en HTML et les fautes de grammaire en français que journalistes font de plus en plus souvent. Est-ce inéluctable ?
Posté par  (site Web personnel) . Évalué à 5.
J’ai bossé quelques années en agence Web…
Jamais je n’y ai vu qui que ce soit contrôler la validité du code mis en ligne. Par contre, c’est dingue ce qu’on contrôle son “score SEO” (a.k.a. ses chances de bien se placer dans les résultats de moteurs de recherche).
Posté par  (site Web personnel) . Évalué à 3.
Il y a quelques années, j’ai fait passé des entretiens d’embauche pour un CDI concernant (entre autre) du développement web, et je me suis amusé à passer le validateur sur les sites fournis dans les CV. J’ai été assez surpris des résultats, et au final, un de mes critères discriminant d’embauche a été la validité du code présenté.
Posté par  (site Web personnel) . Évalué à 10.
Beaucoup testent leur site sur plusieurs navigateurs et en sont satisfaits.
Pour ma part je fais du code valide et c’est tout, quand c’est valide, c’est bon partout.
Faire du code valide, c’est bien. Mais ça ne dispense nullement de tester sur plusieurs navigateurs, et avec des résolutions différentes. Le site de l’ABUL sur un petit écran, j’aurais quand même beaucoup de mal à dire que « c’est bon » :
Le site de l'ABUL sur un petit écran, avec des images qui chevauchent le texte
Il faut également voir que la validation HTML n’est qu’un axe parmi tant d’autres. La validateur CSS se plaint de la feuille de style du site de l’ABUL. D’un point de vue accessibilité, je suis loin d’être un spécialiste mais le texte en vert clair sur fond blanc me paraît manquer très fortement de contraste. D’un point de vue admin sys, on peut regretter que HSTS ne soit pas mis en place. Pour la sécurité, la limite arbitraire à 15 caractères sur le champ de mot de passe est une très mauvaise pratique. Les images pourraient être plus légères en appliquant des outils tels que optipng (sans perte de qualité). Le temps de chargement pourrait être amélioré en déplaçant les balises script ailleurs que dans le <head>. Etc.
D’autre part, la validation HTML est plus compliquée depuis HTML5. C’est une spécification mouvante, avec un validateur marqué expérimental. Certaines erreurs remontées par le validateur pour le site LinuxFr.org correspondent à du code présent depuis longtemps que le validateur n’indiquait pas en erreur à l’époque.
Posté par  (site Web personnel) . Évalué à 2.
Tu as raison, Bruno. Si j’ai parlé du vénérable SPIP, c’est parce que le site a été fait il y a longtemps, au début des années 2000. À cette époque on ne parlait pas de “responsive-design” et les téléphones n’étaient pas encore des smartphones.
Mais en ce temps là, on savait faire du html correct.
Pour tout avouer, le site est de l’ABUL est en train d’être refait.
Posté par  (site Web personnel) . Évalué à 1.
Il suffit parfois de pas grand chose pour avoir du responsive design et c’est tout a fait faisable avec SPIP !
Il me semble avoir un résultat correct sur mon site perso !
Posté par  (site Web personnel) . Évalué à 2.
Il suffit parfois de pas grand chose pour avoir du responsive design
Il suffit même de ne rien faire qui casse le comportement responsive par défaut !
Adhérer à l'April, ça vous tente ?
Posté par  . Évalué à 0.
Ce qui est complexe pour la mise en place effective de ces différentes validations… c’est qu’il est difficile d’automatiser facilement ces vérification… il faudrait des outils en ligne de commande (et non dépendants de ressources web externes) pour intégrer ça en CI ou dans les tests hors CI.
Je passe toujours mon code par un maximum de linter (éventuellement en désactivant/activant certain warning) pour quasiment tous les langages : python (flake8, pylint), rust (clippy), javascript (jslint), etc… même le JSON, le TOML, le YAML et le Markdown ont de très bon validateurs… mais pour le HTML5, à part aller le valider en ligne je ne trouve pas d’outil digne de ce nom (ou qui ne se contente pas d’aller intéroger un site pour nous retourner la réponse…) bien configurable et tout pour faire la même chose avec le HTML que j’écris ou que je génère.
Et comme le dit Bruno, la propreté du code ne fait pas tout : le poids des image et les temps de chargement jouent aussi… et des outils de détection des erreurs typiques serait vraiment top.
Posté par  (site Web personnel) . Évalué à 4.
Pour les outils pour valider du HTML5 :
Posté par  (site Web personnel) . Évalué à 5.
Y a même un type qui ne doute rien qui essaie de valider les pages de LinuxFr.org dans une dépêche encore en rédaction…
Posté par  (site Web personnel) . Évalué à 2.
Y a même un type qui ne doute rien qui essaie de valider les pages de LinuxFr.org
Vous avez retrouvé Pierre Tramo ?
Posté par  . Évalué à 3.
[…]il faudrait des outils en ligne de commande (et non dépendants de ressources web externes) pour intégrer ça en CI ou dans les tests hors CI.
Ça c’est simple, mais ce n’est pas suffisant. Comment tu énumère les pages ? Quand tu ne fais pas de sites statiques ton code ne représente que des templates. Il faut les exécuter. Les paramètres de ces templates peut casser la validation (exemple ici sur linuxfr, si tu ne met pas de texte alternatif aux images).
Je passe toujours mon code par un maximum de linter[…]Il faut aussi garder en tête que l’analyse statique de code est un outil limité. Il possède des biais, génère des faux positifs et faux négatifs. Il n’est pas forcément complet. Ce n’est pas une fin en soit. Se concentrer sur des métriques comme cela peut facilement amener à des abus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par  (site Web personnel) . Évalué à 3.
Tu as raison, je devrais aussi valider à chaque modification, mais je n’y arrive pas 🙁
Notons qu’il est probablement plus utile de valider l’accessibilité, non?
Posté par  (site Web personnel) . Évalué à 6.
Un site valide est la première marche vers l’accessibilité. Quand un site est valide, l’accessibilité suit sans trop d’efforts. Or il est plus facile de tester la validité que l’accessibilité.
Pour s’en convaincre, on peut aller faire un tour sur https://opquast.com en particulier sur https://checklists.opquast.com/fr/
Posté par  (site Web personnel) . Évalué à 4.
Ce que je connais de meilleur, et que j’ai utilisé dans le passé pour rendre accessible le site d’un ministère: WebAIM
Il y en a d’autres je suis sûr, vous utilisez quoi de votre côté?
Posté par  (site Web personnel) . Évalué à 4.
Oui, c’est bien, les points à vérifier des checklist d’OpQuast sont un bon début !
Le WCAG est la référence pour l’accessibilité. C’est là que l’on s’aperçoit qu’un daltonien, un aveugle, un sourd et un handicapé moteur sont des cas difficiles à traiter ensemble.
L’accès avec Lynx permet très vite de voir ce qui reste d’un site quand on a enlevé ses décorations. C’est le premier test que je fais pour avoir une idée de ce qu’un aveugle peut “voir” dans la page.
Faire un bon site web n’est vraiment pas simple. C’est comme la cuisine gastronomique, c’est plus compliqué à faire que la malbouffe.
Posté par  (site Web personnel) . Évalué à 4.
L’accès avec Lynx permet très vite de voir ce qui reste d’un site quand on a enlevé ses décorations. C’est le premier test que je fais pour avoir une idée de ce qu’un aveugle peut “voir” dans la page.
Pareil pour moi, mais en plus, j’utilise aussi le vénérable Dillo qui donne souvent une bonne idée des éventuels dégats.
Posté par  . Évalué à 1.
Sympa Fils du Net.
Le projet simpleWeb sans doute aussi mais là, il est trop tard pour que j’y réfléchisse.
Surtout, ne pas tout prendre au sérieux !
Posté par  . Évalué à 1. Dernière modification le 21/04/20 à 08:00.
Cela ressemble pas mal à Pico CMS, statique et exploitant Markdown.
Posté par  (site Web personnel) . Évalué à 3.
A priori, pico est un générateur dynamique de site web, mais basé sur des contenus sous forme de fichiers statiques non?
Ce qui conserverait une certaine complexité sur le serveur, et ne permet pas une édition simple à distance.
Au moins, pas de base de données 🙂
Posté par  . Évalué à 1.
Oui et non, a priori il y a une app pour Nextcloud, qui permet aux utilisateurs de créer leur site avec leurs propres fichiers de leur compte-même dudit Nextcloud (et l’éditeur Markdown intégré à Nextcloud).
Après je n’ai pas trop compris la spécificité de simpleWeb : c’est aussi du contenu statique géré avec des scripts non ?
Posté par  (site Web personnel) . Évalué à 3.
L’idée c’est de gérer le générateur de site, et de permettre l’édition à distance.
Cela devrait être plus clair si tu regardes le bac à sable.
C’est spécifique car je ne connais nulle part ce type d’édition “brut” par le web…
(il y a heureusement plein d’autres moyens d’éditer un site statique, avec gitlab par exemple)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.
Revenir en haut de page

source

Catégorisé:

seo on page

Étiqueté dans :