This post is to gauge what features or enhancements the community would like to have / see in future versions of Jekyll.
See this as a “Suggestion Box”. The maintainers may or may not implement the suggested enhancements but it’s always better knowing what the community desires for.
Thank you for opening this wishlist thread!
I will ponder and may have additional responses, but I will break this into a few categories:
The biggest problem with people getting started with Jekyll is not realizing webrick is required. It would be great if installing Jekyll included webrick as a dependency.
I like the Minima template a lot because it is pretty easy to configure, but I would love to see the following features.
The value these changes bring are a more future-proof solution and adds features people immediately look for, leading them to seek out other templates for a basic blog.
- Update CSS page formatting to some of the more common patterns with CSS Flexbox and Grid
- Use CSS dark mode switching
- Allow for featured images in posts
- Allow for a logo in the header, not just the title of the site
- Get rid of the SVG icons structure and move to bitmaps and or individual files for the footer (like the Twitter and GitHub logos, for example)
The value of these features is to reduce context switching and testing errors.
- We should rarely (if ever) have to stop and start
jekyll serve. Auto-reload the
--livereloadthe default. I rarely want to run Jekyll without seeing live updates to code and have to imagine I am in the 80% of people that do the same
- Warn users of missing or unconfigured
_config.yml. This could also be a general feature of
The value of these features will help reduce the number of plugins required for Jekyll for general use.
.filesizevariable that allows you to display the file size of a page. For example, let’s say you have a page that allows people to download images, audio, or video. You might use Liquid to create a link that looks like the link below. Unfortunately, you cannot get the filesize without creating a plugin
post.readingtimevariables would allow a developer to display the average time it will take to read the contents on the page. There are some good standards out there that give a good estimate, so it would be worthwhile to incorporate this feature and perhaps allow some adjustments to the formula in the
post.featuredimagewould allow a user to get the image associated with a post’s featured image
Once a blog gets fairly large, there is an obvious need to offer pagination. The value here is around expectation and not having to re-work a website. The ability to simply configure settings in
_config.yml for automatic pagination seems like a more modern and natural solution.
Configuring a code editor to support Jekyll currently means [at least] installing a front-matter extension and a Liquid extension. These extensions take a lot of configuration and require you to understand too much about how Jekyll works before you can get up and running.
The value in having an extension that allows for YML front-matter extension, code blocks, and type-ahead would allow new users to get up and running and it supports any custom site variables or filters.
It feels like headless content managers can support fast previews of sites and easily allow you to create new pages and posts. However, Jekyll always seems to be a problem for them. I do not know the technical reasons why, but I think there is something to look into there. Sorry, I cannot add more thoughts on the matter, but I do know there is value in providing a modern platform that plays nicely with the rest of the static site headless content management market.
I know Jekyll relies on Ruby. Maybe it shouldn’t anymore? Maybe it is fine? But what I do know is getting from Ruby to Jekyll can take a new user hours or days. Power users like myself and others that respond to posts here on this site can do it, but even I have a big old checklist of what I have to do to make sure Jekyll is installed and my site is ready for development. If there is some way to type
computer install jekyll and then
jekyll new mysite and that is it? I think it adoption would increase greatly.
So far, these are feature requests based on what I know about the Jekyll platform. I will think more about how a modernized version might look.
Many people that are not active and professional developers are still getting familiar with (or are blind to) using Docker, but it is super powerful, so there is an opportunity to take Jekyll into a Docker-first mentality. Perhaps even provide GitHub Action (or Azure CI/CD, etc) features built-in.
Provide guidance and possibly some built-in features that provide a framework for accessing open APIs
Provide some level of support for paywalled content (that is something I am throwing out there without a solution)
I hope this helps!
Thank you for asking! These are things I’m missing, and not sure if easy to address within Jekyll:
- Sitewide renaming (e.g., an image file which is referenced several times)
- Sitewide search for “dead” files, those which are not (or no longer) referenced anywhere
fileDateModifiedbuilt-in, and failing gracefully when the file does not (yet) exist. Name homogenised with Bill’s
“Can’t innovate anymore, my ass”
Thank you for your suggestion, BillRaymond.
- The “webrick problem” has already been solved but the patch never found itself in a release. It will definitely be part of
- The Minima theme has a couple of dark skins along with some other changes. While there hasn’t been an official release of a new version, one may utilise the
jekyll-remote-themeto pull the new features during a Jekyll build.
- Why would you suggest use of bitmaps for social icons when SVG are lighter and responsive to device widths?
- The ability to get the file size of static files, is a good idea. Wonder why Jekyll doesn’t do so already…
- The ability to show the approx reading time was never a core feature to avoid hampering performance from the calculating process. Perhaps Ruby and Jekyll has gotten faster in recent times and therefore be able to absorb the perf damping.
featured_imageis already feasible via front matter. So there won’t be any further enhancements on that front.
livereloadcannot be a default feature because it depends on native extension gems that still doesn’t have a smooth usage across platforms.
- the in-house pagination plugin is currently in limbo.
- headless content management is outside the scope of Jekyll Core.
- Jekyll will remain a Ruby program for the foreseeable future. Especially because there are already competing alternatives in other languages.
- I don’t think paywall content can be practical for static sites. There is no database involved in Jekyll.
Thanks for your response, Michael.
- Built-in file-modified data is possible but probably never implemented because it doesn’t have value in container based builds like on GitHub Pages, GitHub Actions, etc because the source repository is mostly always freshly cloned onto a clean slate.
- Hmm… “dead files” needs some pondering over.
Thanks for getting back to me!
- modified date: ok, I understand. Different use cases – I’m not using “container based builds”. So be it.
- “dead files”: holding my breath
On the “dead” file issue, I just posted a How-To topic on finding dead files with external tools (wget/diff).
Linting/proofing/validating Jekyll’s output can be complex and often requires site-by-site configuration, so I think it is best left to external tools or plugins.
A lot of Jekylers use
html-proofer to check for broken links. Dead file checking would be a good fit for
html-proofer, since it is just the inverse of link-checking. It might be possible to implement it as an
html-proofer plugin, etc.
Thank you! Looks good on first glance, looking forward to try. Yes, makes sense to keep Jekyll lean.
Thank you for the response, @ashmaroli.
Following up on a few items…
One of the things I like about the Minima theme is how easy you can start adding things to it. However, the footer section is not that simple to modify. Making it more difficult is understanding and using SVGs. A lot of people do not know what that is and then they are always looking for that one logo that does not exist int he SVG. Also, the SVG is in a sort of compilation of logos, so having to understand that takes a lot of experience. A lot of people figure out my email (not hard) and then ask me how to add a [insert logo here] logo that is not built in. I feel like it would be fine to just put a 16 px x 16 px bitmap down there so others can modify and add easily and I do not think the size would have much if any major performance hit (but also I am no expert on website performance so maybe I’m wrong )
Is it possible to get it out of limbo and shift the functionality into the base Jekyll build? I think most people that go over 25+ posts want pagination. A lot of people contact me asking why it is not there. I tell them to post the question here or on GitHub and guess what they don’t do?
Yes, I can understand that. However, I am wondering why Jekyll and Headless CMS is a problem for some vendors and if there is a way to address it? I would be happy to reach out to find out from various vendors why Jekyll previews and publishing is harder and what they are looking for. Perhaps it is a technical implementation that can benefit Jekyll. It could be there are some changes that could be made that benefit the community without trying to turn Jekyll into a headless CRM.
Yes, I hear you on this one. I know a lot of us create sites that may have training or customer-specific material on it. To gain access, the customer might need to login to the site. I am wondering out loud what Jekyll might to do support that scenario without actually being an authentication platform or contain the database of customers.
I wonder if perhaps there is a concept of a Jekyll micro-site (or sub-site, or parent/child site) where you can have a different set of URLs on the same Jekyll platform. That is what Jekyll would allow, but the developer would have to use custom code or a third-party provider to secure the site.
For example, maybe my website is:
But my paywall training site is:
Now, I have a
_config.yml file that may have multiple
baseurls. Anyway, I am thinking out loud on this one. It could be just as easy to put an entire site behind a paywall I suppose, but then you have to maintain multiple sites and that can be difficult too. Curious your thoughts? Or maybe this functionality is there and I am not aware.
Thank you for getting back with very interesting arguments, @BillRaymond
I kinda realised what you are pointing towards from your very first reply to this thread. I started working on a plugin to compile individual SVGs in a directory (or given list) into a composite resource (like the one currently in Minima’s repository) during every build.
We only planned on having a “few” widely used social media icons. A composite SVG was chosen since it allows manual editing with just a text-editor. But I guess, that was an oversight on our side.
To my knowledge, existing in-house pagination plugin works equally well with Jekyll 4 as with Jekyll 3. I wonder why users contacting do not simply add the plugin to their config file (+ Gemfile). Users with 25+ posts can’t be seen as (“newbies”) novice consumers. I hope you understand that it is not practical to have the out-of-box build to have all plugins that a certain subset of the user-base expect.
No. There is no concept of multiple sets of URLs in Jekyll. But there is a concept of altering builds with multiple config files. The exact steps involved is going to differ based on use-case.
Domain-subdomain handling and paywalling is strictly server-side. The max Jekyll or any SSG should do is emit the necessary CNAME file.
Thank you for the responses @ashmaroli!
I pressed that Reply button a little too quickly on my last response. If you require someone to help you with testing even on early builds, feel free to ping me here or you can find other ways to reach me via my GitHub Profile. I am an occasional developer, so you do not want me touching any core code, but I am happy to test and help with documentation.
@ashmaroli you wrote:
[…] what features or enhancements the community would like to have / see in future versions of Jekyll
To browse the docs for any version of Jekyll, on jekyllrb.com.
To build versioned docs websites using Jekyll.
Regarding point 1, I’m aware of the
jekyll-docs gem, which supports offline browsing of various versions of the Jekyll docs. But when browsing on the web, it seems to me very odd that those versions of the docs aren’t available online too. Couldn’t the Jekyll docs website simply serve all the sites built by
jekyll-docs, at URLs such as
Point 2 is more general. The lack of direct Jekyll support for building versioned docs seems surprising on GitHub, where the focus is on version control! The
versions-jekyll repo shows how developers can set up versioned docs using Jekyll; perhaps use of GitHub Actions and templates could simplify that approach?
In any case, various themes in other ecosystems do support versioned docs directly. The answer to a relatively recent request for help about support for versioned docs was to migrate the website from the Jekyll-based Just the Docs theme to Read the Docs…
@pdmosses Currently, Jekyll simply takes one source of truth and builds an output out of it. So to build an doculibrary of multiple versions, you would need to maintain multiple versions of sources in different directories to get one mega Jekyll build run. I don’t see how it is difficult for users to use existing Jekyll functionality to set up a versioned-docs with a centralized GH Action.
To host a versioned docs at jekyllrb.com, we may need to move the source for jekyllrb.com into a new repository. Please open an issue at the GitHub repository and ping
mattr- for their take on the idea.
I’ve opened the issue in the
I meant the
jekyll/jekyll repo actually. That’s where the source for docs at jekyllrb.com is located.