Planet Jekyll

Thursday, 19. April 2018

Official Jekyll News

Jekyll 3.8.0 Released

Aloha Jekyllers!! :wave:

Aloha Jekyllers!! :wave:

After months of toiling on the codebase and shipping a couple of release-candidates, the Jekyll Team is delighted to finally present v3.8.0, packed with optimizations, improvements, some new features and a couple of bug-fixes. Yay!!!

Under the hood, Jekyll has undergone many minor changes that will allow it to run more performantly in the coming years. :smiley: Rest assured, our users should see minor improvements in their site’s build times.

Speaking of improvements, users running a site containing a huge amount of posts or those who like to use our where filter frequently in a single template, are going to see a massive reduction in their total build times!! :tada:

Hold on, this version is not just about optimizations, there are some new features as well..:

  • Detect non-existent variables and filters specified in a template by enabling strict_variables and strict_filters under the liquid key in your config file.
  • Allow date filters to output ordinal days.
  • jekyll doctor now warns you if you have opted for custom collections_dir but placed _posts directory outside that directory.

..and yes, a couple of bug-fixes, notably:

  • Jekyll now handles future-dated documents properly.
  • Jekyll is able to handle Liquid blocks intelligently in excerpts.
  • A few methods that were not meant to be publically accessible have been entombed properly.
  • A few bugs that still plagued our collections_dir feature from v3.7 got crushed.

As always, the full list of changes since last release can be viewed here.

A big thanks to the following people who contributed to our repository with pull-requests that improved our codebase, documentation and tests:

Ana María Martínez Gómez, Antonio Argote, Ashwin Maroli, Awjin Ahn, Ben Balter, Benjamin Høegh, Christian Oliff, Damien Solodow, David Zhang, Delson Lima, Eric Cornelissen, Florian Thomas, Frank Taillandier, Heinrich Hartmann, Jakob Vad Nielsen, John Eismeier, Kacper Duras, KajMagnus, Mario Cekic, Max Vilimpoc, Michael H, Mike Kasberg, Parker Moore, Pat Hawks, Paweł Kuna, Robert Riemann, Roger Rohrbach, Semen Zhydenko, Stefan Dellmuth, Tim Carry, olivia, and steelman.

Happy Jekylling!! :sparkles:


Official GitHub Pages News

Introducing GitHub Learning Lab: A new way to level up on GitHub

GitHub is more than a home for code. It’s a forum for collaboration, a sandbox for testing, a launchpad for deployment, and often, a platform for learning new skills. After training thousands of people to use Git and GitHub, the GitHub Training Team has established a tried-and-true method for helping new developers retain more information and ramp up quickly as they begin their software journeys

GitHub is more than a home for code. It’s a forum for collaboration, a sandbox for testing, a launchpad for deployment, and often, a platform for learning new skills. After training thousands of people to use Git and GitHub, the GitHub Training Team has established a tried-and-true method for helping new developers retain more information and ramp up quickly as they begin their software journeys. And now, we’re making those experiences accessible to developers everywhere with GitHub Learning Lab.

github-learning-lab

Instead of a traditional tutorial or webcast, GitHub Learning Lab is an app that gives you a learning experience you can actively participate in, without leaving GitHub. Our friendly bot will take you through a series of practical, fun labs that will give you the skills you need in no time—and share helpful feedback along the way.

Start learning

How it works

With GitHub Learning Lab, you’ll learn through issues opened by a bot in a GitHub repository. After you finish tasks, the bot will comment on your work and even review your pull requests like a project collaborator would.

If you have questions that come up while you complete a course, you can get answers in the GitHub Learning Lab Community Forum. This is a new way to get support from a community of learners and expert trainers (including members of the GitHub Training Team) as your journey progresses.

Check out the GitHub Learning Lab Community Forum

What’s covered

You’ll find five courses covering our most popular topics at launch:

Introduction to GitHub: Get an introduction to the most common, collaborative workflow for developers around the world.

Communicating using Markdown: Learn how to communicate on GitHub and beyond with Markdown’s simple syntax.

GitHub Pages: Host a website or blog directly from your GitHub repository.

Moving your project to GitHub: Get tips for migrating your code and contributors to GitHub.

Managing merge conflicts: Learn why merge conflicts happen and how to fix them.

Coming soon to GitHub Learning Lab:

Contributing to open source: Make your first open source contribution in a friendly mapping project.

What’s next

This is just the beginning. We’ll be expanding how this app helps new developers, inviting new course authors, and adding more topics as we go. Let us know what you think in the Community Forum.

Learn more about GitHub Learning Lab

Friday, 30. March 2018

Parker Moore @ San Francisco, CA › United States

Managing your personal servers with Puppet

At GitHub, we use Puppet to manage all our physical and virtual hosts’ configurations based on app-role combinations. Having become familiar with Puppet over my tenure there, I finally decided last month that I should be using Puppet to manage my own servers.

When I was just graduating from college and had a steady income, I finally decided it was time to have my own cloud server. Racksp

At GitHub, we use Puppet to manage all our physical and virtual hosts’ configurations based on app-role combinations. Having become familiar with Puppet over my tenure there, I finally decided last month that I should be using Puppet to manage my own servers.

