Passer de WordPress à Hugo

Lorsque WordPress 5 est sorti, j'étais enthousiaste à l'idée d'utiliser l'éditeur Gutenberg pour créer des blocs personnalisés, car les articles de mon blog personnel comportaient quelques fonctionnalités que je pouvais transformer en bloc, ce qui facilitait la configuration de mon contenu. C'était définitivement une chose cool à avoir, mais c'était quand même assez gonflé.

À peu près à la même époque, j'ai commencé à lire de plus en plus sur les générateurs de sites statiques et le JAMstack (cet article de Chris Ferdinandi m'a convaincu). Avec les projets parallèles personnels, vous pouvez en quelque sorte écarter une grande variété de problèmes, mais en tant que professionnel, vous devez vous assurer de produire la meilleure qualité possible. La performance, la sécurité et l'accessibilité deviennent les premières choses auxquelles il faut penser. Vous pouvez certainement optimiser WordPress pour qu'il soit assez rapide, mais plus rapide qu'un site statique sur un CDN qui n'a pas besoin d'interroger la base de données ni de générer votre page à chaque fois ? Pas si facile.

J'ai pensé que je pourrais mettre cela en pratique avec un de mes projets personnels pour apprendre et ensuite pouvoir l'utiliser pour des projets professionnels, et peut-être que certains d'entre vous aimeraient aussi savoir comment. Dans cet article, je vais expliquer comment j'ai effectué la transition de WordPress vers un générateur de site statique spécifique nommé Hugo.

Hugo est construit en Go, qui est un langage assez rapide et facile à utiliser une fois que vous vous êtes habitué à la syntaxe, que je vais vous expliquer. Tout se compile localement afin que vous puissiez prévisualiser votre site directement sur votre ordinateur. Le projet sera ensuite enregistré dans un référentiel privé. De plus, je vous expliquerai comment l'héberger sur Netlify et enregistrer vos images sur un Git LFS (Large File Storage). Enfin, nous verrons comment mettre en place un système de gestion de contenu pour ajouter des publications et des images (similaire au backend WordPress) avec Netlify CMS.

Notez que tout cela est absolument gratuit, ce qui est assez étonnant si vous me le demandez (bien que vous deviez payer un supplément si vous utilisez tout votre stockage LFS ou si le trafic de votre site est intense). De plus, j'écris ceci du point de vue d'un utilisateur Bitbucket, fonctionnant sur un Mac. Certaines étapes peuvent être légèrement différentes, mais vous devriez pouvoir suivre, quelle que soit la configuration que vous utilisez.

Vous devrez être un peu à l'aise avec HTML, CSS, JS, Git et le terminal de commande. Avoir quelques notions avec des langages de modèles tels que Liquid pourrait également être utile, mais nous passerons en revue les modèles d'Hugo pour vous aider à démarrer. Je vais quand même donner le plus de détails possible !

Je sais que cela semble beaucoup, et avant que je commence à me pencher là-dessus, c'était pour moi aussi. Je vais essayer de rendre cette transition aussi douce que possible pour vous en décomposant les étapes. Il n'est pas très difficile de trouver toutes les ressources, mais il y a eu un peu de conjecture de ma part, passant d'une documentation à l'autre.

1. Exporter le contenu de WordPress
2. Préparer la conception de votre blog
3. Configurer un nouveau référentiel
4. Activation de Git LFS (facultatif)
5. Création du site sur Netlify
6. Préparation pour Netlify Large Media (facultatif)
7. Configurer Hugo sur votre ordinateur
8. Création de votre thème personnalisé
9. Notes sur la syntaxe Hugo
10. Contenu et données
11. Déploiement sur Netlify
12. Configurer un domaine personnalisé
13. Modification du contenu sur Netlify CMS

Remarque : Si vous rencontrez des problèmes avec certains d'entre eux, veuillez me le faire savoir dans les commentaires et j'essaierai de vous aider, mais veuillez noter que cela est destiné à être appliqué à un blog simple et statique qui n'a pas une douzaine de widgets ou commentaires (vous pouvez le configurer plus tard), et non un site d'entreprise ou un portfolio personnel. Vous pourriez sans aucun doute, cependant, mais par souci de simplicité, je vais m'en tenir à un blog simple et statique.

Conditions préalables

Avant de faire quoi que ce soit, créons un dossier de projet où tout, de nos outils à notre référentiel local, va résider. Je l'appellerai "WP2Hugo" (n'hésitez pas à l'appeler comme vous voulez).

Ce didacticiel utilisera quelques outils de ligne de commande tels que npm et Git. Si vous ne les avez pas déjà, installez-les sur votre machine :

• Installer Git
• Installez Node.js et npm (Node.js inclut npm)
• Installez Homebrew (recommandé pour les utilisateurs de macOS/Linux)

Avec ceux-ci installés, commençons!

1. Exporter le contenu de WordPress

Tout d'abord, nous devrons exporter votre contenu depuis WordPress : publications, pages et téléchargements. Il existe quelques outils disponibles que Hugo mentionne mais personnellement, un seul d'entre eux a fonctionné : blog2md. Celui-ci fonctionne en exécutant un fichier JavaScript avec Node.js dans votre terminal de commande. Il prend les fichiers XML exportés par WordPress et produit des fichiers Markdown avec la bonne structure, convertissant votre HTML en Markdown et ajoutant ce qu'on appelle le Front Matter, qui est un moyen de formater les métadonnées au début de chaque fichier.

Accédez à votre administrateur WordPress et ouvrez le menu Outils, sous-menu Exporter. Vous pouvez exporter ce que vous voulez à partir de là. Je ferai référence au fichier exporté en tant que YOUR-WP-EXPORT.xml .

Vous pouvez sélectionner exactement les données que vous souhaitez exporter depuis votre blog WordPress.

Dans notre dossier WP2Hugo, je vous recommande de créer un nouveau dossier nommé blog2md dans lequel vous placerez les fichiers de l'outil blog2md, ainsi que votre export XML depuis WordPress ( YOUR-WP-EXPORT.xml ). Créez également un nouveau dossier là-dedans out où iront vos publications Markdown. Ensuite, ouvrez votre terminal de commande et naviguez avec la commande cd vers votre dossier "blog2md" nouvellement créé (ou tapez cd avec un espace et faites glisser le dossier dans le terminal).

Vous pouvez maintenant exécuter les commandes suivantes pour obtenir vos publications :

 npm install node index.js w YOUR-WP-EXPORT.xml out

