发表新帖
发表新帖

GitHub pages and relative paths

前端 未结
关注
7 1148
梦如初夏
梦如初夏 2020-11-30 22:40

I have created a gh-pages branch for a project that I am working on at GitHub.

I use Sublime text to author the website locally and my problem is that w

相关标签:
7条回答
  • 情话喂你
    2020-11-30 23:18

    The best option is now the relative_url filter:

    <link href="{{ '/assets/css/common.css' | relative_url }}" rel="stylesheet">
    0 讨论(0)
  • 南方客
    2020-11-30 23:27

    It seems that Github Pages is not very responsive. Though it makes new files available immediately, modified files would not appear immediately due to caching or something.

    After waiting 15 minutes or so, everything is fine.

    0 讨论(0)
  • 天命终不由人
    2020-11-30 23:29

    Another option is to create a new repo specifically for the github.io webpages. If you name the repo as [user].github.io on github then it will be published at https://[user].github.io and you can avoid having the repo name in the URL path completely. Obviously the downside is that you can only have 1 repo like this per github user, so it may not suit your needs, I'm not sure.

    0 讨论(0)
  • 情话喂你
    2020-11-30 23:36

    You could just put

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

    inside of the <head> tag, and it solves the problem.

    You could also improve this solution by setting:

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

    and then set site.baseurl to empty string for the local testing.

    0 讨论(0)
  • 既然无缘
    2020-11-30 23:37

    You'll need to use Jekyll.

    Copying verbatim from the relevant documentation:

    Sometimes it’s nice to preview your Jekyll site before you push your gh-pages branch to GitHub. However, the subdirectory-like URL structure GitHub uses for Project Pages complicates the proper resolution of URLs. Here is an approach to utilizing the GitHub Project Page URL structure (username.github.io/project-name/) whilst maintaining the ability to preview your Jekyll site locally.

    1. In _config.yml, set the baseurl option to /project-name – note the leading slash and the absence of a trailing slash.

    2. When referencing JS or CSS files, do it like this: {{ site.baseurl}}/path/to/css.css – note the slash immediately following the variable (just before “path”).

    3. When doing permalinks or internal links, do it like this: {{ site.baseurl }}{{ post.url }} – note that there is no slash between the two variables.

    4. Finally, if you’d like to preview your site before committing/deploying using jekyll serve, be sure to pass an empty string to the --baseurl option, so that you can view everything at localhost:4000 normally (without /project-name at the beginning): jekyll serve --baseurl ''

    This way you can preview your site locally from the site root on localhost, but when GitHub generates your pages from the gh-pages branch all the URLs will start with /project-name and resolve properly.

    (Apparently someone figured this out only a few months ago.)

    0 讨论(0)
  • 时光说笑
    2020-11-30 23:41

    Which browser are you using? Are you sure that this happens? Because it shouldn't. If you include a relative URL in a link, it will get resolved relative to the URL of the document that contains the link. In other words, when you include 

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

    in an HTML document at http://www.foo.com/bar/doc.html, the link to assets/css/common.css will get resolved by appending it to the prefix of the URL of the HTML document without the last part of the path (without doc.html), i.e. the link will resolve to http://www.foo.com/bar/assets/css/common.css, not to http://www.foo.com/assets/css/common.css as you claim.

    For example, view the source of the Twitter Bootstrap webpage: http://twitter.github.io/bootstrap/. Notice the style links at the top, specified as <link href="assets/css/bootstrap.css" rel="stylesheet">. That link correctly resolves to http://twitter.github.io/bootstrap/assets/css/bootstrap.css, i.e. it does include the repo name.

    0 讨论(0)
 看不清?
提交回复
热议问题