When I was just graduating from college and had a steady income, I finally decided it was time to have my own cloud server. Rackspace was the easiest choice back then, and I spun up a server with CentOS 6. Being new to server administration, I spent a long time organizing the packages and apps I installed. I ran a few Ruby web apps and hosted my static site built with Jekyll. I even went through the arduous process of manually configuring postfix to receive email for me on this host. Needless to say, I learned a lot.

GitHub switched to Debian in the last year and I figured I would migrate my server to Debian, too. During my internship at 6Wunderkinder / Wunderlist, I saw first-hand how nice immutable deploys were. The concept was fairly novel for a Ruby on Rails shop: with each deploy, spin up brand new VM’s, install your code, add them to the load balancer, and spin down the old ones. This is very much how Kubernetes rolling deploys happen today. After several years of my CentOS server running and collecting cruft, I decided to follow in 6Wunderkinder’s footsteps and spun up a fresh Debian server.

In the interim, I had, like millions of other developers, become enammored with Docker. The idea of packaging up code and dependencies in a language-agnostic container was immediately appealing. I began experimenting with running my apps inside Docker containers, and proxying traffic from nginx to the Docker containers. After a while, I found a system I liked: run the docker container in an upstart script, proxy traffic received by nginx to the docker container. When I wanted to update the app, I pushed a new revision of the Docker image, modified my upstart script to use the new tag, and ran restart <app> on my VM.

Over time, I made some improvements to this: I migrated all my apps from upstart to systemd when moving to Debian, and I generated nginx configurations for static and proxy sites instead of manually creating them.

In the last month or so, I decided that spending $35/mo on a VM didn’t make much sense when there were equivalent computing environments for much less money. I signed up for Linode, which offers 1GB VM’s for $5/mo, and had to migrate all my apps again. Time for a configuration management system! I had never much liked Chef, so I chose to give Puppet a try. What a massive difference this change has made.

I began by setting up my development environment: creating my user, adding my SSH public keys, and cloning my dotfiles. This was a fairly straight-forward process. I pushed up this new code to a repository. In order to get started with Puppet on the new host, I had to install Puppet. I went with v4.8, cloned down my repository to /etc/puppet, and ran puppet apply. It worked! I setup a script/apply bash script and set it up to run every hour.

The next piece was to setup hieradata and a parker::app resource which I could use to setup my above flow. First piece was the docker image. I installed the puppetlabs-docker Puppet module (using puppet-librarian, of course!), and used the docker::image resource to download the image of my choosing. Next, I created a systemd::unit_file for my app. The unit file is based on a common template using docker run and writing all environment variables to a file and using the --env-file flag when running the docker container. It exposes the server to a port of my choosing. I used the camptocamp-systemd Puppet module to get systemd::systemctl::daemon_reload, which I notify when a systemd unit file changes. Last, I used the service resource to ensure the service is running when I apply my puppet catalog.

This made this very easy! I setup a new .pp file for each of the servers I wanted to run. For those which used a database, I used the puppetlabs-mysql module and used the mysql::db resource to create a database, user, and password specific to each app. If I needed any other resources (for example, a specific unix user for the app), then I could add these in this .pp file.

To install each app, I used hieradata. Hiera is basically the greatest thing ever, and makes managing your puppet code so much nicer. All my parameters to each class go in the hiera YAML file for each host. And at the top, I specify a classes array, which essentially includes each class. When I want a new app, I create the class for it, and include it in this list for the host I want to install it on.

I also run a few static sites from this server (like this one!) and wanted to set those up, too. I created a site resource and created a new class for each static site I wanted to host. These are simple webroot nginx configurations so all I do is create directories, symlink a file in sites-available to sites-enabled, and let my jekyll-build-server handle the creation of the site.

This has been working great so far! Setting up new apps and static sites is super simple now. I’m in the process of both manging nginx with this (I compile manually using the versions of nginx, zlib, openssl, and pcre that I want), and setting up my home NUC to use this, too. I have a bunch of little command-line utilities which do my bidding and it’d be nice to get those all installed via this new method, too.

One open question I have is managing secrets. I just write these in plain text in my hieradata YAML file, which isn’t ideal. Anyone with the proper unix permissions who gets onto my server can see all my credentials. One thing I’ve done is setup a separate user on GitHub.com with access to my static sites and other repos of mine and use personal access tokens for that user instead of for my user. This helps reduce the likelihood that a security breach on my servers would result in any meaningful access to private code that I didn’t explicitly allow my server to access. Using GitHub Apps seems like a better next step, but I haven’t quite gotten there. If you have any recommendations for how I can better organize this, please drop me an email!

Managing my servers with Puppet has been a great pleasure so far and I’m really pleased with how it’s helped make managing my servers even easier. :sparkles:

Sunday, 25. February 2018

Official Jekyll News

Jekyll 3.7.3 Released

Hello Jekyllers!! :wave:

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.


Jekyll 3.7.3 Released

Hello Jekyllers!! :wave:

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.

Tuesday, 20. February 2018

Official Jekyll News

Meet Jekyll’s New Lead Developer

Jekyll has a new Lead Developer: Olivia!

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.

Thursday, 25. January 2018

Official Jekyll News

Jekyll 3.7.2 Released

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.

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:

Tuesday, 02. January 2018

Official Jekyll News

Jekyll 3.7.0 Released

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

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!

Saturday, 21. October 2017