Regardez dans le /WP2Hugo/blog2md/out pour vérifier si tous vos messages (et pages potentielles) s'y trouvent. Si c'est le cas, vous remarquerez peut-être qu'il y a quelque chose à propos des commentaires dans la documentation : j'avais un blog sans commentaires, donc je n'avais pas besoin qu'ils soient exécutés, mais Hugo propose plusieurs options pour les commentaires. Si vous aviez des commentaires sur WordPress, vous pouvez les exporter pour une réimplémentation ultérieure avec un service spécialisé comme Disqus.

Si vous êtes suffisamment familiarisé avec JS, vous pouvez modifier le fichier index.js pour modifier la façon dont vos fichiers de publication seront publiés en modifiant la fonction wordpressImport . Vous voudrez peut-être capturer l'image sélectionnée, supprimer le lien permanent, modifier le format de la date ou définir le type (si vous avez des articles et des pages). Vous devrez l'adapter à vos besoins, mais sachez que la boucle ( posts.forEach(function(post){ ... }) ) parcourt tous les messages de l'exportation, vous pouvez donc vérifier le contenu XML de chaque publication dans cette boucle et personnalisez votre Front Matter.

De plus, si vous avez besoin de mettre à jour les URL contenues dans vos messages (dans mon cas, je voulais rendre les liens d'image relatifs plutôt qu'absolus) ou le formatage de la date, c'est le bon moment pour le faire, mais ne perdez pas le sommeil. . De nombreux éditeurs de texte proposent une édition en masse afin que vous puissiez insérer une expression régulière et apporter les modifications souhaitées dans vos fichiers. De plus, vous pouvez exécuter le script blog2md autant de fois que nécessaire, car il écrasera tous les fichiers précédemment existants dans le dossier de sortie.

Une fois que vous avez vos fichiers Markdown exportés, votre contenu est prêt. La prochaine étape consiste à préparer votre thème WordPress à fonctionner dans Hugo.

2. Préparer la conception de votre blog

Mon blog avait une mise en page typique avec un en-tête, une barre de navigation, un contenu et une barre latérale, et un pied de page - assez simple à configurer. Au lieu de copier des morceaux de mon thème WordPress, j'ai tout reconstruit à partir de zéro pour m'assurer qu'il n'y avait pas de styles superflus ou de balisage inutile. C'est le bon moment pour implémenter de nouvelles techniques CSS ( pssst… Grid est assez génial ! ) et mettre en place une stratégie de nommage plus cohérente (quelque chose comme les directives de CSS Wizardry). Vous pouvez faire ce que vous voulez, mais rappelez-vous que nous essayons d'optimiser notre blog, il est donc bon de revoir ce que vous aviez et de décider si cela vaut toujours la peine d'être conservé.

Commencez par décomposer votre blog en plusieurs parties afin de voir clairement ce qui va où. Cela vous aidera à structurer votre balisage et vos styles. Soit dit en passant, Hugo a la capacité intégrée de compiler Sass en CSS, alors n'hésitez pas à diviser ces styles en fichiers plus petits autant que vous le souhaitez !

Quand je dis simple, je veux dire vraiment simple.

Alternativement, vous pouvez complètement contourner cette étape pour le moment et styliser votre blog au fur et à mesure que votre site Hugo est configuré. J'avais mis en place le balisage de base et préféré une approche itérative des styles. C'est aussi un bon moyen de voir ce qui fonctionne et ce qui ne fonctionne pas.

3. Configurer un nouveau référentiel

Maintenant que c'est réglé, nous devons mettre en place un référentiel. Je vais supposer que vous voudrez créer un nouveau référentiel pour cela, ce qui sera une excellente occasion d'utiliser Git LFS (Large File System). La raison pour laquelle je conseille de le faire maintenant est que l'implémentation de Git LFS lorsque vous avez déjà des centaines d'images n'est pas aussi fluide. Je l'ai fait, mais c'était un mal de tête que vous voudriez probablement éviter. Cela offrira également d'autres avantages sur la route avec Netlify.

Bien que je fasse tout cela via Bitbucket et leur interface graphique propriétaire Git, Sourcetree, vous pouvez absolument le faire avec GitHub et GitLab et leurs propres outils de bureau. Vous pouvez également le faire directement dans le terminal de commande, mais j'aime automatiser et simplifier le processus autant que possible, réduisant ainsi le risque de faire des erreurs stupides.

Lorsque vous avez créé votre nouveau référentiel sur la plate-forme Git de votre choix, créez un dossier vide dans votre dossier de projet local (WP2Hugo), par exemple hugorepo , puis ouvrez votre terminal de commande ou votre outil Git GUI et initialisez votre référentiel Git local ; puis, liez-le au référentiel distant (vous pouvez généralement trouver la commande exacte à utiliser sur le référentiel distant nouvellement créé).

Je vous recommande de créer une branche dev (ou stage ) afin que votre branche principale soit strictement utilisée pour les déploiements de production. Cela limitera également la génération de nouvelles versions uniquement lorsque vous en aurez terminé avec une série potentielle de modifications. La création d'une branche peut être effectuée localement ou sur la page Web distante de votre référentiel.

GitHub facilite la création d'une branche en cliquant sur le sélecteur de branche et en saisissant un nouveau nom. Sur GitLab, vous devez ouvrir le menu déroulant "Plus" pour accéder à l'option. Bitbucket vous demande d'ouvrir le menu "Plus" sur la gauche pour ouvrir le menu coulissant et de cliquer sur "Créer une branche" dans la section "Se mettre au travail".

4. Activation de Git LFS (facultatif)

Git Large File System est une fonctionnalité de Git qui vous permet d'enregistrer des fichiers volumineux de manière plus efficace, tels que des documents Photoshop, des archives ZIP et, dans notre cas, des images. Étant donné que les images peuvent nécessiter une gestion des versions mais ne sont pas exactement du code, il est logique de les stocker différemment des fichiers texte ordinaires. Cela fonctionne en stockant l'image sur un serveur distant, et le fichier de votre référentiel sera un fichier texte contenant un pointeur vers cette ressource distante.

Hélas, ce n'est pas une option sur laquelle il suffit de cliquer pour l'activer. Vous devez configurer votre référentiel pour activer LFS et cela nécessite du travail localement. Une fois Git installé, vous devez installer une extension Git-LFS :

 git lfs install

Si, comme moi, cette commande n'a pas fonctionné pour vous, essayez l'alternative Homebrew (pour macOS ou Linux):

 brew install git-lfs

