-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add resources to top level sections without a _index.md file #11179
Comments
Regarding Option 2 in my previous comment: it would improve link/image portability in conjunction with render hooks. This content structure is common in Hugo and in other markdown environments (GitHub, Obsidian, etc.):
content/posts/post-1.md
An image render hook that looks for a page resource won't find the image, and that's how it should be. But, if content/posts were a branch bundle (as .BundleType reports today), the render hook could fall back to the current section. A simplified example:
This works fine today in directories with _index.md files. But the point is, for a top level section, it is common to not have an _index.md file. I understand that this won't work with directories further down the tree that lack _index.md files, and that's fine. The more common scenario relates to the top level section. This is, to some extent, related to #4583. Finally, I'm also fine just correcting .BundleType for the top level sections. |
Or:
So, this issue is certainly as designed, as
|
OK, thinking about this, I have fixed this in a branch that I had planned to get out the door soon. |
Duplicate of #11439 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I'm not sure if this is a bug or an enhancement.
This content:
With this code in layouts/_default/home.html:
Produces:
If the "books" section were a branch bundle, then "section.jpg" should be available as a page resource.
Two options:
Option 2 makes more sense to me, but I don't know what it would break.
Same results with v0.54.0 -- this isn't anything new.
The text was updated successfully, but these errors were encountered: