We use Jekyll 4.2.0 to generate a static HTML site that we serve using jekyll serve for debug purposes. On my machine (Arch Linux), this works correctly but on my colleagues machines (Arch Linux and Mac OS), Jekyll incorrectly generates absolute paths, so that for example image links on the local site point to e.g. https://ourdomain//public/image.png instead of http://localhost:4000//public/image.png.
The links are defined as e.g. {{site.url}}{{ site.baseurl}}/public/img.png
How can I get Jekyll to keep local paths intact on my colleagues machine?
Solution
The problem was solved by #Kin but I had to perform two modifications
Use single quotes for the image path, else it conflicts with the outer double quotes.
Use relative_url instead of relative.
The end result is <img src="{{ '/public/img.png' | relative_url }}">.
Why it worked differently on different machines
Equal behavior was achieved by deleting the _site folder before calling jekyll serve --incremental, as the relative paths were used before and jekyll serve seems to only update some parts of the site.
Then, the original {{site.url}}{{ site.baseurl}}/public/img.png actually specifies an absolute path in any circumstance, as site.url seems to take the hardcoded url attribute from _config.yml instead of magically setting this value to the deployed webpages local URI as I expected.
The reason I used site.url and site.baseurl at first was that I also deployed into a subfolder of a domain using github pages but that use case is covered by relative_url as well.
Update with OP's solution
The problem was solved by using relative_url on the images [2]
[2] https://jekyllrb.com/docs/liquid/filters/
Original Post
In my past Jekyll project[1], we were able to use jekyll serve on various platforms without issues. It is possible we avoided the issue you are seeing by used relative [1] on all of our image URLs. Here is an example
<img id="myImage" src="{{ "/img/myImage.png" | relative }}" alt="My Image">
I haven't tried recreating your issue, so I cannot confirm if relative is what kept our Jekyll project cross platform compatible.
[1] https://github.com/OpenLiberty/openliberty.io
Related
I've a Jekyll site that I'm developing locally with jekyll serve and I'm editing a post in the _posts directory and I'm storing images in a _pics directory.
I'm trying to reference the image inline with all sorts of things...
../_pics/image.png
/_pics/image.png
{{ site.url }}/_pics/image.png
{{ site.url }}_pics/image.png
The last two really don't work, because when I inspect it, it's of course referencing my github URL, which makes no sense if I'm trying to develop locally first.
What's the right way to handle this if I want to develop locally and not have the images not break when they get pushed up to GitHub?
I noticed that changing the _pics folder to pics with no underscore fixed it...Not sure why that is though. There may be a special meaning for underscore prepended folders with Jekyll?
_pics and generally all folder beginning with underscore are ignored by jekyll.
You can instruct jekyll to process a specific "underscored" folder by adding this folder in the include configuration array.
In _config.yml, add :
include :
- _pics
i have been trying to create jekyll site and host on git-pages. Localy everything works fine. But on github-pages works only first pages and 10 newest blog post.
But after going to any of other pages like "Blogas" or "Straipniai" every link starts with 'localhost:4000' and naturaly breaks css, javascript...
And i am not sure where is problem, because everything is same even if i make change in /_includes/header.html site.url to site.baseurl.
Here is git-hub
And site
I think the problem is that you somehow have both a .md and an .html version of the same pages. The .html version you built locally and GH is preferring it. it has localhost in the urls so it won't work. Try deleting the .html files in those sub folders and see what happens. For example, delete the index.html file from invisibleghostt.github.io/blogas/ and see if that page is fixed.
No idea how you got those files in there, they should not be there.
Look, there are a few things you'd better fix on your _config.yml:
url: "http://codas.lt" # add the site url
gems: # remove `jekyll` from gems
- jekyll-sitemap
- jekyll-gist
- octopress
include: [".htaccess"] # remove this line (GitHub Pages does not support .htaccess)
The other thing is, you'll need to remove all the folders from the folder _posts, as explained here:
If you organized your categories as
/_posts/code/2008-12-24-closures.md, you will need to restructure your
directories to put the categories above the _posts directories, as
follows: /code/_posts/2008-12-24-closures.md.
You are probably working locally with a Jekyll version which diverges from GitHub Pages' (currently is Jekyll 3.0.3). That's why your site works locally and doesn't work there. To avoid that, build Jekyll with Bundler (a dependency manager). On this answer you can see how to do that, step-by-step.
Hope to have helped! :)
Note: If you get stuck in how to adapt your theme to work with GitHub Pages, you can try GitLab Pages, as you can easily set the Jekyll version you want to use to build your site. For example, this project builds the site with Jekyll 2.5.3.
I am creating a blog on Jekyll for the first time and I am at the point where I'm trying to deploy what I have so far to github pages. When I serve the site and view it locally, it looks fine - so I thought that all I had to do was push all of the files to a gh-pages branch. Now that I have done this, all that is showing is the HTML.
To troubleshoot, I downloaded just the template files and pushed those to a Github page to see if the issue had to do with how I was editing the CSS, but when I did that I got the same results.
I came across an article that was specifically about how to use github pages to store a jekyll site, and it said to remove the slash before the css folder in the linked stylesheets on the HTML if your page isn't styled correctly. After reading that I thought that the slash was for sure the issue, but after removing the slash... I got the same result.
I have been trying for hours and I feel like its probably something very simple(such as the slash).
Here is the repo:
https://github.com/pacalabre/blog-site/tree/gh-pages
Here is the output:
http://pacalabre.github.io/blog-site/
Thank you in advance for any answers!
You need to add/edit:
baseurl: /blog-site
to the config file. Note there is no trailing slash. 'blog-site' is the name of your project, the project name becomes a sub directory that serves your site. Without the baseurl setting, your relative urls are trying to fetch things from http://pacalabre.github.io/ when they are really at http://pacalabre.github.io/blog-site/.
GH is serving your site as a subfolder to the domain and your references are not taking that into account.
Once you add the baseurl setting, you then need to add {{site.baseurl}} in front of your assets like images, css and js.
Also, once you do the baseurl setting, when you serve locally it will not be quite correct, you will need to add the /blog-site to the end of the localhost url for it to work properly.
You also should try using the dev tools inspector in Chrome to help you troubleshoot, it will clearly tell you right now that it cannot load all your js files or images, and it will show where it is trying to load them from.
Look, there's something wrong with your site/repo.
I didn't find your _config.yml at the site root ( gh-pages branch). It should be there.
There's a binary file there (probably Mac's file if I'm not mistaken). It shouldn't be there.
There are both Jekyll's folders (_posts, _drafts, _layouts, etc) and _site folder there. You need to choose. Or you upload the _site content (not the folder itself) or you upload the Jekyll project. Usually you upload just Jekyll folders and GH build the site for you, unless you use some plugins which are not allowed by GitHub. In this case, you upload just the _site content, which is the compiled site (html, CSS, js only).
On the previous answer, you were instructed to add a baseurl to your site configuration. It's the best approach, but if your template uses just url and doesn't even mention baseurl, the best way is adding the project name to the end of the url, not searching for every link to call {{ site.baseurl }} via liquid. So, instead of giving yourself all this trouble, better do like that in your _config.yml:
url: http://username.github.io/projectname
If you indeed go for setting up the baseurl, you can view your site locally via localhost:4000 by adding this flag when serving Jekyll: --baseurl "". So, jekyll serve --watch --baseurl "". This means like "Jekyll, ignore the baseurl set in the config". Got it?
Serving Jekyll with bundler is the right way to do that, specially when deploying to GH Pages. But this is another story, I can add a comment later if you're interested.
Suggestions. Read a little more about how Jekyll works. Also look for .gitignore so you won't upload to GH anything unnecessary (like that binary file).
After that, if your site doesn't build or display correctly, let me know and I'll help you out if you want.
Hope to have helped!
I'd like to use Jekyll to share a page that cannot be served anywhere. I need to share this information using sync clients (Dropbox, Google Drive, WorkDocs, etc) and i'd like the links on the pages to work, regardless of the path where they are synced.
When i generate a new jekykll site with jekyll new somesite, then build with jekyll build, then open index.html from the filesystem, the links are broken because they are absolute.
For example, the href to the sample "Welcome to Jekyll" is generated as "/jekyll/update/2015/09/12/welcome-to-jekyll.html" and thus opens to "file:///jekyll/update/2015/09/12/welcome-to-jekyll.html" on my browser.
If it would generate us relative links, such as "jekyll/update/2015/09/12/welcome-to-jekyll.html", they would open fine regardless of the system or path they are opened from.
Would it be possible to change jekyll to use relative links instad of the default absolute links?
A fast and dirty way
If your page is in the root of the website (e.g. index.html), you could create relative links to posts using liquid filters, e.g.:
{% for post in site.posts %}
{{post.title}}
{% endfor %}
But, if you want relative links from every possible page in you site, I think that the only solution is to write a custom liquid filter that generate a relative link considering the current page location and the link location.
A clean way
Another (and more clean) way could be to use different _config.yml files for every destination. Here you can config each host and permalink structure to match the destination.
E.g. to serve your jekyll blog from http://example.com/my/subdir/blog:
# _config-example-com.yml
host: example.com
permalink: /my/subdir/blog/:year/:month/:title
Then build your blog using:
jekyll build --config _config-example-com.yml
If you have X targets, you could use a script to run jekyll X times (using every time a different config file) and then copy every output from _site to another directory, or upload directly where you want.
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 when this is pushed to GitHub, all the links to javascrips, images, and css files are invalid.
For instance, I have this in my head section.
<link href="assets/css/common.css" rel="stylesheet">
This works great locally, but it does not work from GitHub as the links are not resolved using the repository name as part of the URL.
It asks for:
http://[user].github.io/assets/css/common.css
when it should have been asking for:
http://[user].github.io/[repo]/assets/css/common.css.
I could of course put the repo name as part of the URL, but that would prevent my site to work locally during development.
Any idea how to deal with this?
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.
In _config.yml, set the baseurl option to /project-name – note the leading slash and the absence of a trailing slash.
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”).
When doing permalinks or internal links, do it like this: {{ site.baseurl }}{{ post.url }} – note that there is no slash between
the two variables.
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.)
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.
You could just put this
<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.
This should not be an issue anymore in Dec. 2016, 3 and an half years later.
See "Relative links for GitHub pages", published by Ben Balter:
You've been able to use relative links when authoring Markdown on GitHub.com for a while.
(that is from January 2013)
Now, those links will continue to work when published via GitHub Pages.
If you have a Markdown file in your repository at docs/page.md, and you want to link from that file to docs/another-page.md, you can do so with the following markup:
[a relative link](another-page.md)
When you view the source file on GitHub.com, the relative link will continue to work, as it has before, but now, when you publish that file using GitHub Pages, the link will be silently translated to docs/another-page.html to match the target page's published URL.
Under the hood, we're using the open source Jekyll Relative Links plugin, which is activated by default for all builds.
Relative links on GitHub Pages also take into account custom permalinks (e.g., permalink: /docs/page/) in a file's YAML front matter, as well as prepend project pages' base URL as appropriate, ensuring links continue to work in any context.
And don't forget that since August 2016, you can publish your pages right from the master branch (not always the gh-pages branch)
And since Dec. 2016, you don't even need Jekyll or index.md. Simple markdown files are enough.
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.
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.
The best option is now the relative_url filter:
<link href="{{ '/assets/css/common.css' | relative_url }}" rel="stylesheet">