Official Jekyll News

Jekyll 3.6.2 Released

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:

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! 🎂

Thursday, 19. October 2017

Official Jekyll News

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

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 le

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.

Thursday, 21. September 2017

Official Jekyll News

Jekyll turns 3.6!

Another much-anticipated release of Jekyll. This release comes with it Rouge 2 support, but note you can continue to use Rouge 1 if you’d prefer. We also now require Ruby 2.1.0 as 2.0.x is no longer supported by the Ruby team.

Another much-anticipated release of Jekyll. This release comes with it Rouge 2 support, but note you can continue to use Rouge 1 if you’d prefer. We also now require Ruby 2.1.0 as 2.0.x is no longer supported by the Ruby team.

Otherwise, it’s a massive bug-fix release! A few bugs were found and squashed with our Drop implementation. We’re using the Schwartzian transform to speed up our custom sorting (thanks, Perl community!). We now protect against images that are named like posts and we generally worked on guarding our code to enforce requirements, instead of assuming the input was as expected.

Please let us know if you find any bugs! You can see the full history here.

Many thanks to our contributors who helped make this release possible: Aleksander Kuś, André Jaenisch, Antonio Argote, ashmaroli, Ben Balter, Bogdan, Bradley Meck, David Zhang, Florian Thomas, Frank Taillandier, Jordon Bedwell, Joshua Byrd, Kyle Zhao, lymaconsulting, Maciej Bembenista, Matt Sturgeon, Natanael Arndt, Ohad Schneider, Pat Hawks, Pedro Lamas, and Sid Verma.

As always, Happy Jekylling!

Friday, 01. September 2017

Parker Moore @ San Francisco, CA › United States

Schwartzian transform & faster sorting

In responding to a Jekyll pull request, I went digging around the way Ruby handles sorting. The problem was that we were trying to sort a list of objects which don’t all have a given property. The contributor was using sort_by which throws an ArgumentError if the block returns a nil value at all. We had a sparse property we wanted to sort by.

Our typical solutio

In responding to a Jekyll pull request, I went digging around the way Ruby handles sorting. The problem was that we were trying to sort a list of objects which don’t all have a given property. The contributor was using sort_by which throws an ArgumentError if the block returns a nil value at all. We had a sparse property we wanted to sort by.

Our typical solution to this is something like:

def sort_sparse_property(objects, property)
  objects.sort do |apple, orange|
    apple_value = apple.public_send(property)
    orange_value = orange.public_send(property)

    if !apple_value.nil? && orange_value.nil?
      -1
    elsif apple_value.nil? && !orange_value.nil?
      1
    else
      apple_value <=> orange_value
    end
  end
end

Indeed, we did that in Jekyll::Filters#sort_input. It works fine, but it’s pretty slow. The speed difference between Enumerable#sort and Enumerable#sort_by is well-documented: sort_by wins every time. But why?

Well, I read the documentation for Enumerable#sort_by all the way through to the end. Lo, and behold! It walks right through an optimization problems using sort! The key problem is that the sort block is allocating objects during every call. That’s a huge waste of allocations, and if you have ever worked on production systems written in Ruby, you know object allocations are one of the key reasons for slowness.

To reduce object allocations, the Ruby documentation suggests something called a “Schwartzian transform”:

A more efficient technique is to cache the sort keys (modification times in this case) before the sort. Perl users often call this approach a Schwartzian transform, after Randal Schwartz. We construct a temporary array, where each element is an array containing our sort key along with the filename. We sort this array, and then extract the filename from the result.

This is exactly what sort_by does internally.

Holy smokes! So going back to our example above, it’s suggesting we first extract the property for each object, then we sort, then we pull the object out again. Let’s give that a try:

def sort_sparse_property(objects, property)
  objects.map { |object| [object.public_send(property), object] }
    .sort do |apple, orange|
      # apple & orange are now an arrays of [value, object]
      # Use the value cached in this array to compare!
      if !apple.first.nil? && orange.first.nil?
        -1
      elsif apple.first.nil? && !orange.first.nil?
        1
      else
        apple.first <=> orange.first
      end
    end
    .map { |object_info| object_info.last }
end

The first call to #map creates an array for each object with the value we want to compare paired with the object itself. The call to #sort performs the sort as usual, but this time it’s using the cached value. The last #map extracts the object from the sorted array of [value, object] pairs.

I wrote a benchmark for Jekyll using Jekyll::Document objects and ran it for 2 properties: one which is sparsely available (i.e. only on a few objects), and one which is more fully available (i.e. on all but a small number of objects) and the results were shocking.

For a sparsely available property, the Schwartzian transform was 7-8x faster. And for the more fully available property, the Schwarzian transform was 1.75x faster. Those are monumental savings!

It seems like a huge waste to create a new array and a new object for every item in the original Enumerable, but as we have just proven, it is far more efficient due to the number of times the sort block is called.

Next time you implement a custom sort block, remember the Schwartzian transform!

Saturday, 12. August 2017

Official Jekyll News

Jekyll 3.5.2 Released

3.5.2 is out with 6 great bug fixes, most notably one which should dramatically speed up generation of your site! In testing #6266, jekyllrb.com generation when from 18 seconds down to 8! Here is the full line-up of fixes:

