Expérience de générateur de site statique Hugo

Je partage 2 ans d'expérience avec le générateur de site statique Hugo . Ce message est destiné aux débutants, mais ce message ne fournira pas d'instructions sur la façon d'installer Hugo ou sur la création d'un premier message. Ce message sera utile à ceux qui choisissent et comparent des alternatives pour les blogs.


Pourquoi générateur de site statique et Hugo


Le générateur de site statique est un programme qui traite des fichiers source structurés (textes, images, modèles) et génère un site HTML statique qui peut être téléchargé sur le serveur.


Les sources du site sont un ensemble de dossiers sur un ordinateur:


Dossier racine Hugo


Dans des sous-dossiers séparés, il y a des modèles de thèmes, des codes sources de publications, des images générales. Plusieurs fichiers bat contiennent des commandes pour des opérations typiques: enregistrement des mises à jour du blog, démarrage du serveur pour une visualisation locale, création d'une nouvelle publication à partir du modèle.


Malgré l'hostilité apparente, cette approche, contrairement au CMS, est pratique pour ceux qui ont des connaissances en HTML, CSS et autres technologies Web, mais qui souhaitent que le blog reste techniquement primitif.


Subjectivement, l'édition de scripts de base sur 5 à 10 lignes est plus facile que de creuser dans le code source de certaines pages CMS. De plus, vous n'avez pas besoin de configurer l'environnement sur le serveur, de gérer les problèmes de sécurité de la base de données et de l'installation.


Les limites des sites statiques sont qu'il n'y a aucun moyen d'utiliser des fonctions liées aux utilisateurs. Par exemple, vous devez utiliser un système de commentaires tiers. Pour un blog, de telles restrictions ne sont pas critiques.


Pour les sites statiques, il est facile de trouver et de configurer l'hébergement


L'hébergement statique, alors que le site n'a pas de volumes de trafic, comme celui de Google, est configuré plus facilement que pour les sites dynamiques, et dans de nombreux cas, il est gratuit.


Je garde le code source et le blog lui-même sur GitLab. Voici comment cela fonctionne:


  1. Le référentiel git privé de GitLab contient le code source du blog.
  2. Lors de la mise à jour du référentiel, GitLab CI démarre indépendamment la génération d'une nouvelle version du site et la place sur les pages GitLab.

Schéma de fonctionnement:


Schéma


À la fin de la pile, Cloudflare est utilisé pour organiser un certificat SSL pour la version https du blog.


La mise à jour du site pour ne pas modifier la disponibilité en ligne de la nouvelle version du blog dans la configuration Hugo-GitLab prend 0,5 à 1 minute. La plupart du temps, Gitlab CI passe à préparer la construction du site. La génération directe d'un site prend 1 à 2 secondes. Les autres générateurs de site auront un taux de rafraîchissement différent. Par exemple, avec un autre générateur de site Jekyll populaire, la création de pages pour une nouvelle version d'un site peut être plusieurs fois plus lente .


Les sources et l'hébergement peuvent être divisés - générer des pages de site sur l'ordinateur local et télécharger uniquement les fichiers HTML résultants sur l'hébergement. Pour la statique, il existe des services d'hébergement pratiques, par exemple Netlify. GitHub Pages a précédemment travaillé sur ce principe. Il y a quelque temps, GitHub a introduit des outils d'automatisation CI, comme GitLab.


Pas besoin de penser au support santé du blog


Si une fois sans erreur, j'ai téléchargé le site fini sur le serveur et que vous ne changez rien, les efforts pour maintenir le site sont minimisés. Vous ne devez payer le domaine qu'une fois par an. Il n'est pas nécessaire de penser à la sécurité (par exemple, mettre à jour le CMS et les plugins), payer mensuellement pour l'hébergement, vous ne pouvez pas avoir peur des mises à jour automatiques.


Le contrôle total de la source est maintenu


Chaque article est un dossier séparé avec du texte Markdown et des fichiers d'image immédiatement allongés.


Les postes ainsi préparés, en théorie, sont facilement transférables sur d'autres plateformes. En pratique, il est difficile de juger cela, car il est difficile de trouver des cas sur Internet.


Voici à quoi ressemble le dossier de données pour 1 article de blog:


Dossier de publication


Et cela modifie le message lui-même dans Sublime Text et la page de sortie:


Modification d'un article dans Sublime Text


Si vous ajoutez le code source au système de contrôle de version, vous pouvez voir l'historique des modifications dans le blog. La capture d'écran ci-dessous montre un examen de l'historique des modifications de mai 2018 dans Sublime Merge:


Modifications de fusion sublime


Hugo a été choisi parmi différents générateurs en raison de sa popularité, sa rapidité et sa facilité d'installation


Hugo est dans le top 3 des générateurs de sites les plus populaires sur Internet par le nombre d'étoiles sur GitHub.


Le programme lui-même est un fichier 1 exe. Le démarrage du générateur ne nécessite pas d'installation, mais pour l'appeler avec la commande hugo, vous devez enregistrer le chemin d'accès à celui-ci dans la variable système PATH.


J'ai déjà écrit sur la vitesse de travail ci-dessus - Hugo est beaucoup plus rapide que de nombreux autres générateurs, ce qui devient important à mesure que le volume du site augmente.


Difficultés rencontrées


Vous avez besoin d'au moins un peu de compréhension de la programmation ou des scripts


HUGO et les autres générateurs n'ont pas d'interface utilisateur familière. Le démarrage d'une mise à jour de site se fait via un ensemble de commandes ou un seul fichier bat.


