Up until a few hours ago, I had my jekyll install working as normal. Having created 26 different posts using my current setup, I'm not expecting something to suddenly not work at all. Ran jekyll build to see the results of a new post I created for my blog. I got an error saying it could not find redcarpet; weird since I have never touched my config or anything since I created it. I ran bundle install no new gems added. For sanity's sake I ran bundle show redcarpet, it could not be found. Okay that's weird. So I run gem install redcarpet v 3.1.0 which was the version I was using pretty much the entire time. I then run bundle install again, checking to see if redcarpet was added...and nope.
I decided to go into my config and switch markdown parser and add kramdown, then run jekyll serve...and now I get that I'm missing kramdown and like redcarpet even if I install via gem install jekyll refuses to acknowledge it's existence.
I tried deleting my gemfile and rebuilding it unfortunately that does nothing. If I run bundle exec jekyll serve it works however redcarpet isn't activated and thus the markdown isn't parsed correctly (And new entries aren't added to the index page).
I'm probably missing something obvious, any direction or advice would be much appreciated.
I've just built my first Jekyll website, and (almost) everything was going fine, until I added a few (around 80) old posts from my previous website.
Now, when I try to run Jekyll to serve the website locally, it starts, but stay stuck in the Rebuilding index… stage:
$ ./_serve.sh
WARN: Unresolved specs during Gem::Specification.reset:
posix-spawn (~> 0.3.6)
listen (~> 2.7)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Configuration file: _config.yml
Configuration file: _config-twitter.yml
Source: /Users/nhoizey/Dropbox/Personnel/Devs/nicolas-hoizey.com
Destination: /Users/nhoizey/Dropbox/Personnel/Devs/nicolas-hoizey.com/_site
Generating...
Populating LSI...
Rebuilding index...
The _serve.sh I run here is just this:
#!/bin/sh
jekyll s --config _config.yml,_config-twitter.yml
(_config-twitter.yml contains only my Twitter API credentials I don't want to share)
The whole site source and content is in my Github repo: https://github.com/nhoizey/nicolas-hoizey.com/
Google didn't help at all, nor did Stackoverflow yet, any idea?
Came across this issue myself, but found a better solution.
Installing gsi and using the rb-gsl gem significantly speeds up LSI for me (~6sec)
I tested your site and everything seems to be running find when :
- disabling twitter tags :p
- disabling LSI in _config.yml
While the site is building I Ctrl-C to see what was running, and I get the following stack :
Rebuilding index... ^C/Users/johan/.rbenv/versions/2.1.2/lib/ruby/2.1.0/matrix.rb:315:in `[]': Interrupt
from /Users/johan/.rbenv/versions/2.1.2/lib/ruby/2.1.0/matrix.rb:823:in `block (3 levels) in *'
…
from /Users/johan/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/classifier-reborn-2.0.3/lib/classifier-reborn/extensions/vector.rb:43:in `block (2 levels) in SV_decomp'
…
from /Users/johan/.rbenv/versions/2.1.2/bin/jekyll:23:in `<main>'
I finally found this issue on Github on the plugin gems-classifier that is used to generate relative links with LSI.
I guess your best option is to disable LSI…
I've set up a vanilla Octopress blog & I am hosting on github pages, but am encountering some issues when using rake preview.
To help troubleshoot, here's a short list of changes I've made since setting up Octopress (that I can recall):
in _config.yml, changed the url to my domain
in _config.yml, changed root to "/"
in _config.yml, specified my github repo under 3rd party settings
added CNAME pointing to my domain in /public/github
added CNAMe pointing to my domain in /source/
made a post using rake new_post
Here's a description of the issues:
http://localhost:4000 yields a 404, however, I am able to see my site at http://localhost:4000/github/index.html
When previewing /github/index.html, most of the stylesheets/JS are returning a 404.
Here's what happens when I run rake generate, followed by rake preview:
Starting to watch source with Jekyll and Compass. Starting Rack on port 4000
Configuration from /Users/[redacted]/Documents/code/octopress/_config.yml
[2013-09-09 10:21:44] INFO WEBrick 1.3.1
[2013-09-09 10:21:44] INFO ruby 1.9.3 (2013-06-27) [x86_64-darwin11.4.2]
[2013-09-09 10:21:44] INFO WEBrick::HTTPServer#start: pid=39870 port=4000
Auto-regenerating enabled: source -> public/github
[2013-09-09 10:21:45] regeneration: 95 files changed
>>> Change detected at 10:21:45 to: screen.scss
identical public/github/stylesheets/screen.css
Dear developers making use of FSSM in your projects,
FSSM is essentially dead at this point. Further development will
be taking place in the new shared guard/listen project. Please
let us know if you need help transitioning! ^_^b
- Travis Tilley
>>> Compass is watching for changes. Press Ctrl-C to Stop.
You need Python 2.x. You should be able to check your Python version at the command prompt with python --version
If you don't have it then if you are on Windows, download and install Python 2.7.6 from http://www.python.org/download/
then add C:\Python27 (or the folder where you installed Python) to your path environment variable.
Did you change the destination setting in _config.yml. Default should be something like this:
root: /
permalink: /blog/:year/:month/:day/:title/
source: source
destination: public
We are dealing with an issue where our assets are compiling w/o any issues during slug compilation. However, starting yesterday after a push to both our staging and production applications, we are now running into issues where the browser is indicating that the assets can't load for some reason.
Using the browser dev tools we are seeing this error:
Failed to load resource: the server responded with a status of 404 (Not Found) :
/assets/application-a3b17e738ce8996d058795310e3cd9b4.js
The first thing we decided to do was rollback our codebase to the last commit (which was the commit that was fully functional in a previous heroku push). The same issue exists where the browser can't load the asset.
Using bash, I connected to the heroku instance and checked out the public/assets directory to ensure the assets were actually there. They are ALL there with the correct hash codes preceding the file names. The files are not empty and the manifest file looks good to go.
I'm not sure what else to try at this point. We've never had issues until now with loading of assets. There is nothing in the heroku push logs that indicate anything is throwing an error at any point.
I had the same issue. It seems to be fixed for me after including the rails_12factor gem in my production gems (in my Gemfile). I found this out after reading the first part of this Heroku Support page: https://devcenter.heroku.com/articles/rails4
Logging and assets
Heroku treats logs as streams and requires your logs to be sent to STDOUT. To enable STDOUT logging in Rails 4 you can add the rails_12factor gem. This gem will also configure your app to serve assets in production. To add this gem add this to your Gemfile:
gem 'rails_12factor', group: :production
This gem allows you to bring your application closer to being a 12factor application. You can get more information about how the gem configures logging and assets read the rails_12factor README. If this gem is not present in your application, you will receive a warning while deploying, and your assets and logs will not be functional.
The 'rails_12factor' gem has gem dependencies on the rails_serve_static_assets gem and rails_stdout_logging. Basically, if you don't want your Rails app using its precious cycles on processing requests just to serve assets then you'll need to figure out a different solution such as a CDN: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn-with-rails
I'm getting started with Jekyll static site generator and I would like to use Live Reload with it. I know Jekyll has a generator and server commands, and Live Reload can run various compilers and custom commands. How do I configure these to work together?
LiveReload is built into Jekyll 3.7+.
jekyll serve --livereload
You can also set LiveReload's port, delay, and ignored files. See jekyll help serve.
UPDATE: As pointed out in other answers, LiveReload is built into Jekyll 3.7+.
jekyll serve --livereload
For older versions:
The simplest approach I've found that works is to use two terminal windows: One for jekyll serve --watch and one for guard.
I tried the guard-jekyll-plus approach suggested by Nobu but I had a bunch of errors.
As shumushin pointed out, Jekyll can handle the automatic rebuilding process, you simply launch it using jekyll serve --watch
Now to get LiveReload working run guard with guard-livereload in a second terminal window. This is basically the same as Jan Segre's answer, but without guard-jekyll.
My Guardfile looks like this:
guard 'livereload' do
watch(/^_site/)
end
And my Gemfile:
gem 'jekyll'
gem 'guard'
gem 'guard-livereload'
Note: You still need to include the livereload script in your index.html page; it is the "glue" that binds guard-livereload and the browser together.
<script src="http://localhost:35729/livereload.js"></script>
There's guard-livereload which you can use with guard-jekyll and centralize the watching process with guard, an example would be (I haven't tested it):
Install guard-jekyll, either through gem or bundler
Install guard-livereload, either through gem or bundler
Init guard-jekyll
guard init jekyll
Add this to your Guardfile:
guard 'livereload' do
watch(%r{_site/.+})
end
You can adapt the above to suit better your project, and
you probably already know you have to include the livereload
script on your page:
<script src="http://localhost:35729/livereload.js"></script>
Oh, and to start the whole watching mess:
guard
For jekyll 1.0+ use:
jekyll serve --watch
See Jekyll: Basic Usage for more details and options.
UPDATE: this no longer works with the latest version of Jekyll
cd your/site/folder
jekyll --server --auto
This post explains a cleaner way - Setting Up LiveReload With Jekyll
Gemfile:
gem 'jekyll'
gem 'guard'
gem 'guard-jekyll-plus'
gem 'guard-livereload'
Guardfile:
guard 'jekyll-plus', :serve => true do
watch /.*/
ignore /^_site/
end
guard 'livereload' do
watch /.*/
end
Install any LiveReload browser extension. Then run guard.
I wrote a Jekyll plugin called Hawkins that incorporates LiveReload into the Jekyll watch process. It works with Jekyll 3.1 and up.
Simply add
group :jekyll_plugins do
gem 'hawkins'
end
to your Gemfile (and then a bundle install). From there you can run jekyll liveserve. Hawkins will modify the head sections of your pages to include the necessary components for LiveReload, and when Jekyll detects a page change, Hawkins will push a message to your browser via WebSockets. Please note that you will need a browser that supports WebSockets. For very fast reloads, you can use Jekyll's new --incremental option that will only regenerate the changed pages.
Start by running jekyll normally in your site folder:
cd your/site/folder
jekyll
By default Jekyll generates a folder called _site inside it (your/site/folder/_site).
Tell LiveReload to watch that _site folder.
This command will open your website in the browser and uses jekyll built-in livereload server.
bundle exec jekyll serve -l -o
You need a latest jekyll version.
I just started using GitHub Pages today, and wanted to be able to use live reload with Jekyll. Got it working & written my first post on Creating GitHub Pages with Jekyll & LiveReload.
It uses Grunt with the grunt-contrib-watch plugin instead of Jekyll's serve command - works well for me. Hope it works for you as well.
You can use just jekyll serve -w, an option I prefer as I am lazy.
For Live Reload,
Remove Jekyll Admin from Gemfile in the root directory of your project and it works like charm.
If you're running it frequently, the Repla macOS app makes it easy to startup Jekyll so it automatically refreshes. After Repla is installed, you run it from the Jekyll blog's root directory and pass it the jekyll serve command. For example:
repla server "bundle exec jekyll serve --watch --drafts" -r "...done"
Repla will be configured to refresh each time ...done is printed in the console, which Jekyll prints when it finishes compiling your site.
Repla runs the Jekyll server process in a split below a browser split showing your site:
After Jekyll is running in Repla, you can also save the configuration to a file with ⌘S, shut it down by closing the window, and run it again just by double-clicking the file. In other words, you can start your Jekyll blog again next time just by opening the file, without involving the terminal at all.
Disclosure: I maintain the Repla app.