3.5.2 is out with 6 great bug fixes, most notably one which should dramatically speed up generation of your site! In testing #6266, jekyllrb.com generation when from 18 seconds down to 8! Here is the full line-up of fixes:

  • Backport #6266 for v3.5.x: Memoize the return value of Document#url (#6301)
  • Backport #6247 for v3.5.x: kramdown: symbolize keys in-place (#6303)
  • Backport #6281 for v3.5.x: Fix Drop#key? so it can handle a nil argument (#6288)
  • Backport #6280 for v3.5.x: Guard against type error in absolute_url (#6287)
  • Backport #6273 for v3.5.x: delegate StaticFile#to_json to StaticFile#to_liquid (#6302)
  • Backport #6226 for v3.5.x: Reader#read_directories: guard against an entry not being a directory (#6304

A full history is available for your perusal. As always, please file bugs if you encounter them! Opening a pull request with a failing test for your expected behaviour is the easiest way for us to address the issue since we have a reproducible example to test again. Short of that, please fill out our issue template to the best of your ability and we’ll try to get to it quickly!

Many thanks to our contributors without whom this release could not be possible: Ben Balter & Kyle Zhao.

Happy Jekylling!

Thursday, 03. August 2017

Parker Moore @ San Francisco, CA › United States

Paralyzed

If you follow the Jekyll community, you might have noticed that I haven’t been as active in the last year or two. Part of this is due to life events usurping my free time, and part of this is something else entirely: paralysis. I want to discuss today the paralysis.

Ask any open source maintainer what their job description is, and you’ll likely hear about reviewing patches sent from comm

If you follow the Jekyll community, you might have noticed that I haven’t been as active in the last year or two. Part of this is due to life events usurping my free time, and part of this is something else entirely: paralysis. I want to discuss today the paralysis.

Ask any open source maintainer what their job description is, and you’ll likely hear about reviewing patches sent from community contributors as a major responsibility of a maintainer. Maintainers are gatekeepers: they decide what code makes it into the project and what code doesn’t. Part of this is flat-out rejecting proposals (“This feature will not be accepted because it does not fit into the philosophy of the project.”) and part of this is working with contributors to get the functionality proposed up to code style, functionality, and testing standards of the rest of the project. Maintainers are making decisions non-stop about the product, style, functionality, and testing quality of a contribution.

Decision fatigue is defined as:

the deteriorating quality of decisions made by an individual after a long session of decision making.

When I first heard of this, I immediately related to it. Decision fatigue affects me greatly as a maintainer and has become a bigger problem for me since I began working as a programmer full-time.

In college, my primary focus was on doing homework and studying. The decisions I made were essentially around scheduling when to study. My free time seemed endless in some ways, since I didn’t have a particularly rigid schedule. Rehearsals, classes, studying, socializing. I wasn’t making qualitative decisions about whether what I was learning deserved to be in my brain; school doesn’t really give you that choice once you’ve selected which classes to take. I worked on Jekyll in between classes and in the evenings. It was an escape from the monotonous work of completing problem sets.

After graduation, I took a great job at VSCO, a start-up near and dear to my heart. I had used VSCOCam since the early days of the Grid and was really excited to be joining the start-up world. Jekyll was experiencing a renaissance. We were merging contributions, releasing more often, and growing the project to meet the evolving needs of web developers. It was in a good place, so I focused on making sure I could be successful at VSCO. As my focus shifted, I began reviewing fewer issues and contributions and I found myself punting on discussions all the time. I would save the link somewhere and “get back to it later.” Issues and pull requests started hanging for weeks, then months. It was getting harder and harder to determine the merits of a contribution. Every holiday, when I had a few days off work, reviews would start feeling a bit easier and I would chug through some contributions, feeling guilty that I had let them stall for so long. Once I met my girlfriend, my holidays were spent with her instead of on my computer. Slowly, I spent less and less time on Jekyll.

When I began working at GitHub on Pages, we were turning Ben Balter’s 20% project back into a full product with a full-time staff. We were cleaning up old technical debt, we made massive architectural changes, and started working on a roadmap for new features. I had been hired with the understanding that I’d be able to dedicate some of my time to Jekyll. It was an integral part of Pages after all, and I could continue building on the renaissance with more resources behind me. I put some more work into Jekyll, but the problems I could solve within GitHub beckoned. Brad Fitzpatrick wrote about this about people joining Google:

Prior to joining Google I always joked that Google was the black hole that swallowed up open source programmers. I’d see awesome, productive hackers join Google and then hear little to nothing from them afterwards. … Many open source programmers are just programmers. They like working on fun, hard problems, whether on open source or otherwise. … The Google development environment is so nice. … It’s very easy to hack on anything, anywhere and submit patches to anybody …

All this goes to say: fun, hard, new-to-me problems existed at work and I got to work on them with some of the best minds in the start-up world. The development environment at GitHub is really nice. Building a feature into the main app is easy, testing is full of niceties I never had elsewhere, and deployment is just 1 command to Hubot. I began to slowly disappear from Jekyll into this wonderland of Ruby and smart people at GitHub. When I was in college, I didn’t know a single person who was familiar with the command-line until Senior year. Students learn to program Java & Python in IDE’s, and even our classes about net infrastructure revolved around the AWS web UI. Joining the Jekyll community my Freshman year helped me learn practical development skills (like source control!) from really smart people. GitHub was that, but full-time, Chat, and great centralized tooling. The things I had joined the Jekyll community to learn I had learned, and was spending all my time soaking up the nuggets of wisdom from my colleagues, disappearing from the open source community for long lengths of time.