Une fois cela fait, vous devrez spécifier les fichiers à suivre dans votre référentiel. J'hébergerai toutes les images que j'ai téléchargées dans le dossier /upload de WordPress dans un dossier portant le même nom sur ma configuration Hugo, sauf que ce dossier se trouvera dans un dossier /static (qui se résoudra à la racine une fois compilé). Décidez de la structure de vos dossiers et suivez vos fichiers à l'intérieur :

 git lfs track "static/uploads/*"

Cela suivra tous les fichiers dans le dossier /static/uploads . Vous pouvez également utiliser les éléments suivants :

 git lfs track "*.jpg"

Cela permettra de suivre tous les fichiers JPG de votre référentiel. Vous pouvez mélanger et assortir pour ne suivre que les JPG dans un certain dossier, par exemple.

Une fois cela en place, vous pouvez valider vos fichiers de configuration LFS dans votre référentiel et les transférer vers votre référentiel distant. La prochaine fois que vous validerez localement un fichier qui correspond à la configuration de suivi LFS, il sera « converti » en ressource LFS. Si vous travaillez sur une branche de développement, fusionnez ce commit dans votre branche principale.

Jetons maintenant un coup d'œil à Netlify.

5. Création du site sur Netlify

À ce stade, votre référentiel est configuré, vous pouvez donc continuer et créer un compte sur Netlify. Vous pouvez même vous connecter avec votre compte GitHub, GitLab ou Bitbucket si vous le souhaitez. Une fois sur le tableau de bord, cliquez sur le bouton "Nouveau site de Git" dans le coin supérieur droit et créez votre nouveau site Netlify.

Remarque : Vous pouvez laisser toutes les options à leurs valeurs par défaut pour le moment.

Sélectionnez votre fournisseur Git : cela ouvrira une fenêtre pop-up pour vous authentifier. Lorsque cela sera fait, la fenêtre se fermera et vous verrez une liste des référentiels sur ce fournisseur Git auquel vous avez accès. Sélectionnez votre repo fraîchement créé et continuez. On vous demandera quelques choses, dont la plupart vous pouvez simplement laisser par défaut car toutes les options sont modifiables plus tard.

Pour l'instant, dans les paramètres du site, cliquez sur "Modifier le nom du site" et nommez votre site comme vous le souhaitez - je vais choisir chris-smashing-hugo-blog . On va désormais pouvoir accéder au site via chris-smashing-hugo-blog.netlify.com : une belle page 404 !

6. Préparation pour Netlify Large Media (facultatif)

Si vous configurez Git LFS et prévoyez d'utiliser Netlify, vous devrez suivre ces étapes. C'est un peu plus compliqué mais ça vaut vraiment le coup : cela vous permettra de définir des chaînes de requête sur les URL d'image qui seront automatiquement transformées.

Disons que vous avez un lien vers portrait.jpg qui est une image de 900×1600 pixels. Avec Netlify Large Media, vous pouvez appeler le fichier portrait.jpg?nf_resize=fit&w=420 , qui le redimensionnera proportionnellement. Si vous définissez à la fois w et h , et définissez nf_resize=smartcrop , il sera redimensionné en recadrant pour se concentrer sur le point d'intérêt de l'image (tel que déterminé par un algorithme sophistiqué, alias robot brain magic ! ). Je trouve que c'est un excellent moyen d'avoir des vignettes comme celles générées par WordPress, sans avoir besoin de plusieurs fichiers pour une image sur mon référentiel.

Si cela vous intéresse, installons-le !

La première étape consiste à installer l'interface de ligne de commande (CLI) de Netlify via npm :

 npm install netlify-cli -g

Si cela a fonctionné, l'exécution de la commande netlify devrait donner des informations sur l'outil.

