Jekyll 4.0 Ideas

[oe]

👋 Hello everyone! Summer is coming, and so is the implementation period for Jekyll 4.0. That's right, it's time to get some breaking changes in. To accommodate for this, we're opening this issue to collect interesting ideas that people would like to see implemented in 4.0. Keep in mind that even if an idea receives a lot of support, there's no guarantee that it'll get implemented — that depends on if someone is free to actually implement it. We're all volunteers here, keep that in mind.

Feel free to revive old feature requests, too, just not something that we've explicitly rejected.

For an organized view of how we're consolidating ideas and features, check out our Project board: https://github.com/jekyll/jekyll/projects/2

[laukstein]

I vote for #6293 Markdown links bidi support, in <>, []() by default.

[geraldb]

Adding fetch / get for datafiles to core (or as an "official" addon/plugin) would be great, see the unloved / public domain source @ https://github.com/18F/jekyll-get The code itself is about 40 lines, see https://github.com/18F/jekyll-get/blob/master/_plugins/jekyll_get.rb.

[geraldb]

Using the quik library for scaffolding. If you scaffold a new jekyll theme or plugin now all the code is "hard-coded" / "hard-wired". The scaffolding code itself is also "hard-wired" / "hard-coded", that is, not (re)usable for other projects. Using a (simple) "generic" scaffolding library such as quik you can turn any git(hub) repo (or directory/folder or zip archive) into a parametrized and scripted template scaffold. See the Jekyll Quick Starter Template / Scaffold - Build Your Own (Gem-Packaged) Theme as an example.

PS: Background / References - Talk Notes - Quik - The Missing Project Scaffolder (Library) for Ruby - Quick Start Your Ruby Gems, Jekyll Websites, Jekyll Themes 'n' More

[laukstein]

Custom HTTP headers compatibility for Github Pages (Webrick isn't planned to support github/pages-gem#415)

[pathawks]

@laukstein Let’s keep this restricted to Jekyll features. We don’t have any control over GitHub Pages.

[letrastudio]

I'd love to see automatic generation of tag and category archive pages in core (plugins like jekyll-archives do this, but none are whitelisted in GitHub Pages). I wrote up #6952 with my detailed rationale and a proposal of how it could work.

Here's the TL;DR:

Having vanilla Jekyll auto-generate archive pages for every tag and category is probably a good idea now, and I think I've come up with a good, clean way to do it while staying true to Jekyll's philosophy.

Code-wise, this snippet gets most of it across:

collections:
  tags:
    output: true
    permalink: /tags/:name/
  categories:
    output: true
    permalink: /categories/:name/

[mbrav]

I know that this is markdown and not necessarily jekyll related, but my life would have been a thousand times easier if jekyll supported inline footnotes like so [^Footnote, p. 123] as apposed to the more tedious:

This is first reference[^one], this is the second[^two]

[^one]: Footnote, p.1
[^two]: Footnote, p.2

[DirtyF]

@mbrav This depends on the Markdown engine. Please ask on Kramdown or CommonMark.

[asipple1]

First would like to say thank you to the Jekyll team for all the great work you all do. Jekyll is one my favorite frameworks to work with and I really do appreciate what you guys do!
Ok on to the request it would be great if there was a built-in way to paginate a list Jekyll collection items on a page. I know there is jekyll-paginate-v2 gem but it would be nice if there was a built in pagniation that worked for both post and collection items.

[nativerez]

Hello all, my first post so go easy. I want to just say that I love Jekyll, I'm now using it on a lot of my web builds. One thing that has bothered me though, is that I've not been able to take advantage of the latest Jekyll features because a lot of the 3rd party CMS solutions I rely on for my clients use (cloudcannon, siteleaf and forestry) simply don't run the latest versions of Jekyll themselves. This forces me to have my folder structures in a really messy state and not take advantage of the latest features when developing locally. So if anyone at Jekyll could bend a few arms to get them to update that would be fab.

[DirtyF]

@nativerez It alwyas take some time to update to the latest version for services like GitHub Pages, Forestry, CloudCannon or Siteleaf because they need to run tests and adapt their tools. There's nothing Jekyll's core team can do about it.

[rjachuthan]

I would like to see Nested Collections. I know there are alternatives to do this. But still if the Jekyll team can make it easier, that would be awesome.!

[hosnas]

I would like to see reading metadata in separate files.

[letrastudio]

@hosnas Great suggestion. I'll add a use case:

• Create a collection of static image files
• Add metadata (like alt text, captions, dimensions) in sidecar files
• Loop through them to create a rich image gallery

Jekyll CMS services like Siteleaf could make great use of this feature. Siteleaf uploads static assets to an _uploads collection. cc @sskylar

[cmhelmr]

I would like to see the tags of collections included in site.tags. Thanks!

[BerkhanBerkdemir]

Please please support for i18n. At least 2 languages. Many plug-ins break or don't work with ghpages.

[shivajivarma]

build in support for content blocks and components

[oe]

@shivajivarma Can you elaborate? Do you mean something like includes?

[ghost]

I'd very much love to have native support for Coffeescript in much the same manner as Sass. Thus, we could define in _config.yml

# Support Coffeescript
coffeescript:
  coffeescript_dir: _coffee
  output: compressed

This way one could create partials of .coffee in well-structured folders with all of them compiling minified to one .js file, even same way as you have css/style.sass with all the imports of individual Sass files.

[charlesrocket]

it would be great to have more interactions with github, like pulling profile information (contributions, avatar, ), releases data - and convert it for proper publication. this would be vital for software website to create team and download pages that would not require multiple code changes. currently working with current available plugins, this solution lacks stability since there's too many plugins that should be constantly updated. would be glad to help if this will go further!

[charlesrocket]

also background section could get some improvements - building website that will look good on regular displays and retina quiet challenging. creating multiple backgrounds for could be the solution to decrease loading time. or middle state like page loading to comfort browsing

[DirtyF]

@charlesrocket GitHub data should be part of GitHub-metadata plugin not Jekyll-core

[charlesrocket]

@DirtyF sorry, i just started with jekyll a week ago) this repo is on the list. at this time, i guess that this info could be pulled by metadata, but shouldn't jekyll convert it for better (more universal) usage?

