Skip to content
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

Post Asset Folder feature in Hugo #1768

Closed
NuLL3rr0r opened this issue Jan 11, 2016 · 13 comments
Closed

Post Asset Folder feature in Hugo #1768

NuLL3rr0r opened this issue Jan 11, 2016 · 13 comments

Comments

@NuLL3rr0r
Copy link

I just started migrating my blog from Hexo 3.x (before that Ocropress 2.x that's why I must stay backward compatible, lots of posts and images) and I must say this issue is a huge blocker. At least it has been address by a handful of people #147 #1199 #1122 #1240 but I still see this feature lacking in Hugo as of v0.15. So, I'll explain a bit more:

Hexo has a concept called Post Asset Folder

My Hexo blog has these configurations:

permalink: blog/:year/:month/:day/:title/
new_post_name: :year-:month-:day-:title.md # File name of new posts
post_asset_folder: true

So, from now on when I create a new .md file using Hexo's new command it also create a folder by the same name in the same directory as the .md file:

2016-01-11-a-new-post.md
2016-01-11-a-new-post/

Then I put any static assets for that post in that folder and it generates the following output in the public folder:

blog/2016/01/11/a-new-post/
blog/2016/01/11/a-new-post/index.html
blog/2016/01/11/a-new-post/pic1.jpg
blog/2016/01/11/a-new-post/pic2.png
blog/2016/01/11/a-new-post/code.zip

Which makes sense. So, I do not have to create all those blog, 2016, 01 and 11 folders for all those posts I have. Beside the effort, I am sure it is very error-prone. In my estimation that makes life simpler and easier.

Hugo is a solid peace of software which beats every other static-gen out there that I've seen by any measure. It would be great to have a few lines in the config file to enable this necessary feature (could be disabled by default) for people who rely on it even if it does not make sense for its developers.

@derekperkins
Copy link
Contributor

@NuLL3rr0r: You can have a post asset folder, and I think it'll work if you say hugo new blog/2016/01/11/a-new-post/index.md

From an SEO perspective, you should drop the dates from your URL and redirect, but that's another discussion.

@NuLL3rr0r
Copy link
Author

NuLL3rr0r commented Sep 22, 2016

@derekperkins thank you for the response. Yes, I can create the folder and put my images there. But, it's not quite a post asset folder, at least by what other generators like hexo mean. Just look at the directory hierarchy:

post1.md
post1/
post2.md
post2/
post3.md
post3/

Then I can change my permalinks later in the config file to whatever I want (e.g, include dates or not). In addition to that I ran a quick test with your suggestion. And, let's say I put my pics in a .md file like this:

+++
date = "2016-09-22T23:43:48+03:30"
draft = true
title = "index"
+++

You should see the following image:

{{< figure src="H8VNr1Sg.png" title="Example Image" >}}

And this one:

![Example image](H8VNr1Sg.png)

<!-- more -->

Some other text

It won't show the image on the home page (yes, obviously inside that page it does). I believe the generator should handle the urls from home page, too. Because, if I change the permalink, it will break all my posts:

{{< figure src="/blog/2016/01/11/a-new-post/H8VNr1Sg.png" title="Example Image" >}}

![Example image](/blog/2016/01/11/a-new-post/H8VNr1Sg.png)

This one is not flexible.

@derekperkins
Copy link
Contributor

Fair enough, but I don't think people are changing their permalink structures that often... at least they shouldn't be.

Couldn't you create your own shortcode that linked to the current folder? I think there's enough data in the .Node/.Page context, but I'm not sure. Sounds like a good PR.

This is somewhat off-topic, but I saw it today and it reminded me of this post.
image
https://twitter.com/dan_shure/status/776797943961640960

@NuLL3rr0r
Copy link
Author

NuLL3rr0r commented Sep 28, 2016

Thanks for the info. Actually latest issue of Moz Top 10 had an article on dates in URL which I found interesting, too.

The shortcode is a nice idea. Actually, it seems to be the most feasible one at the moment. I'll try to implement a my own shortcode system on a subdomain or a spare domain. Thanks.

@bep bep added the Stale label Feb 28, 2017
@bep
Copy link
Member

bep commented Feb 28, 2017

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

The resources of the Hugo 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 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, and you feel that it is still relevant and valuable, please tell us why.

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

@bep
Copy link
Member

bep commented Mar 1, 2017

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the 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, and you feel that it is still relevant and valuable, please tell us why.

@gima
Copy link

gima commented Mar 10, 2017

Trying Hugo once again, and this problem still exists (previously here #1199).


Filesystem layout:

content/page/my_first_blog_post/index.md
content/page/my_first_blog_post/prettypicture.jpg

config.toml:

[permalinks]
page = "/:title/"

Output after running hugo:

public/my_first_blog_post/index.html
public/page/my_first_blog_post/prettypicture.jpg

Does this demonstrate the problem adequately?
The bug is: Permalinks configuration doesn't affect assets (files in the same folder as the post, index.md, itself). This case demonstrates that it very clearly should.

@bhaskarvk
Copy link

+1 it would be really nice to have a post_asset_folder that is handled the same way as the post is and is moved according to the permaurl settings.
This is kinda really a big deal.

@n10v n10v removed the Stale label Apr 11, 2017
@skadauke
Copy link

skadauke commented Jun 7, 2017

I had a similar situation as @gima with blogdown (a wrapper for hugo written in the R language) where I had the following two files

content/post/2017-06-06-imagetest.Rmd
content/post/image.png

Blogdown and Hugo then created:

public/2017/06/06/imagetest/index.html:
public/post/image.png

It seems like what should happen is for Hugo to copy overimage.png to public/2017/06/06/imagetest/

I ended up solving this issue by making the following changes in config.toml:

uglyurls = true
#[permalinks]
# post = "/:year/:month/:day/:slug/"

Now hugo creates:

public/post/imagetest.html
public/post/image.png

Which works for me.

@marcojakob
Copy link

@skadauke You could also put the files in subfolders like this:

content/post/2017/06/06/index.Rmd
content/post/2017/06/06/image.png

Hugo should create the following with uglyurls = false:

public/post/2017/06/06/index.html
public/post/2017/06/06/image.png

@IntegralExplorer
Copy link

IntegralExplorer commented Aug 28, 2017

Working Now - My observations:
I kept trying to get the images to display in my site by changing the image path. When I made a set of changes to the text, not the image path, of another post and saved it I could see the images. At that moment I had two files with the exact path to an image.

I kept trying to adjust the path in the file that would not display the image in various ways including copying and pasting from the one that worked and refreshing the web page. Still not working.

But, when I changed text in the page and saved it, the image was rendered.

Hope this hint helps. I'll let you know any other nuance I come across on this here as I will be doing quite a bit of rewriting today and exercising the images.

Original Post With My Use Case Before Getting It To Work:
I want to emphasize how important it is to be able to easily add a link to images and have it automatically render is and for it to work simply, intuitively, and naturally. It is high friction now.

My Use Case:

  1. I create visual taxonomies stored as both jpg and svg files for different purposes across a site.
  2. I take snapshots of video frames and add context ovals or arrows to point at the visual taxonomies as I focus a students attention on the area of discussion.

The graphics provide a context that keeps being referred to over and over, with the image used on different pages/posts, so a student can form a mental model of the big picture while drilling in and out into the details. Much more reuse than one offs.

I need to store my master images in one directory path (which may be organized into subdirectories) and point at them by relative reference from many pages.

  1. The images change rarely and if they do all content needs to be updated.
  2. I want to "maintain" only the central set of images.
  3. Caveat: I want the option to manually manage an image and point to it with relative reference where I put it. I would only do this with images that are "specific" to the subject in the page or post. This may be very specific images, say a photo jpg or one-off screen capture but in general rare for my needs.
  4. Any page may have a "central image" that needs to refresh on the page when it changes and it may have a one off that will not change over time.

This is always needed in any content management. With any site with a lot of content, there will be the need to organize it in different and appropriate ways. And for static site generators this should just work directly. I am surprised it doesn't here given how good Hugo has been to this point. I have been having fun until about 3 hours ago. :)

Personally, I have had no success yet with all the combination of solutions offered in the many blog posts related to this problem of "pointing" at an image resource in markdown, and having it render in the localhost:1313 pages. I can see the text description change but never an image to view.

This is a fundamental problem.

I have been moving assets from my Wordpress site and having a great deal of fun over the last 30+- hours thinking about how great this experience with the JAMStack using Hugo is until the last few hours trying to get this to work.

I propose:

  1. adding an "imageDir" = "img" which would be at the root (public) or root/static by default (where I interpreted/thought the documentation suggested to put images).

and, optionally,

"relativeToContent" so a person can choose a location to store their images relative to their content in custom structures (including with the content) (nice to have for me, but rare)

in that order.

  1. any automation in generating the web site would be aware of this directory so relative paths would be to and through "root", relative to content, or both

I do not want extra "copies" of an image automatically placed into a "content" directory associated with a page or post. Let git manage versions. Please no unplanned, or work-around duplicates to manage.

I hope this helps. I will continue experimenting, but for now, after reading others comments, I wanted to raise awareness of my experience here today. And thanks to those who work on it. Hugo is great. I want to continue using it if I can overcome this issue. Any additional pointers are appreciated.

@stale
Copy link

stale bot commented Dec 6, 2017

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo 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 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, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

@stale stale bot added the Stale label Dec 6, 2017
@stale stale bot closed this as completed Dec 27, 2017
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants