Страницы GitHub и относительные пути

Я создал ветку gh-pages для проекта, над которым я работаю в GitHub.

Я использую Sublime-текст для локального создания веб-сайта, и моя проблема в том, что при нажатии на GitHub все ссылки на javascrips, images и 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-адреса, но это помешало бы моему сайту работать локально во время разработки.

Любая идея, как с этим справиться?

Ответ 1

Какой браузер вы используете? Вы уверены, что это произойдет? Потому что это не должно. Если вы укажете относительный 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, то есть включает имя репо.

Ответ 2

Вам нужно использовать Jekyll.

Копирование дословно из соответствующей документации:

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

  • В _config.yml установите для параметра baseurl значение /project-name - отметьте начальную косую черту и отсутствие конечной косой черты.

  • При обращении к файлам JS или CSS сделайте это так: {{ site.baseurl}}/path/to/css.css - обратите внимание на косую черту сразу после переменная (непосредственно перед "дорожкой" ).

  • При выполнении постоянных ссылок или внутренних ссылок сделайте это так: {{ site.baseurl }}{{ post.url }} - обратите внимание, что нет косой черты между две переменные.

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

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

(По-видимому, кто-то понял это всего несколько месяцев назад.)

Ответ 3

Это не должно быть проблемой больше в декабре 2016 года, через три с половиной года.
См. " Относительные ссылки для страниц GitHub ", опубликованные Бен Балтером:

Вы могли использовать относительные ссылки при создании Markdown на GitHub.com некоторое время.

(то есть с января 2013 года)

Теперь эти ссылки будут продолжать работать при публикации через GitHub Pages.

Если у вас есть файл Markdown в вашем репозитории на docs/page.md, и вы хотите связать его с docs/another-page.md, вы можете сделать это со следующей разметкой:

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

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

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

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

И не забывайте, что с августа 2016 года вы можете публиковать свои страницы прямо из master ветки (не всегда ветки gh-pages)

А с декабря 2016 года вам даже не нужны Jekyll или index.md. Простых файлов разметки достаточно.

Ответ 4

Вы могли бы просто положить

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

внутри <head>, и он решает проблему.

Вы также можете улучшить это решение, установив:

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

а затем установите site.baseurl в пустую строку для локального тестирования.

Ответ 5

Кажется, что Github Pages не очень отзывчива. Хотя это делает новые файлы доступными немедленно, измененные файлы не появятся сразу из-за кеширования или чего-то еще.

Ожидая 15 минут или около того, все в порядке.

Ответ 6

Другой вариант - создать новое репо специально для веб-страниц github.io. Если вы назовете репо как [user].github.io на github, то он будет опубликован в https://[user].github.io, и вы можете избегать полного имени репо в URL-адресе. Очевидно, недостатком является то, что у вас может быть только 1 репо, как у каждого пользователя github, поэтому он может не соответствовать вашим потребностям, я не уверен.

Ответ 7

Лучшим вариантом является теперь фильтр relative_url:

<link href="{{ '/assets/css/common.css' | relative_url }}" rel="stylesheet">