[DirtyF]

@charlesrocket This is off-topic, but FYI GitHub-metadata already provides access to these data through site.github namespace.

[charlesrocket]

@DirtyF my bad. guess i misfired with backgrounds as well?

[DirtyF]

@charlesrocket It looks like so, as Jekyll is fully agnostic when it comes what's get generated in the front-end, it just transforms files into HTML. You can use plugins like jekyll-assets and/or jekyll-cloudinary to help you deal with responsive images.

[charlesrocket]

@DirtyF thanks for the input! im looking for every jekyll plugin i can find, put majority is out of date and has no support, so it pushed me to propose these functions into core (not counting jekyll-originated plugins) should i delete my comments? don't want to overload the tread since im thinking it will grow and going tho useless comments would add some discomfort

[DirtyF]

To benefit from PWA features I'd recommend the use of jekyll-pwa plugin based on workbox 3 by Google. You'll score 100/100 in LightHouse if you add a manifest.json.

[mohsenkhanpour]

@DirtyF jekyll-pwa is more of a Service Worker thingy than manifest.json thingy. 😂
I am talking about vanilla manifest.json and not Service Workers.

[mbrav]

The ability to render includes only once. This question on Stack demonstrates the idea. To demonstrate why this is a great idea, here is a scenario that I have: say you want to have a tag cloud in every one of your posts. You have tag-cloud.html in your _includes, which allows you to generate a tag cloud on every post so the user can have a better time navigating the site. Instead of generating a tag cloud for every post, it will be nice to have the ability to generate an include only once and then have it included in every post. In my case, this could decrease the generation of my blog from 1 minute to 4 seconds. Curent solutions include plugins and hacks, but this does not apear to be hard to implement natively in Jekyll.

[ashmaroli]

@mbrav The plugin mentioned in the StackOverflow you linked to, jekyll-include-cache is the best option available out there.
However, there is a related proposal for getting similar support in Core: #7108 ..
..and another (very distantly) related proposal at #7136

You may subscribe to the above PRs to stay notified about any developments on the proposals

[kenman345]

I was reading over the thoughts about Open Collective in the blog post HERE

Moving towards a means to maintain the list of plugins better might be to move those lists to yaml files and/or individual yaml files.

If each entry in a section of the list here: Available Plugins
Then we can make it easier for maintenance. You would simply add a yaml file in the appropriate location that corresponds to your section. The file would have the fields needed to be listed. This would be name, url, description...
Part of why that helps things is no merge conflicts even become possible. Refactoring that page becomes less impacted by people adding to the lists, and we can add in additional fields, like repository_url that can be used to track the repository of the project in question. When a new breaking change comes into a PR, we can potentially use a bot/script to pull in all those files and if the repository url exists, that it checks for a given pattern (and ambitiously, opens a PR for an automated fix).

All this can potentially also be achieved with a yaml file per section, but we dont gain as much in terms of potential merge conflicts, but this is a fairly straightforward data set at that point, so this might not even be a concern. Opening hundreds of yaml files does have the potential of adding on time to generate the site.

Side note: This also makes it extremely easy to keep the list alphabetically ordered.

