Сторінки GitHub та відносні шляхи

77

Я створив gh-pagesвідділення для проекту, над яким працюю в GitHub.

Я використовую Sublime text для створення веб-сайту локально, і моя проблема полягає в тому, що коли це перенесено на GitHub, всі посилання на javascrips, зображення та файли css недійсні.

Наприклад, у мене це є в моїй голові.

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

Це чудово працює локально, але це не працює від GitHub, оскільки посилання не вирішуються за допомогою імені сховища як частини URL-адреси.

Він просить: 

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

коли воно мало просити: 

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

Звичайно, я міг би вказати ім'я репозиторію як частину URL-адреси, але це заважало б моєму сайту працювати локально під час розробки.

Будь-яка ідея, як з цим боротися?

html  github 
— дихатель
джерело
1
Це трапляється зі мною. Вам вдалося з’ясувати причину цього?
— Андрій Михайлов - lolmaus
1
Примітка: у грудні 2016 року сторінки GitHub значно змінилися. Дивіться мою відповідь нижче
— VonC

Відповіді:

13

Який браузер ви використовуєте? Ви впевнені, що це відбувається? Бо не повинно. Якщо ви включите відносну URL-адресу у посилання, вона буде вирішена щодо URL-адреси документа, що містить посилання. Іншими словами, коли ви включаєте

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

в HTML-документі на http://www.foo.com/bar/doc.html, посилання на assets/css/common.cssбуде вирішено шляхом додавання його до префіксу URL-адреси HTML-документа без останньої частини шляху (без doc.html), тобто посилання буде вирішувати на http://www.foo.com/bar/assets/css/common.css, а не на те, http://www.foo.com/assets/css/common.cssяк ви заявляєте.

Наприклад, перегляньте джерело веб-сторінки Twitter Bootstrap: http://twitter.github.io/bootstrap/ . Зверніть увагу на посилання на стиль вгорі, вказані як <link href="assets/css/bootstrap.css" rel="stylesheet">. Це посилання правильно вирішує http://twitter.github.io/bootstrap/assets/css/bootstrap.css, тобто воно містить ім'я репо.

— Іван Зузак
джерело
3
як ти поводишся href="https://stackoverflow.com/"?
— Акабаб
73

Вам потрібно буде використовувати Jekyll .

Дослівне копіювання з відповідної документації :

Іноді приємно попередньо переглянути свій сайт Jekyll, перш ніж перенести вашу gh-pagesгілку на GitHub. Однак структура URL-адрес, схожа на підкаталог, яку GitHub використовує для Project Pages, ускладнює правильне розрішення URL-адрес. Ось підхід до використання структури URL-адреси сторінки проекту GitHub ( username.github.io/project-name/), зберігаючи при цьому можливість попереднього перегляду сайту Jekyll локально.

  1. В _config.yml, встановіть baseurlопцію /project-name- примітка провідний слеш і відсутність слеш.

  2. Посилаючись на файли JS або CSS, робіть це так: {{ site.baseurl}}/path/to/css.css- зверніть увагу на скісну риску, яка слідує за змінною (безпосередньо перед “path”).

  3. Роблячи постійні посилання або внутрішні посилання, робіть це так: {{ site.baseurl }}{{ post.url }}- зауважте, що між цими двома змінними немає косої риски.

  4. Нарешті, якщо ви хочете переглянути свій сайт перед фіксацією / розгортанням за допомогою jekyll serve, не забудьте передати пустий рядок --baseurlпараметру, щоб ви могли переглядати все в localhost:4000звичайному режимі (без / назва проекту на початку): jekyll serve --baseurl ''

Таким чином, ви можете попередньо переглянути свій сайт локально з кореня сайту на localhost, але коли GitHub генерує ваші сторінки з gh-pages гілки, всі URL-адреси починатимуться /project-nameі правильно визначатись .

(Мабуть, хтось це зрозумів лише кілька місяців тому .)

— Анубхав С
джерело
4
Так, це має бути прийнятою відповіддю. Здається, це трохи заплутано для звичайного випадку використання Jekyll - цікаво, чи є причина, за якою вони не використовують site.baseurl за замовчуванням?
— Кевін Ці
4
Хоча це кілька років і документація змінилася, це рішення працювало для мене над тим, що було рекомендовано в документах про використання Джекіла{{ site.github.url }}
— Кайл Шевлін,
8

