Can collection directories contain static files?

I’m encountering unexpected behavior, and I’m not sure if it’s a bug or a misapprehension on my part.

I’ve got a collection, people. There’s a directory, _people, containing a document,, for each person. There’s also a photo, name.jpg, in this directory for each person.

I’ve not set output to true for the collection; I render it in an index page. I want to render a thumbnail photo for each individual here.

When I build the site, a people directory is created in _site. That’s surprise #1; I wouldn’t expect a directory created to house a collection to be transformed into a like-named directory (sans the leading underscore) in the site. Surprise #2 is that the image files are copied into this directory, but they don’t appear in site.static_files.

I’m guessing that the treatment of static files in a collection directory is undefined, and I ought not to do this?

Being able to look at a repository can answer many of your questions.
Anyways, yes, Collection directories can contain static files as well.

I’m confused - your collection is called people, but there is a directory called team?

I played around with this a bit and it does look a little off. It seems like if you have static files in a collection, they will be copied to the site folder regardless of whether or not output is true or false. They also don’t show up in site.static_files or even in the collection itself if you do a loop thru the collection items.

I was testing with 3.6.

@rdyar will you be able to open an issue-ticket on GitHub with a public test-repo to reproduce the issue…?

Regarding why the OP gets a directory named teams is probably because he has a custom permalink defined

    permalink: teams/:path

I can’t be certain unless he provides a repo we all can explore…

I’ll see if I can do that - might take a day or two.

Apologies—in fact, I’m building a site for our company, and the collection, directory etc. are called team. I started my post with people to make it more generic, but then I slipped up and used the real name later in the post.

Since Ron has reproduced my results, I don’t think seeing my repo (which is private) will add any value.

Ron, you’ve reproduced the exact issue. (As I mentioned, “team” was a typo; the collection and directory have the same name.) I’m running 3.7.3.

I’m happy to open an issue myself. If you really think a test repo is warranted, I can create one. It would probably be better to add failing tests to If Ron is handy with that, it’s likely to happen quicker if he does it, but I can give it a shot.

Thanks for your replies! I’m just going to work around this, but I thought it might be an area of ambiguity in the way Jekyll works, so I thought I’d point it out.

If this is indeed a bug, then please do open a ticket at GitHub. Who knows? Perhaps a fix can be shipped with the upcoming v3.8.0

I’m not handy with that at all, go ahead and open the issue if you can!

Okay—I’ll do that tomorrow. Thanks again!

You can omit the test-repo when opening the issue ticket at GitHub. I’ve reproduced this issue on a test-repo of my own…

I did some sleuthing. The docs say:

Files in collections that do not have front matter are treated as static files and simply copied to their output location without processing.

There’s no qualification about whether output is true or false.

This concurs with @ashmaroli’s comment on issue 6410, I can expect, e.g., _people/name.jpg to be rendered to _site/people/name.jpg. So the only issue is that such files don’t appear in site.static_files (@rdyar was mistaken about their not appearing for the collection; it’s just that, confusingly, the attribute on a collection is called files, not static_files).

The reason for the omission: Reader#read_directories, which collects (among other things) the site’s static files, explicitly passes over directories that begin with _, and so omits to include any collections’ static files.

This could be simply a matter of documenting that collection static files only appear in collection.files. But I’ll open the issue and let others decide.

This is issue #6906.