I know this is not exactly a solution to the idea: "Create a comprehensive official plugin and theme directory site" but it does cause a shift in how we store the data we already have thats more inline with recommendations Jekyll users would be used to. It also makes it a lot easier to pull that data out into some other repository to make a dedicated official plugin directory whenever that task might be taken on.

EDIT: Apologies for my poor wording....I regret not having proofed this better.

[tordans]

I would love to see better environment support.

Update: See also #6948 (comment)

For example site.url: Right now site.url has an implicit env pattern that is hard coded for development (Source). This is very implizit, hard to understand and remember and not extendable. #5142

I would love to see this extended. Example:

url:
  production: 'https://www.example.com'
  development: 'http://www.example.test' # this could have the a fallback like today, see "source" above
  staging: 'https://staging.example.com' # this would be possible

The pattern could be:
When jekyll calls a variable, it checks for <var-name>.<env-name>. The fallback is <var-name>. So it does not matter if I configure just url order url.<env-name>.

(This is a copy of #5307 (comment))

[letrastudio]

@tordans You can set up all kinds of fallbacks by using multiple config files, as I mentioned in this comment.

I've come across this use case myself — I use _config.yml for production values, and an additional _config_dev.yml for development overrides. When building locally I run:

jekyll serve --config _config.yml,_config_dev.yml

[letrastudio]

Is anyone working on i18n support? I noticed @oe's enthusiasm for it, and a lot of interest. I think I can make a significant contribution at the proposal/spec stage.

I’ve been working on a multilingual Jekyll site, and I’ve come up with a pretty good plugin-free solution! It’s up at openhousemacau.com, hosted on GitHub Pages with Jekyll 3.7.3. It’s still in active development, but the i18n part is fully functional, and can support any number of locales (not just the two it has now).

It’s quite a complete solution, featuring sane (DRY) content management with fallbacks between locales, string translation, and date format localization. It even supports permalink localization, though we ended up not using it for this site. It works by using:

• Parallel collections for everything (_posts and _posts_zh, for example)
• A locales key in _config.yml, set up in a similar way to collections
• Scope path glob patterns in front matter defaults
• Localized strings in site.data
• A liquid include for localizing dates
• Another liquid include for setting up a bunch of relationships and variables

The biggest issue is that the last liquid include gets called a lot (especially when looping through documents), so site builds get slow quickly. While I can’t open source the entire site, I could open source the i18n system by making a demo site, if there’s interest.

Throughout development I’ve kept Jekyll 4.0 in mind, trying to think about how a native solution could eliminate the problems I’ve come up against. I think I’m pretty qualified at this point to submit a complete top-to-bottom specification proposal for discussion. Should I do it?

[kenman345]

So This is just a thought, I can try and make an issue for it with more details and thought through functionality, but I have noticed a potential gap in functionality.

If you use the _drafts folder, or have a post that is unpublished in your _posts folder, then you still need to move things around for your content, like images, to not get published to the generated site.

Since a lot of users use /assets/imgs/ folders for the beginning position of images associated to a post, I was thinking that we could make a new special key to use in posts that you add to the frontmatter.

The key would be something like asset_paths: or asset_path: that we merge to an array, and it can define any of the assets that should not be published if they do not match up to any other posts that are being published.

So if I have the following in my frontmatter:

asset_path: /assets/imgs/vacation/July/4

Then the post when in the drafts folder would not copy over any of that folder located at /assets/imgs/vacation/July/4.
However, if a post is in _posts that contains the same frontmatter key/value, then it would get published as it was included in a post that is getting published. This could be done for individual file levels too.

The last part would be that unless included and exclusively used for an unpublished post, that the folder/files in question would perform /be acted on exactly as they already are now, where they will be included or excluded based on the _config.yml settings.

[tordans]

In Reply to #6948 (comment)

@letrastudio I am aware of that solution, but it only causes new problems.

The Szenario is:
I have a config-files with 100 lines of config.
One, maybe two line of this config needs to be changed for different environments.

With your solution, I need to duplicate 99 lines in three files (dev, staging, production) and manually sync them every time I make a change. This is bound to fail!

People will forget to sync the changes and the main idea of a staging system (to behave like the production system) will be lost.

Other solutions would be
a. The one I describe in #6948 (comment)
b. Allowing more than one config, one general-config-file for all env, and one config-file for each env. This is similar to the way rails does it. The env-config will overwrite the general-config in case that is needed.
c. Your solution, but with the ability to "include" or "reference" other config files inside the one I call with the jekyll build command. For this I would say "build with staging-config" and inside staging config "use this 1 line and include/use all other lines from this other config-file".
d. …?

[mmistakes]

@tordans You don't have to duplicate 99 lines for each environment specific config file. When you specify multiple config files at build Jekyll daisy chains them from left to right.

Meaning you could have a production config with all settings, and then for your staging and dev configs just add the lines that are unique or change. Jekyll will use everything from the first config, and override whatever comes next. For example, say you have

_config.yml (production settings with all configs)

title: My Awesome Site
description: Powered by Jekyll
url: https://prod-domain.com

and then a staging specific config (e.g. _config.staging.yml

url: https://staging-domain.com

When you run bundle exec jekyll build you'd get the prod url, if you run:

bundle exec jekyll build --config _config.yml,_config.staging.yml

You'd get the staging url along with all the other variables set in _config.yml.

[kenman345]

Wanted to add a comment about what I noted in Comment that this is essentially a solution for what @Harrix requested, but a bit more segregated to the standards that we expect blogs to keep for folder/file structure. Instead of making a change to store the content with the post, this just allows you to specify it directly.

[oe]

@letrastudio So the more I've looked into implementing i18n in Core, the less feasible it became practically. There's huge performance drawbacks, even for sites that only use one language, the time spent rewriting a huge part of the Core internals would very likely be better spent working on other features, and we've garnered feedback from some big users of Jekyll that for them, performance improvements are more important than a huge new breaking feature. Obviously this shouldn't influence our decision as a project all that much, but it did provide us with insight into why a full i18n implementation in Core wouldn't be feasible. What I think we could do is provide baseline APIs upon which a (maybe officially supported) plugin could operate. If you have any such ideas, feel free to shoot them my direction!

[letrastudio]

@oe I understand, and I feel the same way about performance. However, I am not completely discouraged! Wouldn't performance impact depend largely on how the feature is designed? I think that my proposed solution wouldn't significantly impact performance for single-language sites (and it wouldn't break Jekyll 3 sites at all). Big disclaimer though: I am not a Ruby programmer so I could be completely wrong.

I think I'll write up my ideas anyway and post them as a new issue — even if they're not feasible for Core, I hope they'll contribute to the discussion, maybe even inspire some intrepid plugin developer. Or they might help spark some ideas for the baseline APIs you suggested (such low-level discussion is probably a bit out of my league).

And still, I've found that i18n is quite doable with vanilla Jekyll 3. IMHO content management can actually be better than with existing plugins, though it's a bit complex to work with on the Liquid side. Some small tweaks to make that easier might be worth implementing; I'd happily settle for making it feel like less of a hack.

[kevinSuttle]

What are the plans for (Dart) Sass support in Jekyll 4.0 now that the Ruby implementation is deprecated? I'm very interested to hear the responses from the maintainers.

[nickmccurdy]

Could libsass be used instead?

[kevinSuttle]

🤷‍♂️

[DirtyF]

@kevinSuttle We'll rely on sassc implementation, that is currently removing dependency to Ruby sass

[kevinSuttle]

Awesome. Thank you @DirtyF!

[kvz]

It would be great if include would take preference over exclude. So that you could exclude: *, and include include: [ homepage.html ] and do fast iterations over a single page. This is also how e.g. rsync and other unix tools operate, and more useful than the (current) other way around. This was also reported in ticket #4791 but stalled as it would be a breaking change. Seems like 4.0 would be a perfect moment. What do you say @envygeeks? (cced as he was planning to work on it)

[ashmaroli]

It would be great if include would take preference over exclude

@kvz I've submitted a PR that should handle what you're looking for, as a side-effect.. Would you be able to give that branch a test-run..?

# Gemfile
gem 'jekyll', git: 'https://github.com/jekyll/jekyll.git', ref: 'refs/pull/7188/head'

Feedback invited at the PR's url

[kvz]

@kvz:

It would be great if include would take preference over exclude

@ashmaroli:

I've submitted a PR that should handle what you're looking for

Just wanted to share that we confirmed that that PR solves the include vs exclude issue, so it would be very neat if that could land in 4.0 💟

[cameronmcefee]

(I suggest this without understanding what would actually be involved in doing it)

I'd love to see performance work done regarding glob patterns in frontmatter defaults. I think it's a tremendously useful feature, but it's hampered by the fact that the more useful it is for a project, the more detrimental it is to build times.

I use this feature heavily in scenarios where I have a collection of documents which represents different variations of a type of content. For example, in the Sentry marketing resources "resources" is a collection, which is broken up into folders representing podcasts, videos, and pdfs. Each of those folders has it's own defaults that are appropriate for the given medium.

In smaller collections there isn't much of an issue, but on our docs site, where a collection is 250+ pages, using a wildcard added 2s to a .8s build.

[DirtyF]

Thanks to everyone for the feedback, that's already a lot of food on our plate, we won't be able to implement all your requests, but we'll definitively do our best to fulfill your expectations. We're currently focusing on performance. As we will need your help, we might pick some priority issues and offer rewards thanks to our Open Collective sponsors. Stay tuned.