I would say this will happen, and soon, @spf13? Maybe a good candidate for 0.14.
In it’s first form - I guess what people (me included) ask for is that “unknown content types” (those with no content handler in Hugo) will be synced just as they would be if placed in /static.
It’s not super hard to code, but it’s really hard to get everything right. Once we release this a lot of people will depend on it and it will be pretty hard to change.
This is really necessary for large documentation projects. It is much easier for contributors to see the images relative to the directory in which they appear. For example:
We have a large documentation project and the files live in multiple repositories as well as act as content for our official documentation. Our programmers want to ensure that documentation “works” in Github too; this would support that.
[quote=“moxiegirl, post:9, topic:51, full:true”]
This is really necessary for large documentation projects. It is much easier for contributors to see the images relative to the directory in which they appear. [/quote]
To me the way it’s done in Nikola is even better, iow.
So, in the source material, you are requiring a separate subdirectory to house the images? That seems like it would create a lot of subdirectories to house images — as opposed to a single images directory.
So, in the source material, you are requiring a separate subdirectory to
house the images? That seems like it would create a lot of subdirectories
to house images — as opposed to a single images directory.
Well, the point is that you do not require having separate subdirectory for
each post, but you can have it.
There is also possibility - in Nikola - to have them all in a single ‘images’
directory, but then I have to take care to properly name all those images
instead of simply have them in appropriate subdirectory.
+1 to this. I write a log of blog posts that are “how-to” posts which include screenshots. I can see how this could get really challenging really quickly with having to keep the images separate, although I can see how the “subdirectory for each post” would be a workaround. Definitely challenging.
Partly in 0.14. You can have media files in /content, so it’s possible to group images and content in the same folder, but there are more work in this department.
Not much have happened in this department for 0.15, other than an important performance fix.
This would also be my question.
I want to save images next to md files for management purposes. I also want show the whole content - with images - on both list pages, as well as the article pages.
I could not figure out how to import the path + slug of the article into the ‘figure’ shortcode in a way that would work on list pages like the blog frontpage.
is there any progress being made on this ? I’m new to Hugo and I just tried a few different settings trying to keep my content and images in the same folder. so far, my end result just put the image under /public/post/folder_name/nameimage.jpg and the html file under /public/year/month/folder_name/index.html
I don’t quite understand the situation here. The topic has been raised in 2015, it was said it’s not super hard to code and it would be coming soon, but 2 years later in version 20.7 I don’t find it resolved. Is this pending development or is considered solved?
I can’t see any other way than to use absolute path to reference the content that lies just next to my .md file. Is there at least any way to make it nicer by using some kind of variable to capture the url that points to the directory of the .md file? I’ve read the docs and tried to use variable in my .md but it doesn’t seem to work. Any hints how make this work natively?
This is a must if you are doing lot of blog posts or documentation. Also for non technical users, they can’t be expected to find what folder the image goes and add appropriate link. Also this will work with github and show you the image. Currently, github does not show you the image in your repo.
Hugo is open source. Contributors like myself develop what they need or what they think is interesting, or whatever. The fastest way to get it done is always to do it yourself. Of course, if that is not an option – then wait.
You would kind of have to look at most of the core Hugo code to be able to pull this off, start at the hugolob/page.go and see how that is used. I would also suggest you create some kind of proposal/design before spending too much time coding.