I am trying to add a new post to my Jekyll site, but I cannot see it on the generated pages when I run jekyll serve
.
What are some common reasons for a Jekyll post to not be generated?
_posts
directory.YEAR-MONTH-DAY-title.MARKUP
(Note the MARKUP
extension, which is usually .md
or .markdown
)future: true
in _config.yml
(documentation)published: false
in its front matter. Set it to true
.:
character. Replace it with :
.3.8.3
(and probably in other 'recent' releases).You can use jekyll build --verbose
to view build process in detail.
Exmaple output:
Logging at level: debug
Configuration file: /home/fangxing/fffx.github.io/_config.yml
Logging at level: debug
Requiring: jekyll-archives
Requiring: jekyll-livereload
Requiring: kramdown
Source: /home/fangxing/fffx.github.io
Destination: /home/fangxing/fffx.github.io/_site
Incremental build: enabled
Generating...
EntryFilter: excluded /Gemfile
EntryFilter: excluded /Gemfile.lock
Reading: _posts/2018-01-14-new-post.md
Reading: _posts/2014-01-01-example-content.md
Reading: _posts/2014-01-02-introducing-lanyon.md
Reading: _posts/2017-11-21-welcome-to-jekyll.markdown
Reading: _posts/2018-01-14-boot-android-on-charge.md
Reading: _posts/2013-12-31-whats-jekyll.md
Skipping: _posts/2018-01-14-boot-android-on-charge.md has a future date
Generating: Jekyll::Archives::Archives finished in 0.000122873 seconds.
Generating: JekyllFeed::Generator finished in 0.000468846 seconds.
...
from the log I found jeklly skipped 2018-01-14-boot-android-on-charge.md
because it has a future date.
One possible reason is that the date
specified in the front matter does not contain a time zone offset, in which case it defaults to UTC, not the time zone of the local machine as you might expect. I wasted an hour on this until UTC "caught up" with my current local time zone, BST.
I haven't found a definitive answer to this but I think the date in the front matter must be given in UTC with a timezone offset (which defaults to zero if omitted).
So date: 2018-05-03 12:34:27
is in UTC irrespective of where in the world you are, and irrespective of the timezone
setting in _config.yml
.
So be careful to specify datetimes like this:
date: 2018-05-03 12:34:27 +0100
I have written Rspec tests for my blog that express these rules:
require 'spec_helper'
require 'yaml'
# Documented at https://jekyllrb.com/news/2017/03/02/jekyll-3-4-1-released/
post_regex = %r!^(?:.+/)*(\d{2,4}-\d{1,2}-\d{1,2})-(.*)(\.[^.]+)$!
def date_in_front_matter(date)
return date if date.is_a?(Date)
return date.to_date if date.is_a?(Time)
return Date.parse(date) if date.is_a?(String)
end
describe 'posts' do
Dir.glob("_posts/*md").each do |file|
basename = File.basename(file)
context basename do
front_matter = YAML.load(File.read(file).split(/---/)[1])
it 'filename must match documented post regex' do
expect(basename).to match post_regex
end
it 'date in file name same day as date in front matter' do
date_in_file_name = Date.parse(post_regex.match(basename).captures[0])
expect(date_in_front_matter(front_matter['date'])).to eq date_in_file_name
end
it 'title in front matter should not contain a colon' do
expect(front_matter['title']).to_not match /:/
end
it 'front matter should not have published: false' do
expect(front_matter['published']).to_not be false
end
end
end
end
This may be of use to others as I was losing a lot of time due to typos in the date etc.
These tests along with the rest of the Rspec config can be seen in context here.
Just to add one more reason, when you move an article from _drafts
to _post
, you sometimes need to delete the _site
for the article to be regenerated.
In my case it often happens that _site
will not be entirely deleted before re-generation so the new article won't appear.
Anyway rm -rf _site
and bundle exec jekyll serve
works :)
If you have checked your front matter, and all seems well, and even jekyll build --verbose
doesn't reveal anything (in my case, it just acted as if the file didn't exist at all, not even listing it as excluded), check the encoding of your file. Apparently, it needs to be UTF-8
without signature. It it's UTF-8 BOM
(or UTF-8 with Signature
as some text editors call it), then it will be silently ignored. To make matters worse, some editors will display both types as just UTF-8
, making the difference even harder to spot.