Contrôle des URL et des liens dans Jekyll

introduction

Jekyll est un générateur de sites statiques qui offre certains des avantages d'un système de gestion de contenu (CMS) tout en évitant les problèmes de performances et de sécurité engendrés par ces sites. Il est «compatible avec les blogs» avec des fonctionnalités spéciales pour gérer le contenu organisé par date, bien que son utilité ne se limite pas aux sites de blogs. Jekyll convient parfaitement aux personnes qui ont besoin de travailler hors ligne, qui préfèrent utiliser un éditeur léger au lieu de formulaires Web pour gérer le contenu et qui souhaitent utiliser le contrôle de version pour suivre les modifications apportées à leur site Web.

Dans ce didacticiel, nous allons nous intéresser plus particulièrement à la façon dont Jekyll traite les URL et les liens, car le changement d’URL rompra le lien des autres personnes vers nos pages, ainsi que des liens dans le contenu de notre propre site. Les URL sont essentielles à la manière dont les internautes trouvent et utilisent des sites Web et méritent d'être prises en compte avant la publication d'un site pour la première fois.

Nous verrons comment Jekyll crée les URL par défaut et montrons comment modifier le modèle d’un fichier individuel ou de l’ensemble du site. Nous verrons ensuite comment créer un lien vers des pages de notre contenu. Enfin, nous organiserons le site pour les tests.

Conditions préalables

Pour suivre ce tutoriel, vous devrez compléter les guides précédents:

Lorsque vous avez terminé, vous êtes prêt à commencer.

La structure de fichier du site statique

DansPart 2 of this series, nous avons créé un échafaudage avec la commandejekyll new et nous nous sommes concentrés sur l'apparence du site résultant dans un navigateur Web. Voyons maintenant la structure de fichier créée lors de la création du site statique par Jekyll.

[.note] #Note: Si vous avez suivi la partie 2 de cette série, vous devriez avoir le répertoire des ressources supplémentaires et la page de contact. Si vous ne l'avez pas fait ou si vous avez effectué des tests en ajoutant plus de pages, votre structure peut sembler quelque peu différente.
#

Le répertoire_site et tout le contenu en dessous, mis en évidence ci-dessous, comprennent le site statique.

Contenu de ~ / www après la partie 2

.
├── 404.html
├── about.md
├── assets
│   └── postcard.jpg
├── _config.yml
├── contact.md
├── Gemfile
├── Gemfile.lock
├── index.md
├── _posts
│   └── 2017-09-04-welcome-to-jekyll.markdown
└── _site
    ├── 404.html
    ├── about
    │   └── index.html
    ├── assets
    │   ├── main.css
    │   └── postcard.jpg
    ├── contact.html
    ├── feed.xml
    ├── index.html
    └── jekyll
        └── update
            └── 2017
                └── 09
                    └── 04
                        └── welcome-to-jekyll.html

Contrairement aux sites Web gérés par base de données, les URL d'un site Web statique sont des représentations littérales de la structure de répertoires sur disque. Jekyll a transformé les catégories de l'article en répertoires et a explosé la date dans la structure du fichier, un modèle qui est commun à de nombreux blogs, de sorte que le modèle d'URL final pour ce message est/category1/category2/YYYY/MM/DD/words-in-title.html, donc l'URL littérale esthttp://203.0.113.0:4000/jekyll/update/2017/09/04/welcome-to-jekyll.html.

L'échafaudage ne fournit pas de pages d'index dynamiques pour ces répertoires. Par conséquent, si l'utilisateur supprime une partie de l'URL pour tenter de trouver toutes les publications d'une catégorie, d'une année, d'un mois ou d'un jour particulier, l'une des deux choses suivantes se produira. Si le serveur Web autorise l’indexation automatique des répertoires, les informations relatives aux fichiers et aux répertoires sont affichées:

Directories listed

Dans le second cas, si l'administrateur du site de production désactivait les listes de répertoires sur le serveur, l'accès serait refusé à l'utilisateur:

Forbidden

La structure par catégorie et par date est un modèle courant pour les URL de blog, mais la manière dont vous décidez de structurer vos URL dépend des besoins de votre site.

