Core feature wishlist

Hello Talkers,
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.

Thank you for opening this wishlist thread!

I will ponder and may have additional responses, but I will break this into a few categories:

Fix the webrick problem

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.

Minima template

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)

Serving Jekyll

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 _config.yml file
  • Make --livereload the 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 baseurl or url in _config.yml. This could also be a general feature of jekyll doctor and jekyll build

Site variables

The value of these features will help reduce the number of plugins required for Jekyll for general use.

  • .filesize variable 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
    podcast-season-1-episode3.mp3 (4mb)
  • page.readingtime and post.readingtime variables 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 _config.yml file
  • page.feturedimage and post.featuredimage would allow a user to get the image associated with a post’s featured image

Pagination by default

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.

Offical Visual Studio Code extension (and other popular code editors)

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.

Better headless content management support

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.

One-click/easy installation

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.

Further thinking

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.

For example:

  • I like some out-of-box Hugo features like image processing, diagrams, and menus.

  • 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
  • Variable fileDateModified built-in, and failing gracefully when the file does not (yet) exist. Name homogenised with Bill’s .filesize.

“Can’t innovate anymore, my ass” :slight_smile:

1 Like

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 v4.3.0.
  • 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-theme to 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_image is already feasible via front matter. So there won’t be any further enhancements on that front.
    -livereload cannot 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.
1 Like

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 :slight_smile: :wink:

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.

1 Like

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 :slight_smile: )

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 urls and 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.

Thanks again!

Thank you for getting back with very interesting arguments, @BillRaymond :smiley:

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

Versioned documentation:

  1. To browse the docs for any version of Jekyll, on

  2. 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, we may need to move the source for into a new repository. Please open an issue at the GitHub repository and ping parkr and mattr- for their take on the idea.

I’ve opened the issue in the jekyll-docs repo.

I meant the jekyll/jekyll repo actually. That’s where the source for docs at is located.