Some wisdom I have picked up has come in the form of advice from Ben Balter and Mike McQuaid pertaining to running an open source community. Ben had the idea of affinity teams & affinity team captains and the idea of setting up a philosophy document as guiding principles for the development of Jekyll. Mike suggested I write maintainer-focused documentation for existing and future Jekyll maintainers. I did that too. Clearly, communication and delegation were two aspects of running an open source community that I still hadn’t learned well.

Every time I take a look at the list of PR’s, I want to just close the vast majority of them because they don’t seem useful to me. I have lost my broader lens of users’ needs, and we haven’t documented our core use-cases anywhere. When I see a contribution, I don’t know how to evaulate it. We have process docs, but nothing stating how to evaluate feature requests. Do you ask the user to ship it as a plugin? How do you know if it should be in Jekyll core? Should we ship a new plugin with this functionality? Does this break a relied-on behavior? This laundry-list of questions spirals out of control until I close my browser tab.

Recently, I have been considering what it would look like to pass on the torch of lead maintainer to another member of the Jekyll community. Our affinity team captains are really excellent and are passionate about making Jekyll great. But I’m afraid if I leave, the new maintainers won’t feel like they can make decisions because they’ll feel the same paralysis.

Is this paralysis, coupled with the pressure of a project that needs work if it will survive, the first step in burning out?

I don’t know the answers here, and I don’t know when I’ll find them. All I know is that I need to start asking myself how I can reduce decision fatigue. The Jekyll community deserves better than an absentee lead maintainer. If you have any ideas or resources for dealing with decision fatigue, feel free to email me. Or, if you also suffer from this and just want to reach out to commiserate, I’m all ears. I’d be really curious to hear your thoughts.

Monday, 17. July 2017

Official Jekyll News

Jekyll 3.5.1 Released

We’ve released a few bugfixes in the form of v3.5.1 today:

We’ve released a few bugfixes in the form of v3.5.1 today:

  • Some plugins stopped functioning properly due to a NoMethodError for registers on NilClass. That’s been fixed.
  • A bug in relative_url when baseurl is nil caused URL’s to come out wrong. Squashed.
  • Static files’ liquid representations should now have all the keys you were expecting when serialized into JSON.

We apologize for the breakages! We’re working diligently to improve how we test our plugins with Jekyll core to prevent breakages in the future.

More details in the history. Many thanks to all the contributors to Jekyll v3.5.1: Adam Voss, ashmaroli, Ben Balter, Coby Chapple, Doug Beney, Fadhil, Florian Thomas, Frank Taillandier, James, jaybe, Joshua Byrd, Kevin Plattret, & Robert Jäschke.

Happy Jekylling!

Thursday, 15. June 2017

Official Jekyll News

Jekyll turns 3.5, oh my!

Good news! Nearly 400 commits later, Jekyll 3.5.0 has been released into the wild. Some new shiny things you might want to test out:

Good news! Nearly 400 commits later, Jekyll 3.5.0 has been released into the wild. Some new shiny things you might want to test out:

  • Jekyll now uses Liquid 4, the latest! It comes with whitespace control, new filters concat and compact, loop performance improvements and many fixes
  • Themes can specify runtime dependencies (in their gemspecs) and we’ll require those. This makes it easier for theme writers to use plugins.
  • Speaking of themes, we’ll properly handle the discrepancy between a convertible file in the local site and a static file in the theme. Overriding a file locally now doesn’t matter if it’s convertible or static.
  • Pages, posts, and other documents can now access layout variables via {{ layout }}.
  • The gems key in the _config.yml is now plugins. This is backwards-compatible, as Jekyll will gracefully upgrade gems to plugins if you use the former.
  • Filters like sort now allow you to sort based on a subvalue, e.g. {% assign sorted = site.posts | sort: "image.alt_text" %}.
  • You can now create tab-separated data files.
  • Using layout: none will now produce a file with no layout. Equivalent to layout: null, with the exception that none is a truthy value and won’t be overwritten by front matter defaults.
  • No more pesky errors if your URL contains a colon (sorry about those!)
  • We now automatically exclude the Gemfile from the site manifest when compiling your site. No more _site/Gemfile!
  • We fixed a bug where abbreviated post dates were ignored, e.g. _posts/2016-4-4-april-fourth.md.

And so much more!

There was a huge amount of effort put into this release by our maintainers, especially @pathawks, @DirtyF, and @pup. Huge thanks to them for ushering this release along and keeping the contributions flowing! Jekyll wouldn’t work without the tireless dedication of our team captains & maintainers. Thank you, all!