Si vous souhaitez modifier la valeur par défaut, Jekyll simplifie la construction des URL. Il est utile de réfléchir à cette question avant de publier le site pour la première fois, car les modifications apportées aux modèles d'URL ont une incidence sur l'efficacité avec laquelle les utilisateurs peuvent trouver le contenu avec les moteurs de recherche et sur les liens que d'autres font vers le site.

Comprendre comment les URL sont contrôlées

Le système de création d’URL de Jekyll est à la fois flexible et puissant. Ils peuvent être influencés par l'emplacement et le mode de nommage et de stockage des fichiers source, ainsi que par leur substitution dynamique à une valeur spécifique ou à un modèle plus général.

Pages par défaut

Lorsque nous créons une page à la racine de notre site comme nous l'avons fait pour notre page de contact, le nom du fichier,contact.md est transformé encontact.html, et l'URL résultante est également juste à la racine du document: http://203.0.113.0:4000/contact.html. Si nous le plaçons dans un ou plusieurs sous-répertoires, ceux-ci feront également partie de l'URL. Par exemple, si nous plaçons la pagecontact.md dans un répertoire appelémain, l'URL deviendrahttp://203.0.113.0:4000/main/contact.html.

Post Defaults

Les messages fonctionnent différemment des pages. Tout d’abord, ils sont autorisés à avoir des catégories, et ces catégories deviennent des répertoires sur le site statique ainsi qu’une partie de l’URL. Le modèle de publication par défaut est une concaténation de son sujet principal:

title:  "Welcome to Jekyll!"
date:   2017-09-04 03:36:31 +0000
categories: jekyll update

Dans le répertoire_site, le sous-répertoire serajekyll/update/2017/09/04/welcome-to-jekyll.html, suivant le modèle/:categories/:year/:month/:day/:title et aboutissant à l'URLhttp://203.0.113.0:4000/jekyll/update/2017/09/04/welcome-to-jekyll.html.

Si nous supprimions une catégorie du sujet principal, la structure de répertoires changerait à la prochaine génération du site et ne ferait plus partie de l'URL.

Les valeurs par défaut des pages et des publications peuvent être remplacées de deux manières.

Permalinks
La définition d'un lien permanent dans le Front Matter d'une page individuelle remplacera la valeur par défaut pour les pages et les articles, nous permettant de spécifier exactement ce que nous voulons que le lien soit sur une base par fichier. Cela a été défini dans le contenu par défaut de la page À propos, où la valeur du lien permanent,/about/, a abouti à l'URLhttp://203.0.113.0:4000/about/ qui à son tour existe sur le disque en tant queabout/index.html

Permalink Patterns
Jekyll vous permet de redéfinir tout le modèle par défaut dans les_config.yml Cela affectera à la fois les pages et les articles avec une distinction importante: les articles ont accès aux catégories et aux éléments de date et d'heure à partir du Front Matter, contrairement aux pages. Les URL de page suivront le modèle, omettant gracieusement tous les éléments post-spécifiques.

Pour voir le remplacement de modèle permanent par action, nous allons créer un modèle qui conserve les catégories pour les publications, omet les éléments de date et se termine par le titre de la publication ou de la page:

nano ~/www/_config.yml

Ajoutez la valeur suivante au bas du fichier:

~/www/_config.yml

. . .
permalink: /:categories/:title/

Pour voir les modifications résultant de la modification du fichier de configuration, nous devons arrêter le serveur Web avecCTRL-C, puis le redémarrer:

jekyll serve --host=203.0.113.0

Sur le disque, la structure du fichier a changé:

├── about.md
├── assets
│   └── postcard.jpg
├── _config.yml
├── contact.md
├── css
│   └── main.scss
├── feed.xml
├── Gemfile
├── Gemfile.lock
├── index.html
├── _posts
│   ├── 2017-09-04-welcome-to-jekyll.markdown
│   └── 2017-09-04-link-test.md
└── _site
    ├── about
    │   └── index.html
    ├── assets
    │   └── postcard.jpg
    ├── contact # originally `contact.html`
    │   └── index.html
    ├── css
    │   └── main.css
    ├── feed.xml
    ├── Gemfile
    ├── Gemfile.lock
    └── index.html
    └── jekyll
        └── update
            └── welcome-to-jekyll
                └── index.html