Vous devrez ensuite vous assurer que vous êtes dans votre dossier de référentiel local (que j'ai nommé « hugorepo » plus tôt), et exécuter :

 netlify login

Autorisez le jeton. Ensuite, nous devrons installer le plugin Netlify Large Media. Cours:

 netlify plugins:install netlify-lm-plugin netlify lm:install

Il devrait y avoir une ligne de commande affichée à la fin du message résultant que vous devez copier (qui devrait ressembler à /Users/YOURNAME/.netlify/helper/path.bash.inc sur Mac) - exécutez-la. Notez que Keychain peut vous demander le mot de passe administrateur de votre machine sous macOS.

L'étape suivante consiste à lier Netlify :

 netlify link

Vous pouvez fournir le nom de votre site ici (j'ai fourni le nom chris-smashing-hugo-blog que je lui ai donné plus tôt). Avec cela en place, il vous suffit de configurer la fonctionnalité Large Media en exécutant ce qui suit :

 netlify lm:setup

Validez ces nouvelles modifications dans votre référentiel local et envoyez-les à la branche de développement distante. J'ai eu quelques erreurs avec Sourcetree et Keychain dans le sens de git "credential-netlify" is not a git command . Si c'est votre cas, essayez d'appuyer manuellement avec ces commandes :

 git add -A git commit -m "Set up Netlify Large media" git push

Si cela ne fonctionne pas, vous devrez peut-être installer Netlify Credential Helper. Voici comment le faire avec Homebrew :

 brew tap netlify/git-credential-netlify brew install git-credential-netlify

Essayez de pousser votre commit maintenant (avec votre interface graphique ou votre terminal de commande) : cela devrait fonctionner !

Remarque : Si vous modifiez votre mot de passe Netlify, exécutez à netlify logout et netlify login .

Vous pourriez demander : "Tout cela, et nous n'avons même pas encore initialisé notre build Hugo ?" Oui, je sais, ça a pris du temps mais tous les préparatifs de la transition sont faits. Nous pouvons maintenant mettre en place notre blog Hugo !

7. Configurer Hugo sur votre ordinateur

Vous devrez d'abord installer Hugo sur votre ordinateur avec l'une des options fournies. J'utiliserai Homebrew mais les utilisateurs de Windows peuvent utiliser Scoop ou Chocolatey, ou télécharger directement un package.

 brew install hugo

Vous devrez ensuite créer un nouveau site Hugo mais il n'aimera pas le configurer dans un dossier non vide. Première option : vous pouvez le créer dans un nouveau dossier et déplacer son contenu dans le dossier du référentiel local :

 hugo new site your_temporary_folder

Deuxième option : vous pouvez forcer l'installation dans votre référentiel local avec un indicateur, assurez-vous simplement que vous l'exécutez dans le bon dossier :

 hugo new site . --force

Vous avez maintenant un site Hugo, que vous pouvez démarrer avec cette commande :

 hugo server

Vous obtiendrez un aperçu local sur localhost . Malheureusement, vous n'avez pas de contenu ni de thème à vous. Ne vous inquiétez pas, nous mettrons cela en place très bientôt !

Jetons d'abord un coup d'œil au fichier de configuration ( config.toml dans mon cas) : configurons le nom et l'URL de base du blog (cela doit correspondre à l'URL de votre tableau de bord Netlify) :

 title = "Chris' Smashing Hugo Blog" baseURL = "https://chris-smashing-hugo-blog.netlify.com"

Ce lien sera écrasé pendant que vous développez localement, vous ne devriez donc pas rencontrer d'erreurs 404.

Donnons à Hugo nos articles exportés au format Markdown. Ils devraient se trouver dans le /WP2Hugo/blog2md/out dès la première étape. Dans le dossier Hugo (alias le répertoire du référentiel local), accédez au dossier de content et créez un sous-dossier nommé posts . Placez-y vos fichiers Markdown, puis configurons un thème.

8. Création de votre thème personnalisé

Pour cette étape, je recommande de télécharger le passe-partout Saito, qui est un thème avec tous les partiels dont vous aurez besoin pour commencer (et aucun style) — un point de départ très utile. Vous pouvez, bien sûr, consulter cette collection de thèmes prêts à l'emploi pour Hugo si vous souhaitez ignorer cette partie du processus. Cela ne tient qu'à toi!

Depuis le dossier du référentiel local, clonez le thème dans themes/saito :

 git submodule add https://github.com/hakuoku/saito-boilerplate.git themes/saito

Vous pouvez renommer ce dossier comme vous le souhaitez, comme cool-theme . Vous devrez indiquer à votre configuration Hugo quel thème vous souhaitez utiliser en éditant votre fichier config.toml/yaml/json . Modifiez la valeur du thème en saito , ou cool-theme , ou quel que soit le nom du dossier de votre thème. Votre aperçu devrait maintenant afficher le titre de votre blog avec une ligne de copyright. C'est un début, non ?

Ouvrez le fichier layout/partials/home.html du thème et éditez-le pour afficher votre contenu, en vous limitant aux cinq premiers éléments qui sont de type posts (dans le dossier content/posts/ ), avec range , first et where :

 <div class="container"> {{ range first 5 (where .Paginator.Pages "Type" "posts") }} <article class="post post--{{ .Params.class }}"> <h2 class="post__title">{{ .Title }}</h2> <section class="post__content"> {{ .Content }} </section> </article> {{ end }} </div>

Votre contenu est maintenant visible, de la manière la plus élémentaire. Il est temps de vous l'approprier — plongeons-y !

Modèle avec Hugo

Vous pouvez d'abord lire l'Introduction aux modèles Hugo si vous le souhaitez, mais je vais essayer de passer en revue quelques éléments essentiels qui vous aideront à comprendre les bases.

Toutes les opérations dans Hugo sont définies à l'intérieur de délimiteurs : des accolades doubles (par exemple {{ .Title }} ), ce qui devrait vous sembler familier si vous avez déjà fait un peu de modélisation. Si ce n'est pas le cas, considérez-le comme un moyen d'exécuter des opérations ou d'injecter des valeurs à un point spécifique de votre balisage. Pour les blocs, ils se terminent par la balise {{ end }} , pour toutes les opérations en dehors des shortcodes.

Les thèmes ont un dossier de layout en page qui contient les éléments de la mise en page. Le dossier _default sera le point de départ d'Hugo, baseof.html étant ( vous l'aurez deviné ! ) la base de votre mise en page. Il appellera chaque composant, appelé "partials" (plus à ce sujet dans la documentation d'Hugo sur Partial Template), similaire à la façon dont vous utiliseriez include en PHP, que vous avez peut-être déjà vu dans votre thème WordPress. Les partiels peuvent appeler d'autres partiels — mais n'en faites pas une boucle infinie.

Vous pouvez appeler un partiel avec {{ partial "file.html" . }} {{ partial "file.html" . }} syntaxe. La section partial est assez simple, mais les deux autres pourraient avoir besoin d'explications. Vous pourriez vous attendre à devoir écrire partials/file.html mais puisque tous les partiels doivent être dans le dossier « partials », Hugo peut très bien trouver ce dossier. Bien sûr, vous pouvez créer des sous-dossiers dans le dossier "partiels" si vous avez besoin de plus d'organisation.

Vous avez peut-être remarqué un point parasite : c'est le contexte que vous passez à votre partiel. Si vous aviez un partiel de menu et une liste de liens et d'étiquettes, vous pourriez passer cette liste dans le partiel afin qu'il ne puisse accéder qu'à cette liste, et rien d'autre. Je parlerai plus de ce point insaisissable dans la section suivante.

Votre fichier baseof.html est un shell qui appelle tous les différents partiels nécessaires pour rendre la mise en page de votre blog. Il devrait avoir un code HTML minimal et beaucoup de partiels :

 <!DOCTYPE html> <html lang="{{ .Site.LanguageCode }}"> <head> <title>{{ block "title" . }}{{ .Site.Title }}{{ end }}</title> {{ partial "head.html" . }} </head> <body> {{ partial "header.html" . }} {{ partial "nav.html" . }} <main> {{ block "main" . }}{{ end }} </main> <aside> {{ partial "sidebar.html" . }} </aside> {{ partial "footer.html" . }} </body> </html>

Le {{ block "main" . }}{{ end }} La ligne {{ block "main" . }}{{ end }} est différente car il s'agit d'un bloc défini avec un modèle basé sur le contenu de la page actuelle (page d'accueil, page de publication unique, etc.) avec {{ define "main" }} .

Feuilles de style

Dans votre thème, créez un dossier nommé assets dans lequel nous placerons un dossier css . Il contiendra nos fichiers SCSS, ou un vieux fichier CSS fidèle. Maintenant, il devrait y avoir un fichier css.html dans le dossier partials (qui est appelé par head.html ). Pour convertir Sass/SCSS en CSS et réduire la feuille de style, nous utiliserions cette série de fonctions (en utilisant la syntaxe Hugo Pipes au lieu d'envelopper les fonctions les unes autour des autres) :

 {{ $style := resources.Get "css/style.scss" | toCSS | minify | fingerprint }}

En prime - puisque j'ai eu du mal à trouver une réponse directe - si vous souhaitez utiliser Autoprefixer, Hugo implémente également PostCSS. Vous pouvez ajouter une fonction pipe supplémentaire entre toCSS et minify sur la première ligne, comme ceci :

 {{ $style := resources.Get "css/style.scss" | toCSS | postCSS | minify | fingerprint }}

Créez un fichier « postcss.config.js » à la racine de votre blog Hugo, et transmettez les options, telles que :

 module.exports = { plugins: { autoprefixer: { browsers: [ "> 1%", "last 2 versions" ] } }, }

Et hop ! De Sass au CSS préfixé et minifié. La fonction de pipe "empreinte digitale" est de s'assurer que le nom de fichier est unique, comme style.c66e6096bdc14c2d3a737cff95b85ad89c99b9d1.min.css . Si vous modifiez la feuille de style, l'empreinte digitale change, le nom de fichier est donc différent et vous obtenez ainsi une solution efficace de contournement du cache.

9. Notes sur la syntaxe Hugo

Je veux m'assurer que vous comprenez "le point", c'est-à-dire comment Hugo étend les variables (ou dans mes propres mots, fournit une référence contextuelle) que vous utiliserez dans vos modèles.

Le point et la portée

Le point est comme une variable de niveau supérieur que vous pouvez utiliser dans n'importe quel modèle ou code court, mais sa valeur est limitée à son contexte. La valeur du point dans un modèle de niveau supérieur comme baseof.html est différente de la valeur à l'intérieur des blocs de boucle ou with blocs.

Disons que c'est dans notre template dans notre partiel head.html :

 {{ with .Site.Title }} {{ finir }}

Même si nous l'exécutons dans la portée principale, la valeur du point change en fonction du contexte, qui est .Site.Title dans ce cas. Ainsi, pour imprimer la valeur, il vous suffit d'écrire . au lieu de ressaisir le nom de la variable. Cela m'a dérouté au début, mais vous vous y habituez très rapidement, et cela aide à réduire la redondance puisque vous ne nommez la variable qu'une seule fois. Si quelque chose ne fonctionne pas, c'est généralement parce que vous essayez d'appeler une variable de niveau supérieur à l'intérieur d'un bloc de portée.

Alors, comment utilisez-vous la portée de niveau supérieur à l'intérieur d'un bloc de portée ? Eh bien, disons que vous voulez vérifier une valeur mais en utiliser une autre. Vous pouvez utiliser $ qui sera toujours la portée de niveau supérieur :

 {{ with .Site.Params.InfoEnglish }}{{ $.Site.Params.DescriptionEnglish }}{{ end }}

Dans notre condition, la portée est .Site.Params.InfoEnglish mais nous pouvons toujours accéder à des valeurs en dehors de celle-ci avec $ , où l'utilisation intuitive de .Site.Params.DescriptionEnglish ne fonctionnerait pas car elle tenterait de se résoudre en .Site.Params.InfoEnglish.Site.Params.DescriptionEnglish , lançant une erreur.

Variables personnalisées

Vous pouvez affecter des variables à l'aide de la syntaxe suivante :

 {{ $customvar := "custom value" }}

Le nom de la variable doit commencer par $ et l'opérateur d'affectation doit être := si c'est la première fois qu'il est affecté, = sinon comme ceci :

 {{ $customvar = "updated value" }}

Le problème que vous pourriez rencontrer est que cela ne sortira pas du champ d'application, ce qui m'amène au point suivant.

Rayure

La fonctionnalité Scratch vous permet d'attribuer des valeurs disponibles dans tous les contextes. Supposons que vous ayez une liste de films dans un fichier movies.json :

 [ { "name": "The Room", "rating": 4 }, { "name": "Back to the Future", "rating": 10 }, { "name": "The Artist", "rating": 7 } ]

Maintenant, vous voulez parcourir le contenu du fichier et stocker votre favori pour l'utiliser plus tard. C'est là que Scratch entre en jeu :

 {{ .Scratch.Set "favouriteMovie" "None" }}{{ /* Optional, just to get you to see the difference syntax based on the scope */ }} {{ range .Site.Data.movies }} {{ if ge .rating 10 }} {{ /* We must use .Scratch prefixed with a $, because the scope is .Site.Data.movies, at the current index of the loop */ }} {{ $.Scratch.Set "favouriteMovie" .name }} {{ end }} {{ end }} [...] My favourite movie is {{ .Scratch.Get "favouriteMovie" }} <!-- Expected output => My favourite movie is Back to the Future -->

Avec Scratch, nous pouvons extraire une valeur de l'intérieur de la boucle et l'utiliser n'importe où. Au fur et à mesure que votre thème devient de plus en plus complexe, vous vous retrouverez probablement à rechercher Scratch.

Remarque : ceci n'est qu'un exemple car cette boucle peut être optimisée pour produire ce résultat sans Scratch, mais cela devrait vous permettre de mieux comprendre comment cela fonctionne.

Conditionnels

La syntaxe des conditions est un peu différente de ce à quoi vous vous attendiez - du point de vue de JavaScript ou de PHP. Il existe, par essence, des fonctions qui prennent deux arguments (parenthèse facultative si vous appelez directement les valeurs) :

 {{ if eq .Site.LanguageCode "en-us" }}Welcome!{{ end }}

Il existe plusieurs de ces fonctions :

• eq vérifie l'égalité
• ne vérifie l'inégalité
• gt vérifier supérieur à
• ge vérifier supérieur ou égal à
• lt moins de
• le vérifie inférieur ou égal à

Remarque : Vous pouvez tout savoir sur les fonctions proposées par Hugo dans la référence rapide des fonctions Hugo.

Espace blanc

Si vous êtes aussi pointilleux que moi sur la sortie, vous remarquerez peut-être des lignes vides indésirables. En effet, Hugo analysera votre balisage tel quel, en laissant des lignes vides autour des conditions qui n'ont pas été remplies, par exemple.

Disons que nous avons ce partiel hypothétique :

 {{ if eq .Site.LanguageCode "en-us" }} <p>Welcome to my blog!</p> {{ end }} <img src="/uploads/portrait.jpg" alt="Blog Author">

Si le code de langue du site n'est pas en-us , ce sera la sortie HTML (notez les trois lignes vides avant la balise image) :

 <img src="/uploads/portrait.jpg" alt="Blog Author">

Hugo fournit une syntaxe pour résoudre ce problème avec un trait d'union à côté des accolades à l'intérieur du délimiteur. {{- coupera l'espace blanc avant les accolades, et -}} coupera l'espace blanc après les accolades. Vous pouvez utiliser l'un ou l'autre ou les deux en même temps, mais assurez-vous simplement qu'il y a un espace entre le trait d'union et l'opération à l'intérieur du délimiteur.

Ainsi, si votre modèle contient les éléments suivants :

 {{- if eq .Site.LanguageCode "en-us" -}} <p>Welcome to my blog!</p> {{- end -}} <img src="/uploads/portrait.jpg" alt="Blog Author">

… alors le balisage se traduira par ceci (sans lignes vides):

 <img src="/uploads/portrait.jpg" alt="Blog Author">

Cela peut être utile pour d'autres situations comme les éléments avec display: inline-block qui ne doivent pas avoir d'espace entre eux. Inversement, si vous voulez vous assurer que chaque élément est sur sa propre ligne dans le balisage (par exemple dans une boucle {{ range }} ), vous devrez placer soigneusement vos traits d'union pour éviter le découpage "gourmand" des espaces blancs.

L'exemple ci-dessus afficherait ce qui suit si le code de langue du site correspond à « en-us » (plus de sauts de ligne entre les balises p et img ) :

 <p>Welcome to my blog!</p><img src="/uploads/portrait.jpg" alt="Blog Author">

10. Contenu et données

Votre contenu est stocké sous forme de fichiers Markdown, mais vous pouvez également utiliser HTML. Hugo le rendra correctement lors de la construction de votre site.

Votre page d'accueil appellera la mise en page _default/list.html , qui pourrait ressembler à ceci :

 {{ define "main" }} {{ partial "list.html" . }} {{ end }}

Le bloc principal appelle le partiel list.html avec le contexte de . , alias le niveau supérieur. Le partiel list.html peut ressembler à ceci :

 {{ define "main" }} <ol class="articles"> {{ range .Paginator.Pages }} <li> <article> <a href="{{ .URL }}"> <h2>{{ .Title }}</h2> <img src="{{ .Params.featuredimage }}" alt=""> <time datetime="{{ .Date.Format "2006-01-02" }}"> {{ .Date.Format "January 2 2006" }} </time> </a> </article> </li> {{ end }} </ol> {{ partial "pagination.html" . }} {{ end }}

Nous avons maintenant une liste de base de nos articles, que vous pouvez styliser comme vous le souhaitez ! Le nombre d'articles par page est défini dans le fichier de configuration, avec paginate = 5 (en TOML).

Vous pourriez être complètement confus comme je l'étais par le formatage de la date dans Hugo. Chaque fois que l'unité est mappée sur un nombre (premier mois, deuxième jour, troisième heure, etc.) m'a beaucoup plus de sens une fois que j'ai vu l'explication visuelle ci-dessous fournie par la documentation en langage Go - ce qui est un peu bizarre, mais un peu intelligent, aussi!

 Jan 2 15:04:05 2006 MST => 1 2 3 4 5 6 -7

Il ne vous reste plus qu'à afficher votre message sur une seule page. Vous pouvez modifier le partiel post.html pour personnaliser la mise en page de votre article :

 <article> <header> <h1>{{ .Title }}</h1> <p> Posted on <time datetime="{{ .Date.Format "2006-01-02" }}">{{ .Date.Format "2006. 1. 2" }}</time> </p> </header> <section> {{ .Content }} </section> </article>

Et c'est ainsi que vous affichez votre contenu !

Si vous souhaitez personnaliser l'URL, mettez à jour votre fichier de configuration en ajoutant une option [permalinks] (TOML), qui dans ce cas fera ressembler les URL à my-blog.com/post-slug/ :

 [permalinks] posts = ":filename/"

Si vous souhaitez générer un flux RSS de votre contenu (parce que RSS est génial), ajoutez ce qui suit dans le fichier de configuration de votre site (le modèle par défaut de Saito affichera les balises appropriées dans head.html si ces options sont détectées) :

 rssLimit = 10 [outputFormats] [outputFormats.RSS] mediatype = "application/rss" baseName = "feed"

Mais que se passerait-il si vous aviez une sorte de contenu en dehors d'un message ? C'est là qu'interviennent les modèles de données : vous pouvez créer des fichiers JSON et extraire leurs données pour créer votre menu ou un élément dans votre barre latérale. YAML et TOML sont également des options mais moins lisibles avec des données complexes (par exemple des objets imbriqués). Vous pouvez, bien sûr, définir cela dans le fichier de configuration de votre site, mais c'est - pour moi - un peu moins facile à naviguer et moins indulgent.

Créons une liste de "sites sympas" que vous voudrez peut-être afficher dans votre barre latérale - avec un lien et une étiquette pour chaque site sous forme de tableau en JSON :

 { "coolsites": [ { "link": "https://smashingmagazine.com", "label": "Smashing Magazine" }, { "link": "https://gohugo.io/", "label": "Hugo" }, { "link": "https://netlify.com", "label": "Netlify" } ] }

Vous pouvez enregistrer ce fichier à la racine de votre référentiel ou à la racine de votre thème, dans un dossier de data , tel que /data/coolsites.json . Ensuite, dans votre sidebar.html partiel, vous pouvez le parcourir avec range en utilisant .Site.Data.coolsites :

 <h3>Cool Sites:</h3> <ul> {{ range .Site.Data.coolsites.coolsites }} <li><a href="{{ .link }}">{{ .label }}</a></li> {{ end }} </ul>

Ceci est très utile pour tout type de données personnalisées sur lesquelles vous souhaitez effectuer une itération. Je l'ai utilisé pour créer une liste Google Fonts pour mon thème, dans quelles catégories les publications peuvent être, auteurs (avec bio, avatar et lien vers la page d'accueil), quels menus afficher et dans quel ordre. Vous pouvez vraiment faire beaucoup de choses avec cela, et c'est assez simple.

Une dernière réflexion sur les données et autres : tout ce que vous mettez dans votre dossier Hugo /static sera disponible à la racine ( / ) sur la version en direct. Il en va de même pour le dossier de thème.

11. Déploiement sur Netlify

Alors vous avez terminé, ou peut-être voulez-vous simplement voir quel genre de magie opère Netlify ? Cela me semble bien, tant que votre serveur Hugo local ne renvoie pas d'erreur.

Validez vos modifications et envoyez-les à votre branche de développement distante ( dev ). Rendez-vous ensuite sur Netlify et accédez aux paramètres de votre site. Vous verrez une option pour "Construire et déployer". Nous allons devoir changer quelques choses ici.

1. Tout d'abord, dans la section "Build settings", assurez-vous que "Build command" est défini sur hugo et que "Publish directory" est défini sur public (la valeur par défaut qu'il est recommandé de conserver dans votre fichier de configuration Hugo) ;
2. Ensuite, dans la section "Déployer les contextes", définissez "Branche de production" sur votre branche principale dans votre référentiel. Je suggère également que votre "déploiement de branche" soit défini sur "Déployer uniquement la branche de production" ;
3. Enfin, dans la section "Variables d'environnement", éditez les variables et cliquez sur "Nouvelle variable". Nous allons paramétrer l'environnement Hugo à 0.53 avec le couple suivant : set key à HUGO_VERSION et value à 0.53 .

Maintenant, dirigez-vous vers votre référentiel distant et fusionnez votre branche de développement dans votre branche principale : ce sera le crochet qui déploiera votre blog mis à jour (cela peut être personnalisé mais la valeur par défaut est raisonnable pour moi).

De retour à votre tableau de bord Netlify, les "déploiements de production" de votre site devraient avoir une nouvelle activité. Si tout s'est bien passé, cela devrait être traité et résolu en une étiquette "Publié". Cliquer sur l'élément de déploiement ouvrira une vue d'ensemble avec un journal des opérations. En haut, vous verrez "Aperçu du déploiement". Allez-y, cliquez dessus - vous le méritez. C'est vivant!

12. Configurer un domaine personnalisé

Avoir l'URL my-super-site.netlify.com n'est pas à votre goût, et vous possédez déjà my-super-site.com ? Je comprends. Changeons cela !

Rendez-vous chez votre registraire de domaine et accédez aux paramètres DNS de votre domaine. Ici, vous devrez créer une nouvelle entrée : vous pouvez soit définir un enregistrement ALIAS/CNAME qui pointe vers my-super-site.netlify.com , soit définir un enregistrement A qui pointe votre domaine vers l'équilibreur de charge de Netlify, qui est 104.198.14.52 au moment de la rédaction.

Vous pouvez trouver les dernières informations sur la documentation de Netlify sur les domaines personnalisés. L'adresse IP de l'équilibreur de charge se trouvera dans la section des paramètres DNS, sous "Configuration DNS manuelle pour les domaines personnalisés racine et www".

Lorsque cela est fait, rendez-vous sur le tableau de bord de votre site sur Netlify et cliquez sur "Paramètres du domaine", où vous verrez "Ajouter un domaine personnalisé". Entrez votre nom de domaine pour le vérifier.

Vous pouvez également gérer vos domaines via votre tableau de bord dans l'onglet Domaines. L'interface semble moins déroutante sur cette page, mais cela vous aidera peut-être à donner plus de sens à vos paramètres DNS, comme cela a été le cas pour moi.

Remarque : Netlify peut également tout gérer pour vous si vous souhaitez acheter un domaine par leur intermédiaire. C'est plus simple mais c'est un surcoût.

Après avoir configuré votre domaine personnalisé, dans "Paramètres du domaine", faites défiler jusqu'à la section "HTTPS" et activez le certificat SSL/TLS. Cela peut prendre quelques minutes mais cela vous accordera un certificat gratuit : votre domaine fonctionne maintenant sur HTTPS.

13. Modification du contenu sur Netlify CMS

Si vous souhaitez modifier vos articles, télécharger des images et modifier les paramètres de votre blog comme vous le feriez sur l'interface back-end de WordPress, vous pouvez utiliser Netlify CMS qui propose un très bon didacticiel. C'est un fichier unique qui gérera tout pour vous (et il est indépendant du générateur : il fonctionnera avec Jekyll, Eleventy, etc.).

Il vous suffit de télécharger deux fichiers dans un dossier :

• le CMS (un seul fichier HTML) ;
• un fichier de configuration (un fichier YAML).

Ce dernier contiendra tous les paramètres de votre site particulier.

Allez dans le dossier /static de votre racine Hugo et créez un nouveau dossier auquel vous accéderez via my-super-site.com/FOLDER_NAME (j'appellerai le mien admin ). Dans ce dossier admin , créez un fichier index.html en copiant le balisage fourni par Netlify CMS :

 <!doctype html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Content Manager</title> </head> <body> <!-- Include the script that builds the page and powers Netlify CMS --> <script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script> </body> </html>

L'autre fichier que vous devrez créer est le fichier de configuration : config.yml . Il vous permettra de définir les paramètres de votre site (nom, URL, etc.) afin que vous puissiez configurer ce que doivent contenir les pages d'accueil de vos messages, ainsi que la façon dont vos fichiers de données (le cas échéant) doivent être modifiables. C'est un peu plus complexe à mettre en place, mais cela ne veut pas dire que ce n'est pas facile.

Si vous utilisez GitHub ou GitLab, démarrez votre fichier config.yml avec :

 backend: name: git-gateway branch: dev # Branch to update (optional; defaults to master)

Si vous utilisez Bitbucket, c'est un peu différent :

 backend: name: bitbucket repo: your-username/your-hugorepo branch: dev # Branch to update (optional; defaults to master)

Ensuite, pour nos téléchargements, nous devrons indiquer au CMS où les stocker :

 media_folder: "static/images/uploads" # Media files will be stored in the repo under static/images/uploads public_folder: "/images/uploads" # The src attribute for uploaded media will begin with /images/uploads

Lorsque vous créez un nouveau message, le CMS génère le slug pour le nom de fichier que vous pouvez personnaliser avec trois options :

slug: encoding: "ascii" # You can also use "unicode" for non-Latin clean_accents: true # Removes diacritics from characters like e or a sanitize_replacement: "-" # Replace unsafe characters with this string

Enfin, vous devrez définir comment les données de vos publications sont structurées. Je vais également définir comment le fichier de données coolsites est structuré - juste au cas où je voudrais ajouter un autre site à la liste. Celles-ci sont définies avec l'objet collections qui sera certainement le plus verbeux, ainsi qu'une belle poignée d'options sur lesquelles vous pouvez en savoir plus ici.

 collections: - name: "articles" # Used in routes, eg, /admin/collections/blog label: "Articles" # Used in the Netlify CMS user interface folder: "content/posts" # The path to the folder where the posts are stored, usually content/posts for Hugo create: true # Allow users to create new documents in this collection slug: "{{slug}}" # Filename template, eg, post-title.md fields: # The fields for each document, usually in front matter - {label: "Title", name: "title", widget: "string", required: true} - {label: "Draft", name: "draft", widget: "boolean", default: true } - {label: "Type", name: "type", widget: "hidden", default: "post" } - {label: "Publish Date", name: "date", widget: "date", format: "YYYY-MM-DD"} - {label: "Featured Image", name: "featuredimage", widget: "image"} - {label: "Author", name: "author", widget: "string"} - {label: "Body", name: "body", widget: "markdown"} - name: 'coolsites' label: 'Cool Sites' file: 'data/coolsites.json' description: 'Website to check out' fields: - name: coolsites label: Sites label_singular: 'Site' widget: list fields: - { label: 'Site URL', name: 'link', widget: 'string', hint: 'https://…' } - { label: 'Site Name', name: 'label', widget: 'string' }

Remarque : Vous pouvez en savoir plus sur la configuration des champs individuels dans la documentation Netlify CMS Widgets qui passe en revue chaque type de widget et comment les utiliser - particulièrement utile pour les formats de date.

Authentification

La dernière chose que nous devons faire est de nous assurer que seuls les utilisateurs autorisés peuvent accéder au backend ! L'utilisation de l'authentification de votre fournisseur Git est un moyen simple d'y parvenir.

Rendez-vous sur votre site Netlify et cliquez sur l'onglet "Paramètres". Ensuite, allez dans "Contrôle d'accès" qui est le dernier lien du menu sur le côté gauche. Ici, vous pouvez configurer OAuth pour qu'il s'exécute via GitHub, GitLab ou Bitbucket en fournissant une clé et une valeur secrète définies pour votre compte utilisateur (pas dans le référentiel). Vous voudrez utiliser le même fournisseur Git que celui sur lequel votre référentiel est enregistré.

GitHub

Accédez à votre page "Paramètres" sur GitHub (cliquez sur votre avatar pour afficher le menu) et accédez aux "Paramètres du développeur". Cliquez sur "Enregistrer une nouvelle application" et fournissez les valeurs requises :

• un nom, tel que "Netlify CMS pour mon super blog" ;
• une URL de page d'accueil, le lien vers votre site Netlify ;
• une description, si le coeur vous en dit;
• l'URL de rappel de l'application, qui doit être « https://api.netlify.com/auth/done ».

Enregistrez et vous verrez votre ID client et votre secret client. Fournissez-les au contrôle d'accès de Netlify.

GitLab

Cliquez sur votre avatar pour accéder à la page Paramètres, puis cliquez sur "Applications" dans le menu "Paramètres utilisateur" sur la gauche. Vous verrez un formulaire pour ajouter une nouvelle application. fournissez les informations suivantes:

• un nom, tel que "Netlify CMS pour mon super blog" ;
• un URI de redirection, qui doit être « https://api.netlify.com/auth/done » ;
• les périmètres à vérifier sont :
  • api
  • read_user
  • read_repository
  • write_repository
  • read_registry

L'enregistrement de votre application vous donnera votre ID d'application et votre secret, que vous pouvez maintenant saisir sur le contrôle d'accès de Netlify.

Bitbucket

Rendez-vous dans les paramètres de votre compte utilisateur (cliquez sur votre avatar, puis sur "Paramètres Bitbucket"). Sous "Gestion des accès", cliquez sur "OAth". Dans la section "Consommateurs OAuth", cliquez sur "Ajouter un consommateur". Vous pouvez laisser la plupart des choses à leurs valeurs par défaut, sauf celles-ci :

• un nom, tel que "Netlify CMS pour mon super blog" ;
• une URL de rappel, qui doit être « https://api.netlify.com/auth/done » ;
• les permissions à vérifier sont :
  • Compte : Courriel, lecture, écriture
  • Référentiels : lecture, écriture, administrateur
  • Demandes d'extraction : lecture, écriture
  • Webhooks : Lire et écrire

Après avoir enregistré, vous pouvez accéder à votre clé et à votre secret, que vous pouvez ensuite fournir sur le contrôle d'accès de Netlify.

Après avoir fourni les jetons, accédez à Netlify et recherchez les paramètres du site. Dirigez-vous vers "Identité" et activez la fonctionnalité. Vous pouvez maintenant ajouter un fournisseur externe : sélectionnez votre fournisseur Git et cliquez sur "Activer".

Si vous avez besoin de détails supplémentaires, Netlify CMS a un guide d'authentification que vous pouvez lire.

Vous pouvez maintenant accéder au backend de votre site Netlify et modifier le contenu. Chaque modification est un commit sur votre référentiel, dans la branche spécifiée dans votre fichier de configuration. Si vous avez conservé votre branche main comme cible pour Netlify CMS, chaque fois que vous enregistrez, une nouvelle version est exécutée. Plus pratique, mais pas aussi propre avec des "états intermédiaires".

L'enregistrer sur une dev de développement vous permet d'avoir un contrôle plus précis sur le moment où vous souhaitez exécuter une nouvelle version. Ceci est particulièrement important si votre blog a beaucoup de contenu et nécessite un temps de construction plus long. L'une ou l'autre manière fonctionnera ; c'est juste une question de comment vous voulez gérer votre blog .

Veuillez également noter que Git LFS est quelque chose que vous avez installé localement, donc les images téléchargées via Netlify CMS seront "normales". Si vous extrayez localement votre branche distante, les images doivent être converties en LFS, que vous pouvez ensuite valider et pousser vers votre branche distante. De plus, Netlify CMS ne prend actuellement pas en charge LFS, donc l'image ne sera pas affichée dans le CMS, mais elle apparaîtra sur votre version finale.

Lecture recommandée : Static Site Generators Review : Jekyll, Middleman, Roots, Hugo

Conclusion

Quelle course! Dans ce didacticiel, vous avez appris à exporter votre publication WordPress vers des fichiers Markdown, à créer un nouveau référentiel, à configurer Git LFS, à héberger un site sur Netlify, à générer un site Hugo, à créer votre propre thème et à modifier le contenu avec Netlify CMS. . Pas mal!

Et après? Eh bien, vous pouvez expérimenter votre configuration Hugo et en savoir plus sur les différents outils proposés par Hugo - il y en a beaucoup que je n'ai pas couverts par souci de brièveté.

Explorer! S'amuser! Blog!

Autres ressources

• Documentation Hugo
  • Installation
  • Démarrage rapide
  • Configuration
  • Modèles
  • Taxonomies
  • Codes abrégés
  • Hugo sur Netlify
• Documentation Netlify
  • Domaines personnalisés
  • DNS géré
  • scripts de déploiement netlify.toml
• Documentation du CMS Netlify
  • Widget
• Git LFS