Jekyll • Simple, blog-aware, static sites

Jekyll 3.8.6 Released

2019-07-02T08:21:02-07:00

We have another patch release in the 3.8 series! This time, we have one security patch and a handful of bug patches, including:

Filter symlinks from theme gems
Fix excerpt handling of some Liquid tags
Handle case where a theme directory doesn’t exist
A few internal optimizations to reduce memory overhead

… and a few more! You can check out the patches and see all the details in the release notes

Happy Jekylling!

Jekyll 3.8.3 Released

2018-06-05T07:00:00-07:00

This release fixes a regression in 3.8 where collections with published: false do not show when using the --unpublished flag.

Thanks to @philipbelesky for reporting and fixing this issue; collections with published: false now behave the same way as Posts.

Jekyll 3.8.2 Released

2018-05-19T08:30:00-07:00

Hello Jekyllers!!

Today we are releasing v3.8.2, which fixes the way Jekyll generates excerpts for posts when the first paragraph of the post contains Liquid tags that take advantage of Liquid’s whitespace control feature.

Big thanks to @kylebarbour, who first reported this issue and also very quickly submitted a fix. Also thanks to @nickskalkin for making sure that we are using the latest version of Rubocop to lint our code.

Jekyll 3.8.1 Released

2018-05-01T09:56:01-07:00

Happy May Day :tada:

The Jekyll team is happy to announce the release of v3.8.1, which fixes a couple of bugs that were introduced two weeks ago in v3.8.0. If you have experienced trouble regarding post excerpts or non-published posts, this release should be the remedy. Thanks to @Chaosed0 and @domLocalHeroes for originally reporting these issues, and to @ashmaroli for fixing them so quickly.

As a reminder, we have started work on Jekyll 4.0. If there are any features that you would love to see added to Jekyll, or any pain points you would like to see removed, please do add your ideas to the Jekyll 4.0 idea list.

Jekyll 3.7.3 Released

2018-02-24T23:32:08-08:00

Hello Jekyllers!! :wave:

We’re pleased to announce the release of v3.7.3 which fixes a bug one might encounter while using Jekyll - 3.7.x along with a Jekyll plugin that in turn uses the I18n library.

When v3.7.0 enhanced our slugify filter with a latin option, we also hardcoded a default fallback locale for the I18n library to avoid an exception raised in the event the library fails to find any locale. This led to issues with third-party i18n plugins for Jekyll, especially since the default locale got assigned before the plugin was loaded, irrespective of whether the slugify filter was used.

Jekyll will henceforth set the default locale if and only if necessary.

Meet Jekyll’s New Lead Developer

2018-02-19T17:48:09-08:00

Jekyll has a new Lead Developer: Olivia!

After over 5 years of leading Jekyll, many releases from 0.12.1 to 3.6.0, and countless conversations in GitHub Issues, Pull Requests, Jekyll Talk, and more, I am passing on the torch as Lead Developer of Jekyll.

Olivia has been working with the Jekyll community for some time now. You may have seen her around in issues and pull requests on the various Jekyll repositories. She started as a contributor, then joined the Core team as our community lead. Olivia joined the Jekyll Core Team with experience in the Node.js community, both online and as a volunteer organizer with JSConf EU.

In my conversations with Olivia, it is clear that Jekyll’s vision of simplicity for the user (no magic!) and letting users’ content be king will remain a top priority. In just the last few weeks as the transition has been occurring, we have seen some incredible work on performance that will make future versions of Jekyll work better at scale. She will be prioritizing work on innovative improvements to make Jekyll that much better for all of us. Olivia balances an eye for quality with the need for shipping well.

When Tom Preston-Werner met me at GitHub HQ 2.0 in January 2013 to pass on the torch, I could never have dreamed of all the amazing experiences this community would share with me over the next 5 years. From visiting @qrush in Buffalo, NY for a hack night on Jekyll to attending a Jekyll planning session hosted by @benbalter at GitHub to Google Summer of Code which gave us jekyll-admin, I am eternally grateful to all of you for the opportunity to lead this excellent community. I’m confident Olivia will continue to lead Jekyll to even greater heights.

As always, Happy Jekylling!

Parker

Curious about who else runs this show? Check out our excellent team.

Jekyll 3.7.2 Released

2018-01-25T08:52:22-08:00

Close on the heels of shipping 3.7.0, we were informed of a couple of regressions due to the changes made in that release. In due time, Team Jekyll set out to address those issues as early as possible.

Days later here we’re, announcing 3.7.2 (sorry for skipping 3.7.1, RubyGems didn’t want to play nice) that fixes numerous issues! :tada: The highlights being:

A major regression in 3.7.0 was that when a Front Matter Default was configured with a scope["path"] set to a directory, Jekyll would scan that directory for any subfolders and files, for each document in that path. Though this is intended, it increases build times in proportion to the size of the directory.

We addressed this by having Jekyll scan the directory path only if the user explicitly configures the scope["path"] using wildcards.

Read our documentation for more details.

A huge shout-out to @mmistakes for bringing this to our notice and additionally providing us with a test repository to aid in resolving the issue.
Another regression reported was related to our “Custom collections directory” feature introduced in 3.7.0.

Users setting collection_dir to a certain directory would have altered paths to their posts still at the root of their site’s source. This roughly translated to 404 errors on URLs to their posts.

Props to @localheinz for bringing this regression to our notice.

We decided to resolve this by having Jekyll ignore posts and drafts at the root of the site’s source directory if the user customizes the collection_dir setting.

Ergo, if you set a custom location for your collections, please ensure you move all of your collections into that directory. This includes posts and drafts as well. Your links generated by {% post_url %} or {% link %} will adapt automatically.
We also found out that gem "wdm" boosts performance while directories are being watched on Windows. So we recommend having it included in your Gemfile for a better development experience on Windows. (Newly generated Gemfiles will hereafter have that gem listed automatically :wink:)

In addition to the above, numerous other minor fixes and documentation updates have been made that should improve your Jekyll experience. All of which, would not have been possible without our wonderful contributors:

Alexandr, Andreas Möller, Ashwin Maroli, Chayoung You, Florian Thomas, Frank Taillandier, Hendrik Schneider, Kacper Duras, Olivia, Parker Moore and Paul Robert Lloyd.

As always, you can see our full changelog on the History page.

Happy Jekylling! :sparkles:

Jekyll 3.7.0 Released

2018-01-02T02:21:40-08:00

We’re happy to release a new minor for the new year. Here are a few of the latest additions from our contributors:

LiveReload is available as an option during development: with jekyll serve --livereload no more manual page refresh. A big thanks to @awood for this feature and to @andreyvit, LiveReload author.
New collections_dir configuration option allows you to store all your collections in a single folder. Your source root folder should now look cleaner :sparkles: .
If you’re using a gem-based theme in coordination with the --incremental option, you should notice some significant speed during the regeneration process, we did see build time went down from 12s to 2s with @mmistakes minimal-mistakes theme during our tests.
Jekyll will now check to determine whether host machine has internet connection.
A new latin option is available to better handle URLs slugs.
And of course many bug fixes and updates to our documentation — which you can now search thanks to our friends @Algolia.
Full history is here.

This release wouldn’t have been possible without all the following people:

Aaron Borden, Alex Tsui, Alex Wood, Alexey Pelykh, Andrew Dassonville, Angelika Tyborska, Ankit Singhaniya, Ashwin Maroli, bellvat, Brandon Dusseau, Chris Finazzo, Doug Beney, Dr. Wolfram Schroers, Edward Shen, Florian Thomas, Frank Taillandier, Gert-jan Theunissen, Goulven Champenois, János Rusiczki, Jed Fox, Johannes Müller, Jon Anning, Jonathan Hooper, Jordon Bedwell, Junko Suzuki, Kacper Duras, Kenton Hansen, Kewin Dousse, Matt Rogers, Maximiliano Kotvinsky, mrHoliday, Olivia, Parker Moore, Pat Hawks, Sebastian Kulig, Vishesh Ruparelia, Xiaoiver and Yashu Mittal.

A big thanks to everyone!

Oh, one last thing…

:pray: upgrade your Ruby

Prepare for the next major update, as next major version Jekyll 4.0 will drop support for Ruby 2.1 and 2.2.

Ruby 2.2 is now under the state of the security maintenance phase, until the end of the March of 2018. After the date, maintenance of Ruby 2.2 will be ended. We recommend you start planning migration to newer versions of Ruby, such as 2.4 or 2.3. — Ruby Core Team

We strongly encourage you to upgrade to at least Ruby 2.4.x like our friends at GitHub Pages or even go with Ruby 2.5.

Happy new year to all from the Jekyll team!

Jekyll 3.6.2 Released

2017-10-21T12:31:40-07:00

3.6.2 is out, it’s a tiny patch release and we invite you to run bundle update if you want to avoid possible build problems with:

some UTF-8 and UTF-16 encoded files,
fully numeric layout names (we convert those to string for you now).

Other changes include updates to our documentation, like this complete video series by Giraffe Academy aimed at complete beginners. A big thanks to Mike for this.