"Interface":


Capture d'écran du déploiement lancé


Si vous chargez un site via GitLab CI, vous devez être en mesure de modifier légèrement le fichier de configuration CI.


GitLab propose un certain nombre de fichiers prêts à l'emploi pour différents générateurs, qui peuvent être pris comme base:


Modèles Gitlab


Mais encore faut-il plonger dans la config pour réparer quelque chose. Par exemple, dans la configuration standard (dans la capture d'écran ci-dessous), je recommande au moins de changer la version de Hugo (j'analyserai les raisons plus tard):


Configuration standard des pages GitLab pour Hugo


Vous devez éditer manuellement le thème sélectionné pour vous-même, vous avez besoin de connaissances en HTML


La communauté russophone de Hugo n'est pas trop grande, il y a donc très peu de solutions toutes faites qui prennent en compte les spécificités du public russe. Il n'y a pas de thèmes en russe, les boutons sociaux sont adaptés aux réseaux étrangers, les thèmes sont axés sur l'utilisation des commentaires Disqus uniquement, etc. J'ai dû réécrire indépendamment les inscriptions du système en russe et mettre en place des ensembles de boutons sociaux avec des réseaux qui sont populaires parmi le public russophone.


Même si vous n'êtes pas un développeur front-end, bienvenue dans le monde des modèles HTML avec des insertions sur Go:


Modification du sujet


Dans Hugo, jusqu'à récemment, les plugins n'existaient pas. Toutes les modifications doivent être effectuées dans le code source du sujet. Par exemple, si vous devez corriger du texte dans le pied de page d'une page, vous devez modifier le modèle de thème HTML.


Si le thème doit être mis à jour, vous devez transférer manuellement vos modifications entre les versions du thème. Dans le cas où vous avez besoin d'un transfert complet, vous devez conserver un journal de texte avec une description de toutes les modifications dans le sujet d'origine.


Dans la capture d'écran ci-dessous ~ 1/3 de la liste des modifications:


changer la liste


Il est difficile de comprendre comment fonctionne le moteur du générateur.


Je n'ai pas essayé, mais pendant tout le temps d'utilisation, je n'ai pas pu comprendre pleinement comment fonctionne le générateur. Je ne pourrai pas créer un sujet ou une structure de blog complexe à partir de zéro.


Il n'est pas toujours possible de trouver une solution au problème


Si le problème est commun à de nombreux utilisateurs, il est rapidement réparé. Mais vous pouvez rencontrer un problème que vous seul rencontrerez.


Par exemple, après la mise à jour, GitLab a commencé à convertir les caractères non anglais des chemins de fichiers en encodage Web. Cela augmentait considérablement les chemins d'accès aux fichiers s'ils contenaient des lettres non anglaises. En raison de chemins trop longs, le processus de construction d'un site est tombé avec une erreur. Mention de ce problème particulier que je n'ai pas pu trouver. J'ai commencé un ticket sur le tracker de problème GitLab, mais il n'y a pas eu de mouvement dessus. Je suppose que le problème était lié à un bogue plus important dans GitLab CI, qui a été corrigé quelque part en un mois. Ce mois-ci, j'ai temporairement résolu mon problème grâce au transfert d'hébergement.


Le danger des mises à jour et les raisons de valider la version de Hugo


Il n'y a aucune garantie que vos paramètres, documents et le thème fini fonctionneront correctement sans modifications dans la nouvelle version de Hugo.


Par exemple, dans Hugo version 0.57.0, la page principale n'est plus correctement assemblée. Je ne pouvais pas comprendre quel était le problème: dans les bugs de la nouvelle version du générateur, dans un sujet non ouvert ou dans ma structure source. J'ai décidé de rester sur la version 0.56. Ensuite, il s'est avéré que les développeurs ont apporté des modifications de compatibilité à la configuration de l'algorithme de génération de page.


La question pertinente est de savoir s'il vaut la peine d'être mis à jour en principe, sinon d'utiliser la nouvelle fonctionnalité. En effet, le manque de mises à jour n'affecte pas la sécurité, et la compatibilité peut casser. Exemple du forum officiel de Hugo:


questions du forum officiel de Hugo


Sur GitLab CI, dans les paramètres du script, je vous recommande de corriger la version d'Hugo à utiliser.


Par défaut, j'ai utilisé le "dernier pertinent", mais à plusieurs reprises, je suis tombé sur le fait que la nouvelle version a changé des paramètres importants du rendu du site. Jusqu'au moment où le processus de construction d'un blog s'est interrompu, ou des messages inutiles sont apparus en RSS. J'ai appris cela seulement après avoir mis à jour le site sur l'hébergement ou après être entré dans RSS. Dans la capture d'écran ci-dessous, l'histoire RSS nourrie avec des entrées erronées enregistrées de manière permanente:


Histoire de Feedly


Pour résumer


Générateur de sites statiques - adapté à ceux qui sont déjà un peu familiarisés avec le front-end, veut avec une immersion limitée dans les aspects techniques obtenir un site / blog techniquement simple.


Hugo est un bon choix si la rapidité et la facilité d'installation sont une priorité.


Vous ne pouvez pas vous passer de connaissances techniques. Ici et là, vous devez vous immerger dans le HTML, le CSS et d'autres problèmes techniques. D'un autre côté, une fois configuré, un site nécessite beaucoup moins d'efforts de maintenance.

Source: https://habr.com/ru/post/fr473656/


All Articles