2013-05-01 4 views
42

Я создал ветку gh-pages для проекта, над которым я работаю в GitHub.Страницы 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, но это помешало бы мой сайт работать на месте во время разработки.

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

+0

такой же сомнения здесь. – diofeher

+0

Это происходит со мной. Вам удалось выяснить причину этого? –

+0

Примечание: в декабре 2016 года страницы GitHub значительно изменились. См. [Мой ответ ниже] (http://stackoverflow.com/a/41127983/6309) – VonC

ответ

5

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

-1

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

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

51

Вам необходимо будет use Jekyll.

Копирование дословно из relevant documentation:

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

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

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

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

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

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

(Видимо кто-то понял это only a few months ago.)

+3

Да, это должен быть принятый ответ. Кажется немного запутанным для общего использования Jekyll - интересно, есть ли причина, по которой они не используют site.baseurl по умолчанию? –

+2

Хотя это несколько лет, и документация изменилась, это решение сработало для меня над тем, что было рекомендовано в документах Jekyll по использованию '{{site.github.url}}' –

4

Это не должно быть проблемой больше в декабре 2016 года, 3 и полтора года спустя.
См "Relative links for GitHub pages", опубликованные Ben Balter:

Вы были в состоянии использовать относительные ссылки, когда авторинга Markdown on GitHub.com for a while.

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

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

Если у вас есть файл 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-адрес исходных страниц проекта, чтобы ссылки продолжали работать в любом контексте.

И не забывайте, что since August 2016, you can publish your pages right from the master branch (не всегда gh-pages филиал)

И так Dec. 2016, вам не нужно даже Jekyll или index.md. Simple markdown files are enough.

0

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

Смежные вопросы