Ви можете просто поставити це

<base href="/[repo]/">

всередині <head>тегу, і це вирішує проблему.

Ви також можете вдосконалити це рішення, встановивши:

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

а потім встановіть site.baseurlпорожній рядок для локального тестування.

— Аффільність
джерело
Якщо ви не хочете обдурювати Джекіла і все таке, це найкраще рішення
— Pro Q
5

Це вже не повинно бути проблемою у грудні 2016 року, через 3 з половиною роки.
Див. " Відносні посилання на сторінки GitHub ", опубліковані Беном Балтером :

Ви вже деякий час могли використовувати відносні посилання під час створення Markdown на GitHub.com .

(тобто з січня 2013 року)

Тепер ці посилання продовжуватимуть працювати, коли будуть опубліковані на Сторінках GitHub .

Якщо у вас є файл Markdown у вашому сховищі за адресою docs/page.md, і ви хочете зробити з нього посилання docs/another-page.md, ви можете зробити це за допомогою такої розмітки:

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

Коли ви переглядаєте вихідний файл на GitHub.com, відносне посилання буде продовжувати працювати, як і раніше, але тепер, коли ви публікуєте цей файл на сторінках GitHub, посилання буде мовчки перекладено docs/another-page.html щоб відповідати опублікованій URL-адресі цільової сторінки .

Під капотом ми використовуємо плагін Jekyll Relative Links з відкритим кодом , який за замовчуванням активовано для всіх збірок.

Відносні посилання на Сторінках GitHub також беруть до уваги власні постійні посилання (наприклад, permalink: /docs/page/) у передній частині файлу YAML файлу, а також додають базову URL-адресу сторінок проекту за необхідності, гарантуючи, що посилання продовжують працювати в будь-якому контексті.

І не забувайте, що з серпня 2016 року ви можете публікувати свої сторінки безпосередньо у masterвідділенні (не завжди у gh-pagesвідділенні)

А з грудня 2016 року вам навіть не потрібно Jekyllабо index.md. Досить простих файлів розмітки.

— VonC
джерело
У вашій відповіді є багато корисної інформації - дякую. Але, прочитавши всі зв’язані статті, я не можу зрозуміти, чому відносні посилання html tableв моєму файлі .md не перетворюються на .html під час процесу сторінок github. Тобто всередині мого .md-файлу знаходиться таблиця html, що містить відносні посилання на інші .md-файли в моєму репо. Таблиця правильно відображається на github.com, але на сторінках github відносні посилання залишаються як .md-файли. Чому?
— Шеймус,
@Seamus Я ніколи не бачив такого перетворення в елементах html (наприклад, таблиці). Я припустив, що відносне посилання було перетворено лише при використанні чистої сторінки розмітки, а не в поєднанні елементів розмітки та HTML.
— VonC
Мабуть, це так. Але, здається, я змушений вибирати між потворною однобічною таблицею та посиланнями, які неправильно перетворені. Будь-які пропозиції / відповіді ?
— Шеймус
4

Здається, Github Pages не дуже чуйний. Хоча це робить нові файли доступними одразу, змінені файли не з’являться одразу через кешування або щось інше.

Зачекавши 15 хвилин або близько того, все добре.

— Андрій Михайлов - lolmaus
джерело
Це було і для мене
— Джейк
@ AndreyMikhaylov-lolmaus: Здається, голоси прихильників теж не дуже чуйні :)
— Шеймус,
0

Інший варіант - створити нове репо для веб-сторінок github.io. Якщо ви називаєте репо як [user].github.iogithub, тоді воно буде опубліковане за адресою, https://[user].github.ioі ви можете уникнути повного імені репо в URL-адресі . Очевидно, що мінус полягає в тому, що ви можете мати лише 1 репо, подібне до цього, на кожного користувача github, тому воно може не відповідати вашим потребам, я не впевнений.

— Мюльхаузен
джерело
Я можу лише припустити, що виборець відчув, що ваша відповідь не стосується питання. Однак я знайшов це корисним, тому +1!
— Шеймус,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.