100 votes

Pages GitHub et chemins relatifs

J'ai créé un gh-pages pour un projet sur lequel je travaille sur GitHub.

J'utilise Sublime text pour créer le site web localement et mon problème est que lorsque le site est envoyé sur GitHub, tous les liens vers les javascripts, les images et les fichiers css sont invalides.

Par exemple, j'ai ceci dans ma section tête.

<link href="assets/css/common.css" rel="stylesheet">

Cela fonctionne très bien localement, mais pas à partir de GitHub, car les liens ne sont pas résolus en utilisant le nom du dépôt dans l'URL.

Il demande :

http://[user].github.io/assets/css/common.css

alors qu'elle aurait dû le demander :

http://[user].github.io/[repo]/assets/css/common.css.

Je pourrais bien sûr mettre le nom du dépôt dans l'URL, mais cela empêcherait mon site de fonctionner en local pendant le développement.

Une idée sur la façon de traiter ce problème ?

82voto

Anubhav C Points 2491

Vous devrez utiliser Jekyll .

Copie mot à mot du documentation pertinente :

Il est parfois agréable de prévisualiser son site Jekyll. gh-pages sur GitHub. Cependant, l'URL de type sous-répertoire de type sous-répertoire que GitHub utilise pour les pages de projet complique la bonne résolution des URLs. Voici une approche pour utiliser la structure URL des pages de projet de GitHub pour les pages de projet ( username.github.io/project-name/ ) tandis que tout en conservant la possibilité de prévisualiser votre site Jekyll en local.

  1. Sur _config.yml fixer le baseurl option pour /project-name - Notez la barre oblique de tête et l'absence de barre oblique de queue.

  2. Lorsque vous faites référence à des fichiers JS ou CSS, procédez comme suit : {{ site.baseurl}}/path/to/css.css - Notez la barre oblique qui suit immédiatement la variable (juste avant "path").

  3. Lorsque vous créez des permaliens ou des liens internes, procédez comme suit : {{ site.baseurl }}{{ post.url }} - Notez qu'il n'y a pas de barre oblique entre les deux variables.

  4. Enfin, si vous souhaitez prévisualiser votre site avant de le valider ou de le déployer en utilisant la fonction jekyll serve assurez-vous de passer une chaîne vide vide à la --baseurl afin que vous puissiez localhost:4000 normalement (sans /projec jekyll serve --baseurl ''

De cette façon, vous pouvez prévenir localhost, mais lorsque GitHub génère vos pages à partir de la racine du site, vous pouvez les prévisualiser. gh-pages branche toutes les URLs commenceront par /project-name et résoudre correctement.

(Apparemment, quelqu'un a compris que il y a seulement quelques mois .)

14voto

Ivan Zuzak Points 4083

Quel navigateur utilisez-vous ? Êtes-vous sûr que cela se produit ? Parce que ça ne devrait pas. Si vous incluez une URL relative dans un lien, elle sera résolue par rapport à l'URL du document qui contient le lien. En d'autres termes, lorsque vous incluez

<link href="assets/css/common.css" rel="stylesheet">

dans un document HTML à http://www.foo.com/bar/doc.html le lien vers assets/css/common.css sera résolu en l'ajoutant au préfixe de l'URL du document HTML sans la dernière partie du chemin d'accès (sans doc.html ), c'est-à-dire que le lien se résoudra en http://www.foo.com/bar/assets/css/common.css et non à http://www.foo.com/assets/css/common.css comme vous le prétendez.

Par exemple, consultez la source de la page Web Twitter Bootstrap : http://twitter.github.io/bootstrap/ . Remarquez les liens de style en haut, spécifiés comme suit <link href="assets/css/bootstrap.css" rel="stylesheet"> . Ce lien se résout correctement en http://twitter.github.io/bootstrap/assets/css/bootstrap.css c'est-à-dire qu'il inclut le nom du repo.

12voto

Affilnost Points 189

Vous pourriez simplement mettre ceci

<base href="http://stackoverflow.com/[repo]/">

à l'intérieur de la <head> et cela résout le problème.

Vous pourriez également améliorer cette solution en définissant :

<base href="{{site.baseurl}}" />

et ensuite mettre site.baseurl à une chaîne vide pour le test local.

5voto

VonC Points 414372

Cela ne devrait plus être un problème en décembre 2016, soit 3 ans et demi plus tard.
Voir " Liens relatifs pour les pages GitHub ", publié par Ben Balter :

Vous avez pu utiliser des liens relatifs lors de la création de documents Markdown. sur GitHub.com pendant un certain temps .

(c'est-à-dire à partir de janvier 2013)

Désormais, ces liens continueront de fonctionner lorsqu'ils seront publiés par l'intermédiaire du site Web de la Commission européenne. Pages GitHub .

Si vous avez un fichier Markdown dans votre dépôt à l'adresse suivante docs/page.md et vous voulez créer un lien de ce fichier vers docs/another-page.md vous pouvez le faire avec le balisage suivant :

[a relative link](another-page.md)

Lorsque vous visualisez le fichier source sur GitHub.com, le lien relatif continue de fonctionner, comme auparavant, mais désormais, lorsque vous publiez ce fichier à l'aide des pages GitHub, le lien sera traduit de manière silencieuse en docs/another-page.html pour correspondre à l'URL publiée de la page cible.

Sous le capot, nous utilisons l'open source Liens relatifs à Jekyll qui est activé par défaut pour tous les builds.

Les liens relatifs sur les pages GitHub prennent également en compte les permaliens personnalisés (par ex, permalink: /docs/page/ ) dans le fronton YAML d'un fichier, ainsi qu'à l'URL de base des pages du projet, afin de garantir que les liens continuent de fonctionner dans n'importe quel contexte.

Et n'oubliez pas que depuis août 2016, vous pouvez publier vos pages directement à partir de l'application master branche (pas toujours le gh-pages branche)

Et comme Déc. 2016 vous n'avez même pas besoin Jekyll o index.md . De simples fichiers markdown suffisent.

4voto

Il semble que les pages Github ne soient pas très réactives. Bien qu'elles rendent les nouveaux fichiers disponibles immédiatement, les fichiers modifiés n'apparaissent pas immédiatement à cause de la mise en cache ou autre.

Après une quinzaine de minutes d'attente, tout va bien.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X