Страницы 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">