A huge thanks as well to our contributors to this release: Adam Hollett, Aleksander Kuś, Alfred Myers, Anatoliy Yastreb, Antonio Argote, Ashton Hellwig, Ashwin Maroli, Ben Balter, BlueberryFoxtrot, Brent Yi, Chris Finazzo, Christoph Päper, Christopher League, Chun Fei Lung, Colin, David Zhang, Eric Leong, Finn Ellis, Florian Thomas, Frank Taillandier, Hendrik Schneider, Henry Kobin, Ivan Storck, Jakub Klímek, Jan Pobořil, Jeff Puckett, Jonathan Hooper, Kaligule, Kevin Funk, Krzysztof Szafranek, Liu Cheng, Lukasz Brodowski, Marc Bruins, Marcelo Canina, Martin Desrumaux, Mer, Nate, Oreonax, Parker Moore, Pat Hawks, Pedro Lamas, Phil Nash, Ricardo N Feliciano, Ricky Han, Roger Sheen, Ryan Lue, Ryan Streur, Shane Neuville, Sven Meyer, Tom Johnson, William Entriken, Yury V. Zaytsev, Zarino Zappia, dyang, jekylltools, sean delaney, zenHeart

Please file any bugs with detailed replication instructions if you find any bugs. Better yet, submit a patch if you find the bug in the code and know how to fix it! :heart:

Happy Jekylling! :tada:

Thursday, 18. May 2017

Parker Moore @ San Francisco, CA › United States

Add JSON Feed to your Jekyll site

You might have heard of a neat new project called JSON Feed. It’s a project to create a spec to create feeds in JSON. It’s easier to parse than RSS/Atom’s XML. JSON is also easier to check for errors: either it parses or it doesn’t. It’s easier to write than In my opinion, it’s a huge improvement on shipping serialized content. I have added a JSON feed to this site, and we’re working to add it t

You might have heard of a neat new project called JSON Feed. It’s a project to create a spec to create feeds in JSON. It’s easier to parse than RSS/Atom’s XML. JSON is also easier to check for errors: either it parses or it doesn’t. It’s easier to write than In my opinion, it’s a huge improvement on shipping serialized content. I have added a JSON feed to this site, and we’re working to add it to the jekyll-feed plugin or ship as a separate plugin.

If you want it now, I’d recommend using @vallieres’s feed.json template. :sparkles:

John Gruber wrote about a JSON Feed Viewer, too, which shows off the power of this stuff. :heart:

Wednesday, 03. May 2017

SitePoint - Jekyll

Quick Tip: E-Commerce in 30 Seconds with Gumroad and Jekyll

In my last quick tip, How to Build Customizable HTML Widgets in Jekyll, you learned how to make your own dynamic widgets for Jekyll websites. Today, I'm going to show you how you can use that knowledge to integrate your Jekyll-based website with Gumroad's services to add really powerful e-commerce functionality in just a few seconds.

What is Gumroad

For those of you who don't kno

Ecommerce with Jekyll and Gumroad in thirty seconds

In my last quick tip, How to Build Customizable HTML Widgets in Jekyll, you learned how to make your own dynamic widgets for Jekyll websites. Today, I'm going to show you how you can use that knowledge to integrate your Jekyll-based website with Gumroad's services to add really powerful e-commerce functionality in just a few seconds.

What is Gumroad

For those of you who don't know, Gumroad is a San Francisco-based e-commerce startup launched in 2012. Their service is geared towards making e-commerce easy for content creators.

In addition, Gumroad also offers useful tools that enable you to track sales and market your products to potential customers. You can read more about all that on Gumroad's website.

For web designers, Gumroad makes available some exciting features, in particular their widgets, webhooks, and API (Application Programming Interface).

Embedding Products on Your Website

To start powering up your Jekyll website with Gumroad, follow the steps below.

Grab the Code from the Gumroad's Widgets Page

The first step is to head over to Gumroad's Widgets page, where you can get the code you're going to use to create your widget.

Depending on how you want your Gumroad products to be displayed on your website, select Overlay or Embed (or why not make one widget for each option?). For the purpose of this tutorial, pick Embed with the Redirect to Gumroad option enabled.

Widgets page on Gumroad Website for integration with Jekyll

Next, scroll down to the bottom of the page where you'll find the Gumroad's auto-generated code snippet. This code has two parts: a <script> element, and a <div> element wrapping an anchor tag (if you chose Overlay instead, the second part would be the anchor tag).

Code snippet generated by Gumroad to integrate with Jekyll

Add the Gumroad Script to Your Website

Continue reading %Quick Tip: E-Commerce in 30 Seconds with Gumroad and Jekyll%

Wednesday, 05. April 2017

SitePoint - Jekyll

Quick Tip: How to Build Customizable HTML Widgets in Jekyll

The static site generator Jekyll is known in web design circles for being light-weight and "hacky". But that is only part of the truth. Jekyll is surprisingly powerful in terms of what you can do with it, and how user-friendly you can make it to non-technical users and clients.

In this quick tip, I will show how you can build HTML widgets that your clients or team members can ea

Customizable HTML widgets in Jekyll

The static site generator Jekyll is known in web design circles for being light-weight and "hacky". But that is only part of the truth. Jekyll is surprisingly powerful in terms of what you can do with it, and how user-friendly you can make it to non-technical users and clients.

In this quick tip, I will show how you can build HTML widgets that your clients or team members can easily customize and include anywhere in a Jekyll project—no Ruby plugins needed, just Liquid, the open source template language created by Shopify, and good old HTML.

Setting Variables

There are several ways of setting variables for customization. In this article, I'll introduce two of them: the inline and Front matter methods.

Inline Variables

Setting variables inline is the best option if there's a good chance the widget will be included more than once, say, in a blog post. In this example I'll use a PayPal button.

