Non-MD files in the content directory (like jpg's and png's) end up as html's

[RubenN]

When I put non-md files in the content directory, they should just be copied over (untouched!).

Now they end up as html's

[spf13]

This is a bug, but I don't think you'll want the fixed behavior either.

/content is for documents that need processing
/static is for content that doesn't need processing

I think the fix here should be to ignore any filetype hugo doesn't know how to process.

Does this make sense? Is there a reason for putting non parsed files like pngs in content vs static?

[RubenN]

I would say that content should be what the term says: a collection of info
like documents, pictures, etc.
Static should be for the interchangable parts like layouting, css, etc.

The most important reason is to keep content together (pictures in a blog
for example).

I agree that ignoring is the most sensible thing to do!

2013/12/3 Steve Francia notifications@github.com

This is a bug, but I don't think you'll want the fixed behavior either.

/content is for documents that need processing
/static is for content that doesn't need processing

I think the fix here should be to ignore any filetype hugo doesn't know
how to process.

Does this make sense? Is there a reason for putting non parsed files like
pngs in content vs static?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/147#issuecomment-29737091
.

[robotamer]

I think the way content is interpreted here is: Files that need processing.
Static files are js, css but also image, video, pdf
To keep organized you could do something like
/static/image/blog/...

[robotamer]

Also there is one more interesting thing.

There are is a static folder and it has a sub folder called static as well.

like this: static/static/js
if you place a static file in to the first static folder it shows up in the root of the public folder.
Haven't tested this but you could create a folder in there as well.

looking like this `static/blog/image/foo.jpeg

Then your public folder will be organized the way you are asking for..

[spf13]

Correct.

Best,
Steve

-- 
Steve Francia
http://stevefrancia.com
http://spf13.com
http://twitter.com/spf13

On December 4, 2013 at 2:23:10 PM, Dennis T Kaplan (notifications@github.com) wrote:

Also there is one more interesting thing.

There are is a static folder and it has a sub folder called static as well.

like this: static/static/js

if you place a static file in to the first static folder it shows up in the root of the public folder.
Haven't tested this but you could create a folder in there as well.

looking like this `static/blog/image/foo.jpeg

Then your public folder will be organized the way you are asking for..

—
Reply to this email directly or view it on GitHub.

[luckyrandom]

Is there any update on this issue? It's inconvenient to put all images in separate directory, especially when plots are generated by scripts supplementing the post.

On the other hand, care must be taken when images or other assets are put in local directory. It may encourage the use of relative path, which may link to the wrong path when partial rendering is included by paginations or other pages.

I checked a few popular static site generator. wintersmith seems to be the only one to support local assets and relative links. It patches markdown renderer to support that, and it may not be a easy job if multiple renderers need to be patched.

[cburgdorf]

I think separating strictly by file type is backwards. If I have a picture only for one post, I want it to be next to my post.md file.

[spf13]

I see your point, but I'd like to clarify the intent here.

We're not separating by file type, but by purpose.

/Content is meant to be compiled by hugo.

/static will be copied without any processing

HTML and md are welcome in either location. If in /static they will be copied without being touched.

I'm willing to concede that this separation may not be necessary and perhaps determining intent only by file type would be appropriate, but it is more limited and would make the watching capability less efficient and more complicated.

Steve Francia
spf13.com
@spf13

On Apr 11, 2014, at 4:18 PM, Christoph Burgdorf notifications@github.com wrote:

I think separating strictly by file type is backwards. If I have a picture only for one post, I want it to be next to my post.md file.

—
Reply to this email directly or view it on GitHub.

[cburgdorf]

Understood. Would still like to have that feature :) I'll investigate the possibilities/impact down the road once I got my feet wet with the code base. Still struggling to get my environment set up.

[jcw]

Splitting files by how Hugo treats them is a bit of a software-centric approach, to be honest. When adding a blog post, it really is more convenient to create the post and everything it needs in one place. Even systems which split things up (WordPress, MarsEdit) have moved towards making it easy to do everything in one spot (usually via drag and drop, which is not feasible with Hugo, since it doesn't deal with the editing process itself).

I vote a big +1 to support images next to the text of a post/article.
This should be all about the workflow of people, not how Hugo sees things.

[spf13]

@jcw I think that's a pretty compelling argument. Let's plan on improving this for v0.12.

[RubenN]

Excellent, I couldn't agree more!

Op maandag 19 mei 2014 heeft Steve Francia notifications@github.com het
volgende geschreven:

@jcw https://github.com/jcw I think that's a pretty compelling
argument. Let's plan on improving this for v0.12.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/147#issuecomment-43458988
.

[jcw]

Thanks for considering this, Steve. I'm really looking forward to be able to use this - would like to convert a large weblog filled with images over to hugo. The combination of markdown, speed, and flexibility (plus the fact that you're actively developing it further) makes it a no-brainer for writing just about anything for the web, IMO.

[oscar-b]

@spf13 Just wanted to give my +1 to this as well. I started looking at migrating a clients portfolio site to Hugo (currently in ZenPhoto), but I quickly realized that there is no way to dynamically resize images. I would want to put the original images in albums, and being able to generate thumbnails and appropriate sized versions from the originals (think <picture></picture> with @2x and @3x versions).

In this context (and your own roadmap which lists "Dynamic image resizing via shortcodes"), content images should go to /content, since they need processing by Hugo :)

[mohae]

Some thoughts on this.

Support a per fileType processor that would process content files based on their file extension.
If a processor for that fileType is not implemented, the file is not processed.

This would allow for current functionality, in regards to .md files, support other markup languages by allowing processors to be added for them, and various image processing, when implemented.

I'm sure I'm missing some obvious stuff here. Any thoughts?