Ces modifications dans la structure de fichier se traduisent par des modifications dans les URL. La page À propos de est toujours à/about/ car son lien permanent a été défini sur le fichier individuel depuis le début. La page Contact est passée de/contact.html à/contact/, et le message de test de lien est maintenant à/jekyll/update/welcome-to-jekyll/ en raison du changement du modèle de permalien à l'échelle du site. Vous pouvez en savoir plus sur les jetons disponibles pour la construction d'URL dans la documentation deJekyll Permalinks.

Maintenant que nous savons comment contrôler l'adresse où se trouve une page, il ne reste que peu d'éléments à prendre en compte lors de la création de liens vers ces adresses.

Si nous faisions des liens dans le corps d'une page pour un site complètement statique, nous utiliserions l'URL de la page vers laquelle nous voulions créer un lien dans l'un des formats suivants.

  • An absolute link:[Link Text]([http://203.0.113.0:4000/post-name) C'est le bon format pour un lien hors site, mais inapproprié pour notre site car conserver le numéro de port sur l'URL de base briserait nos liens en production et l'omettre les briserait sur notre site de développement.

  • A root-relative link:[Link Text(/[post-name) Les liens relatifs à la racine ne fonctionnent que pour les liens locaux, et ils suivent la structure de répertoire sur le serveur à partir de la racine Web en raison de la barre oblique initiale,/.

  • A relative link:[Link Text](post-name) Le lien relatif est également destiné aux liens locaux et commence à suivre le chemin depuis le même répertoire que la page qui contient le lien.

Les deux liens relatifs ont un problème similaire. Si nous modifions notre format de lien, nous n'aurions plus besoin de trouver tous les liens vers l'ancienne URL dans notre contenu et de les mettre à jour. Les modèles liquides de Jekyll offrent un moyen de créer un lien vers les messages plus souples. Au lieu d'utiliser un lien littéral, vous pouvez utiliser la variablepost_url avec le nom du fichier afin qu'au lieu de créer un lien comme ceci:

[Link Text](/jekyll/update/2016/09/08/welcome-to-jekyll.html)

nous lierions comme ceci:

[Link Text]({% post_url 2010-09-08-welcome-to-jekyll %})

Nous devons seulement inclure le nom du fichier, et il n’est pas nécessaire d’inclure le répertoire_posts ou l’extension du fichier. Un lien vers un message créé de cette manière continuera à fonctionner avec tous les paramètres de permalien que vous configurez.

[.note] #Note: À l'heure actuelle, cette capacité de liaison dynamique est disponible pour les articles mais pas pour les pages, bien que des plans pour les pages soient en cours.
#

Créer un nouveau poste

Nous allons créer un nouveau message pour appliquer ce que nous avons appris sur la création de liens. Ouvrez un nouveau fichier dans votre éditeur, en définissant la date dans le nom du fichier selon vos besoins.

nano ~/www/_posts/2017-09-04-link-test.md

Nous allons configurer Front Matter un peu comme dans l'exemple de post, en étant sûr que la date dans le ici correspond au nom de fichier de l'étape précédente. Assurez-vous de remplacer l'adresse IP ou le nom de domaine du siteyour et la date dans le nom de votre fichier de test de lien.

---
layout: post
date: 2017-09-04 07:00
title: Link Test
---

Welcome to my Jekyll Blog. I’m exploring how Jekyll handles links:
* [An absolute link](http://203.0.113.0:4000/about/)
* [A root relative link](/jekyll/update/welcome-to-jekyll/)
* [A Jekyll post_url link]({% post_url 2017-09-04-link-test %})

Sauvegarder et quitter. Lorsque vous revenez sur la page d'accueil, le nouveau message devrait apparaître automatiquement:
Screenshot of Homepage with new blog post visible

Suivez le lien de la page d'accueil vers le nouveau message et essayez-les. Tous les trois devraient fonctionner sur notre site de développement:

Screenshot of the new blog post

Le lien absolu fonctionnera sur notre site de développement, mais il se rompra lorsque nous nous déploierons sur un site avec une URL différente ou sans le numéro de port. Le lien relatif à la racine fonctionnera à un nouvel emplacement tant que le schéma de permalien restera le même. Toutefois, si une modification est apportée, ce lien ne sera pas mis à jour et il ne fonctionnera plus sur aucun des sites. Le lien Jekyllpost_url créera un lien relatif à la racine lorsque le site sera analysé. Non seulement cela fonctionnera-t-il n'importe où, mais Jekyll veillera également à ce que le message auquel vous créez un lien existe réellement lorsqu'il analyse le site. Si ce n’est pas le cas, une «Exception liquide» vous indiquera quel fichier contenait le mauvais lien et quel lien était le problème. Par exemple, si nous avons saisi par erreur un nom de fichier incorrect sur le troisième lien:

Liquid Exception: Could not find post
"broken-name-welcome-to-jekyll" in tag 'post_url'.
Make sure the post exists and the name is correct.
in /home/sammy/www/_posts/2017-09-04-link-test.md
                ERROR: YOUR SITE COULD NOT BE BUILT:
               ------------------------------------

Ceci est la dernière modification apportée au contenu du site. Dans la prochaine étape, nous allons copier notre site dans un nouvel emplacement afin de pouvoir tester notre travail.

La pageDeployment methodsde Jekyll couvre une variété de façons de déplacer votre contenu vers son emplacement de production en fonction de vos besoins. Cela inclut n'importe quoi, du FTP aux méthodes automatisées sophistiquées. Pour le moment, nous allons configurer un site intermédiaire sur le même ordinateur pour illustrer le comportement des liens.

Créer un site de test

Nous allons installer Nginx afin de pouvoir tester le fonctionnement de notre liaison avant de le déployer en production:

sudo apt-get install nginx

Une fois l’installation terminée, nous autoriserons le trafic HTTP.

sudo ufw allow http

Lorsque nous visitons l'adresse de la machine de développement, nous devrions voir:

Screenshot of the default nginx web page

Comme nous sommes sur le même système de fichiers, nous allons déplacer le site avec une commande de basersync.

Pour obtenir le contenu de_site dans la racine du document Nginx, situé à/var/www/html, nous utiliserons la commande suivante avec-a pour synchroniser de manière récursive et préserver presque tout et l'option-v pour fournir une sortie verbeuse:

sudo rsync -av ~/www/_site/ /var/www/html/

Une fois la rsync terminée, nous pouvons visiter notre site, servi par Nginx, sans le numéro de porthttp://203.0.113.0 et nous assurer que vous avez quitté votre serveur Web de développement avant de tester.

Test du site

Tester après un déploiement sur un nouvel emplacement nous permet de nous assurer que nos lecteurs possèdent l'expérience recherchée. La vérification automatique des liens peut aider à en faire une partie facile et routinière du processus, mais pour le moment, nous allons l'examiner à la main.

La nouvelle publication de blog apparaît automatiquement sur la page d'accueil, avec le plus récent en haut.

Screenshot of the Link Test post on the staging site

Lorsque nous visiterons la publication «Link Test», nous verrons que le lien absolu et le lien relatif à la racine sont rompus, car l’environnement dans lequel nous avons déployé n’utilise pas le port 4000, alors que le lien Jekyll post_url fonctionne aux deux emplacements.

Nous avons terminé les tests, nous allons donc fermernginx et fermer le port 80 car nous n'avons pas l'intention de servir le site:

sudo systemctl stop nginx
sudo ufw delete allow http

Nous avons terminé notre exploration des liens et des URL. Nous allons donc également quitter le serveur de développement avecCTRL+C.

Si nous combinons des noms de page stables et soigneusement choisis avec des liens vers des articles à l'aide de la balisepost_url, nous ne devrions pas avoir trop de soucis lors de la création de liens vers nos propres pages. Tester dans un nouvel emplacement avant de le mettre en production reste utile pour détecter nos propres erreurs, et plus encore pour rechercher des liens rompus vers des sites externes.

Conclusion

Dans cette série, nous avons installé et configuré un site de développement. Dans ce tutoriel, nous avons examiné comment contrôler l’adresse Web des pages et des publications sur notre site, remplacer les modèles par défaut, créer des liens solides vers des publications au sein de notre contenu et déployer le site à des fins de test. Vous voudrez peut-être en savoir plus sur la personnalisation destemplates et destheme de votre site ou sur la façon de personnaliser lesdeploy your site to its production location.