And if you’re wondering what happened to version 3.6.1, it was just our new release maintainer getting familiar with the release process. 😄

We try to release patch releases as quickly as possible and we’re already working on the next minor version 3.7.0 that will allow you to store all your collections in a single directory. Stay tuned.

Theme developers are invited to test the brand new jekyll-remote-theme plugin and give their feedback to @benbalter. This plugin allows you to use any GitHub hosted theme as a remote theme!

Once again, many thanks to our contributors who helped make this release possible: ashmaroli, bellvat, Frank Taillandier, i-give-up, Jan Piotrowski, Maximiliano Kotvinsky, Oliver Steele and Pat Hawks. For some it was their first contribution to open-source 👏

As it’s been nine years this week that Tom Preston-Werner started this project, I also wanna seize this opportunity to thank all of the 732 contributors who helped make it possible for Jekyll to power millions of websites around the world today.

Happy Birthday Jekyll! 🎂

Diversity in Open Source, and Jekyll’s role in it

2017-10-19T12:33:00-07:00

Open Source has a problem with diversity. GitHub recently conducted a survey which revealed that 95% of the respondents were identifying as male. This is even worse than in the tech industry overall, where the percentage is only about 76%. Every other week, there seems to be another case of a maintainer engaging in targeted harassment against minorities. People somehow deem it completely okay to let these things slide, though.

Fortunately, there’s a couple of things we can do to make it easier and more comfortable for people that have never contributed to any open source project before, to contribute to our projects.

Add a Code of Conduct, and enforce it

This might seem like one of the easiest steps to do, but it actually requires a lot of dedication to pull through with. Basically, a Code of Conduct is a document detailing what is and what isn’t acceptable behavior in your project. A good Code of Conduct also details enforcement procedures, that means how the person violating the Code of Conduct gets dealt with. This is the point at which I’ve seen a looooot of projects fail. It’s easy enough to copy-paste a Code of Conduct into your project, but it’s more important to be clear on how to enforce it. Inconsistent —or worse, nonexistent— enforcement is just going to scare off newcomers even more!

The most widely adopted Code of Conduct is the Contributor Covenant. It’s a very good catch-all document, but it is a bit light in the enforcement section, so I’d recommend to flesh it out by yourself, be it by means of adding contact information or expanding the enforcement rules.

No matter which Code of Conduct you pick, the most important thing is to actually read it for yourself. The worst thing in open source is a maintainer that doesn’t know when they’ve violated their own Code of Conduct.

Document your contributing workflow

The problem that puts people off the most is incomplete or missing documentation, as revealed through GitHub’s open source survey. A very popular myth in programming is that good code explains itself, which might be true, but only for the person writing it. It’s important, especially once you put your project out there for the world to see, to document not only your code, but also the process by which you maintain it. Otherwise, it’s going to be extremely hard for newcomers to even figure out where to begin contributing to your project.

Jekyll has an entire section of its docs dedicated to information on how to contribute for this very reason. Every documentation page has a link to directly edit and improve it on GitHub. It’s also important to realize that not all contributions are code. It can be documentation, it can be reviewing pull requests, but it can also just be weighing into issues, and all of this should be recognized in the same way. At Jekyll, out of 397 total merged pull requests in the last year, 204 were documentation pull requests!

Create newcomer-friendly issues

For most people new to open source, the biggest hurdle is creating their first pull request. That’s why initiatives such as YourFirstPR and First Timers Only were started. Recently, a GitHub bot that automatically creates first-timer friendly issues was launched, which makes it very easy for maintainers to convert otherwise small or trivial changes into viable pull requests that can be taken on by newcomers! So we decided to give it a shot, and we’ve created a couple of very easy first timers only issues:

(There’s also an up-to-date listing of all of our first timers only issues here)

These issues are designed to be taken on only by someone who has had little to no exposure to contributing to open source before, and additionally, project maintainers offer support in case a question arises.

Jekyll is a very big and popular open source project, and we hope that with these special issues, we can help people who haven’t contributed to open source before to catch a footing in these unsteady waters.

Be nice

I know this is a cliche and a overused phrase, but really, it works if you pull through with it. Come to terms with the fact that some people aren’t as fast or reliable as you might want to think. Don’t get angry when a contributor takes a day longer than you might like them to. Treat new contributors to your project with respect, but also with hospitality. Think twice before you send that comment with slurs in it.

I’ve been contributing to open source for about 4 years now, and I’ve had my fair share of horrible, horrible experiences. But Jekyll has historically been a project that has always valued the people contributing to it over the code itself, and I hope we can keep it that way. I also hope that other project maintainers read this and take inspiration from this post. Every project should be more diverse.