First, create a new file called paypal-widget.html in your _includes folder. Then, fill it with this code:

[code language="html"]
<form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top">
<input name="cmd" type="hidden" value="_s-xclick">
<input name="hosted_button_id" type="hidden" value="VALUE">
<button class="buy-button" name="submit">Buy Now</button>
<img src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" alt="" width="1" height="1" border="0" style="display: none !important;">
</form>
[/code]

The above example will generate a simple "Buy Now" button, allowing people to pay via PayPal. There's just one problem: the code is static and can't be customized.

The widget has two elements you will want to keep dynamic: the value of the hosted_button_id and the button label. Achieving this with inline variables is quickly done:

[code language="html"]
<form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top">
<input name="cmd" type="hidden" value="_s-xclick">
<input name="hosted_button_id" type="hidden" value="{{ include.id }}">
<button class="buy-button" name="submit">{{ include.button }}</button>
<img src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" alt="" width="1" height="1" border="0" style="display: none !important;">
</form>
[/code]

The variables you added are include.id and include.button. When you are ready to include the HTML widget inside, say, a Markdown post, you can simply do this:

[code language="html"]
{% include paypal-widget.html id="EXAMPLE-ID" button="Buy Now | $30" %}
[/code]

This will create a button labeled "Buy Now | $30". You can include the same file several times in the same page, each with different include.id and include.button values, as they are set individually inline.

Front Matter Variables

Continue reading %Quick Tip: How to Build Customizable HTML Widgets in Jekyll%

Tuesday, 21. March 2017

Official Jekyll News

Jekyll 3.4.3 Released

Another one-PR patch update as we continue our quest to destroy all bugs. A fairly technical debriefing follows, but the TLDR is that we have updated the uri_escape filter to more closely follow the pre-v3.4.0 behavior.

Another one-PR patch update as we continue our quest to destroy all bugs. A fairly technical debriefing follows, but the TLDR is that we have updated the uri_escape filter to more closely follow the pre-v3.4.0 behavior.

In v3.4.0, we moved away from using the deprecated URI.escape in favor of Addressable::URI.encode. This is what powers our uri_escape filter.

While this transition was mostly a smooth one, the two methods are not identical. While URI.escape was happy to escape any string, Addressable::URI.encode first turns the string into an Addressable::URI object, and will then escape each component of that object. In most cases, this difference was insignificant, but there were a few cases where this caused some unintended regressions when encoding colons.

While Addressable can understand that something like "/example :page" is a relative URI, without the slash it cannot figure out how to turn "example :page" into an Addressable::URI object. URI.escape had no such objection. This lead to the following Liquid code working fine in Jekyll 3.3.x but breaking in 3.4.0:

{{ "example :page" | uri_escape }}

This was not an intended consequence of switching to Addressable.

Fortunately, the solution was not complicated. Addressable has a method Addressable::URI.normalize_component which will simply escape the characters in a string, much like URI.escape.

Thanks to @cameronmcefee and @FriesFlorian for reporting this issue.

Happy Jekylling!

Thursday, 09. March 2017

Official Jekyll News

Jekyll 3.4.2 Released

Another one-PR patch update, though without the same lessons as for the previous release.

Another one-PR patch update, though without the same lessons as for the previous release.

This release includes a beneficial change for a number of plugins: static files now respect front matter defaults.

You might be asking yourself: “why would static files, files that are static files explicitly because they don’t have YAML front matter, want to respect YAML front matter?” That’s a great question. Let me illustrate with an example.

Let’s look at jekyll-sitemap. This plugin generates a list of documents, pages, and static files, and some metadata for them in an XML file for a Google/Yahoo/Bing/DuckDuckGo crawler to consume. If you don’t want a given file in this list, you set sitemap: false in the YAML front matter. But what about static files, which don’t have YAML front matter? Before this release, they could not be excluded because they had no properties in YAML other than the ones we explicitly assigned. So if you had a PDF you didn’t want to be in your sitemap, you couldn’t use jekyll-sitemap.

With this release, you can now set front matter defaults for static files:

defaults:
  -
    scope:
      path: "pdfs/"
    values:
      sitemap: false

Now, for every file in the Liquid site.static_files loop which is in the folder pdfs/, you’ll see sitemap equal to false.

Many thanks to @benbalter for coming up with the solution and ensuring sitemaps everywhere are filled with just the right content.

As always, if you notice any bugs, please search the issues and file one if you can’t find another related to your issue.

Happy Jekylling!

Thursday, 02. March 2017

Official Jekyll News

Jekyll 3.4.1, or “Unintended Consequences”

Conformity is a confounding thing.

Conformity is a confounding thing.

We write tests to ensure that a piece of functionality that works today will work tomorrow, as further modifications are made to the codebase. This is a principle of modern software development: every change must have a test to guard against regressions to the functionality implemented by that change.

And yet, occasionally, our very best efforts to test functionality will be thwarted. This is because of how our code produces unintended functionality, which naturally goes untested.

In our documentation, we tell users to name their posts with the following format:

YYYY-MM-DD-title.extension

That format specifies exactly four numbers for the year, e.g. 2017, two letters for the month, e.g. 03, and two letters for the day, e.g. 02. To match this, we had the following regular expression:

