Static files in collection not found in site.static_files

[chmaynard]

https://jekyllrb.com/docs/collections/ says the following about files inside a user-defined collection:

"If no front matter is provided, Jekyll will consider it to be a static file and the contents will not undergo further processing. If front matter is provided, Jekyll will process the file contents into the expected output."

If Jekyll treats assets in a collection as static files, why are these files not added to site.static_files?

I should mention that, in my project, the collection hash in _config.yml defines a few values such as output: true.

[ashmaroli]

If Jekyll treats assets in a collection as static files, why are these files not added to site.static_files?

The answer to this is most probably a lapse in judgement when the collections primitive was being designed.
Or perhaps it was intentional to be compatible with then existing codebase.

Currently, all static files of a collection is accessible via Jekyll::Collection#files and Jekyll::Site#documents in Ruby and in Liquid templates by either iterating through {{ site.collections }} and consequent {{ collection.files }} (where collection is the current collection in the iteration) or by iterating through `{{ site.documents }}.

---

Going forward, there are two options for us (maintainers):

• Acknowledge the current behavior as intentional and refrain from adding yet another point-of-access to static files in collections.
• Change current behavior of site.static_files to include static files in collections.

/cc @parkr, @mattr-

[chmaynard]

From my point of view, option 2 is the only sensible choice. Otherwise site.static_files is pointless.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the latest 3.x-stable or master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider building it first as a plugin. Jekyll 3 introduced hooks which provide convenient access points throughout the Jekyll build pipeline whereby most needs can be fulfilled. If this is something that cannot be built as a plugin, then please provide more information about why in order to keep this issue open.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[parkr]

It would be interesting to go back through the issues & pull requests and see if it was intentional. My recollection was that collections were not meant to include static files in the first place, so the feature was bolted on later. Changing what gets included in site.static_files is a bit dicey but I think it's ok because (anecdotally) most folks don't use static files in collections and the ones that do are likely interested in having a place to access all of their static files.

[chmaynard]

I created this issue and then found a work-around pretty quickly. I'm sure someone thought adding the site.static_files array was a good idea at the time, but the (implied) decision to ignore static files inside a collection makes the array more or less useless. This seems like a clear case of deferred maintenance.

…

On Feb 8, 2022, at 6:50 PM, Parker Moore ***@***.***> wrote: It would be interesting to go back through the issues & pull requests and see if it was intentional. My recollection was that collections were not meant to include static files in the first place, so the feature was bolted on later. Changing what gets included in site.static_files is a bit dicey but I think it's ok because (anecdotally) most folks don't use static files in collections and the ones that do are likely interested in having a place to access all of their static files. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[parkr]

@ashmaroli My vote is to include collection static files in site.static_files in Jekyll 4.3.

I don't think it was a conscious decision, but instead an oversight. For historical context, site.static_files existed long before collections. And collections existed before we supported reading static files from them. When we added support for static files to collections, we included site.collections[COLLECTION_NAME].files without adding them to the global array site.static_files. We can correct this oversight/decision now if enough folks agree.

[chmaynard]

FYI, I love Jekyll and I've been a happy user for ~5 years. If there's any way I can assist the project, I'd love to contribute. I'm an experienced developer and I'm very motivated to learn about Ruby and related dev tools. :)

…

On Feb 8, 2022, at 10:04 PM, Parker Moore ***@***.***> wrote: @ashmaroli My vote is to include collection static files in site.static_files in Jekyll 4.3. I don't think it was a conscious decision, but instead an oversight. For historical context, site.static_files existed long before collections. And collections existed before we supported reading static files from them. When we added support for static files to collections, we included site.collections[COLLECTION_NAME].files without adding them to the global array site.static_files. We can correct this oversight/decision now if enough folks agree. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[ashmaroli]

@chmaynard I'm delighted to see your enthusiasm to pick up a new language.
Ruby is very easy to learn and Jekyll has a very clean and consistent codebase.

Once you get comfortable with Ruby, figuring out how Jekyll works under the hood will be very easy.

You are free to submit pull requests to improve the Jekyll experience.
It need not be just Ruby-oriented pull requests. You may also improve our documentation website if you feel something is not right.

[y377]

@chmaynard I'm delighted to see your enthusiasm to pick up a new language. Ruby is very easy to learn and Jekyll has a very clean and consistent codebase.

Once you get comfortable with Ruby, figuring out how Jekyll works under the hood will be very easy.

You are free to submit pull requests to improve the Jekyll experience. It need not be just Ruby-oriented pull requests. You may also improve our documentation website if you feel something is not right.

hi @ashmaroli see you agian!

I have already mastered jekyll. If Jekyll users are divided into four levels: primary, intermediate, advanced, and top, I want to be promoted to advanced. I use liquid very well, and I can also use the new filter provided by the official , the only regret now is that I don’t know ruby yet, you said ruby is so simple, do you know which websites to quickly learn ruby related to Jekyll? If you know, please share it with me. I also browsed the ruby official website. I feel that the process is too long. I just want to learn the part related to Jekyll or the part related to liquid, because I want to write my own plug-in. One of the use cases is :
The documents under site.collections or site.documents use tags (for example: color), I can get the article name of color through loop iteration, but I can’t get the article pointing to `color' Link, please let me know if you know, thanks a million!