Hi there,
I’m a little new to ipfs, but loving the idea so far and playing around with different experiments.
One experiment is to publish my personal jekyll blog via ipfs instead of github pages.
I started with ipfs add -r _site and it sort of worked. The main content appears. But most of the links are broken including all the links to the assets.
For instance any links set relative to the root of the site like /about don’t work because this takes the browser to localhost:5001 rather than localhost:5001/ipfs//about.
Maybe it is just as simple as only using relative links, but I’d generally be interested in knowing if anyone else has done this and what adjustments to their jekyll config are required to publish via IPFS.
Since Jekyll is such a popular static site, it might be useful to document these changes to make it easy for people to switch from publishing their blogs on github pages to publishing on ipfs.
Hi @jeffreycwitt. I’m glad you’re having fun experimenting. You should modify your jekyll config so that all of your links are relative links instead of absolute links (so they shouldn’t start with '/'). This is a common thing to do with any static site generator. I’m not sure of the exact approach to take with Jekyll.
1 Like
Yeah, I guess that started to be obvious even as I wrote the question. Should be an easy change 
I am hosting my own blog on IPFS via Jenkins, but I have to tweak continuously the settings to enable the https domain or IPFS. Probably @flyingzumwalt solved your problem
Looks like dealing with relative paths in Jekyll is a continual problem for people (https://github.com/jekyll/jekyll/issues/332, https://ricostacruz.com/til/relative-paths-in-jekyll) that as @koalalorenzo says requires “constant tweaking”.
Not exactly an ipfs problem though, more of a Jekyll problem.
1 Like
Maybe try this Hugo project instead (just going to do the same myself now - had this same idea last night about running a GitHub Pages style blog thing on IPFS, easy kudos points it seems heh, plus Akasha is coming soon right?! 
Or maybe it’s already here…
3 Likes
That’s actually how I found out about the IPFS: I was looking into Hugo, and one of the built-with-Hugo sites/blogs I looked at mentioned the IPFS. I think Hugo & IPFS can work well together.
It works pretty nicely (this link may or may not die in the near future I guess, and I haven’t added any content apart from these two blank pages).
I just had to do this as found on the Hugo discussion platform, and then run hugo -d public
1 Like
Yeah, hugo is quite nice and we’re in the middle of migrating all websites related to IPFS (https://ipfs.io, https://multiformats.io, https://libp2p.io and https://ipld.io) to hugo, some of them already done.
Latest example is https://ipfs.io/blog which is now made with hugo, you can checkout the source here: https://github.com/ipfs/blog/
1 Like
A bit hacky, but couldn’t you just use sed to replace a href="/about/" with a href="/ipfs/whatever/about/"?
sed 's/a href="\//a href="\/ipfs\/whatever\/'
(also do the same for images)
Is the usage of Hugo or Jekyll optimal? They’re made to run on HTTP, where changing the content is no big deal. But this has some side effects which make it undesirable for IPFS use. Are there any alternatives made to cause as few pages as possible to change hash upon edits/inserts/deletions?
For example:
- Changing the theme will cause all pages to change hash. This could be averted by always linking to /theme.css, and then only changing this file when a theme change is desired.
- Uploading a new article will cause all other articles to change, since the list of recent articles in the sidebar is hardcoded in the page. Since it’s shared among all pages, wouldn’t it make more sense to have it as a separate page and embed it via frame?
- Uploading a new article will cause all other index pages to change, since the ID will change. It would make more sense to count up from 1 (the oldest page will have ID 1) than down from 1 (the newest page will have ID 1). Then an old index page would never change if it’s not the latest. The inversion of ID order could even be hidden with CSS if one finds it a major problem.
This is no problem for a larger blog, which can afford to run a server constantly serving the latest pages, but a smaller blog will probably be hosted from someone’s personal computer (i.e. only available during certain hours of the day). And trashing perfectly good pages because of naïve optimization is very wasteful in itself.
3 Likes
Make sure to read: https://github.com/ipfs/notes/issues/66 and also, you can consult the yet unpublished blog post at: https://github.com/ipfs/blog/pull/31/files
Both should provide more context and a good base on how to publish your blog to IPFS
2 Likes