%r!^(?:.+/)*(\d+-\d+-\d+)-(.*)(\.[^.]+)$!

You might already see the punchline. While our documentation specifies the exact number of numbers that is required for each section of the date, our regular expression does not enforce this precision. What happens if a user doesn’t conform to our documentation?

We recently received a bug report that detailed how the following file was considered a post:

84093135-42842323-42000001-b890-136270f7e5f1.md

Of course! It matches the above regular expression, but doesn’t satisfy other requirements about those numbers being a valid date (unless you’re living in a world that has 43 million months, and 42 million (and one) days). So, we modified the regular expression to match our documentation:

%r!^(?:.+/)*(\d{4}-\d{2}-\d{2})-(.*)(\.[^.]+)$!

Our tests all passed and we were properly excluding this crazy date with 43 million months and days. This change shipped in Jekyll v3.4.0 and all was well.

Well, not so much.

A very common way to specify the month of February is 2. This is true for all single-digit months and days of the month. Notice anything about our first regular expression versus our second? The second regular expression imposes a minimum, as well as maximum, number of digits. This change made Jekyll ignore dates with single-digit days and months.

The first eight years of Jekyll’s existence had allowed single-digit days and months due to an imprecise regular expression. For some people, their entire blog was missing, and there were no errors that told them why.

After receiving a few bug reports, it became clear what had happened. Unintended functionality of the last eight years had been broken. Thus, v3.4.0 was broken for a non-negligible number of sites. With a test site in-hand from @andrewbanchich, I tracked it down to this regular expression and reintroduced a proper minimum number of digits for each segment:

%r!^(?:.+/)*(\d{2,4}-\d{1,2}-\d{1,2})-(.*)(\.[^.]+)$!

And, I wrote a test.

This change was quickly backported to v3.4.0 and here we are: releasing v3.4.1. It will fix the problem for all users who were using single-digit months and days.

With this, I encourage all of you to look at your code for unintended functionality and make a judgement call: if it’s allowed, should it be? If it should be allowed, make it intended functionality and test it! I know I’ll be looking at my code with much greater scrutiny going forward, looking for unintended consequences.

Many thanks to our Jekyll affinity team captains who helped out, including @pathawks, @pnn, and @DirtyF. Thanks, too, to @ashmaroli for reviewing my change with an eye for consistency and precision. This was certainly a team effort.

We hope Jekyll v3.4.1 brings your variable-digit dates back to their previous glory. We certainly won’t let that unintended functionality be unintended any longer.

As always, Happy Jekylling!

Wednesday, 18. January 2017

Official Jekyll News

Jekyll turns 3.4.0

Hey there! We have a quick update of Jekyll for you to enjoy this January. Packed full of bug fixes as usual, thanks to the tireless efforts of our exceptional Jekyll community. Three changes to call out:

Hey there! We have a quick update of Jekyll for you to enjoy this January. Packed full of bug fixes as usual, thanks to the tireless efforts of our exceptional Jekyll community. Three changes to call out:

  1. If you’re a big fan of where_by_exp, you’ll be an even bigger fan of group_by_exp.
  2. Using a custom timezone in Jekyll on Windows? Yeah, sorry that hasn’t ever worked properly. We made it possible to accurately set the timezone using IANA timezone codes.
  3. Documentation has been improved, notably on themes, includes and permalinks.

And lots and lots more!

This update was made possible by the dedicated efforts of our excellent contributors: Ajay Karwal, Alexey Rogachev, Ashwin Maroli, BlueberryFoxtrot, Chase, Chayoung You, Dean Attali, Dmitrii Evdokimov, Don Denton, Eldritch Cheese, Fabrice Laporte, Florian Thomas, Frank Taillandier, Hugo, Ivan Dmitrievsky, Joel Meyer-Hamme, Josh Habdas, Kenton Hansen, Kevin Wojniak, Kurt Anderson, Longwelwind, Max Chadwick, Nicolas Hoizey, Nursen, Parker Moore, Pat Hawks, Purplecarrot, Ricardo N Feliciano, Rob Crocombe, Roger Ogden, Skylar Challand, Thiago Arrais, Tim Banks, Tom Johnson, Tunghsiao Liu, XhmikosR, Zlatan Vasović, alexmalik, brainscript, kimbaudi, muratayusuke, penny, and yoostk.

As always, if you encounter bugs, please do search the issues and file an issue if you aren’t able to find a resolution. We also have our Jekyll Talk forum for those of you with general questions about how to accomplish certain tasks with Jekyll.

We have some exciting updates in store for v3.5, and we’re hard at work on those already.

Happy Jekylling!

Monday, 14. November 2016

Official Jekyll News

Jekyll 3.3.1 Released

Hello! We have a bugfix release of Jekyll hot off the presses for you. Key fixes to call out:

Hello! We have a bugfix release of Jekyll hot off the presses for you. Key fixes to call out:

  1. Only warn about auto-regeneration issues on Windows instead of disabling
  2. Exclude very specific vendor/ subdirectories instead of all of vendor/
  3. Allow permalink templates to have plaintext underscores

..and lots more! Check out the full history for more.

Happy Jekylling!

pluto.models/1.4.0, feed.parser/1.0.0, feed.filter/1.1.1 - Ruby/2.0.0 (2014-11-13/x86_64-linux) on Rails/4.2.0 (production)