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

Closed
RubenN opened this Issue Dec 3, 2013 · 66 comments

Comments

Projects
None yet
@RubenN
Contributor

RubenN commented Dec 3, 2013

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 comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Dec 3, 2013

Contributor

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?

Contributor

spf13 commented Dec 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@RubenN

RubenN Dec 4, 2013

Contributor

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/spf13/hugo/issues/147#issuecomment-29737091
.

Contributor

RubenN commented Dec 4, 2013

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/spf13/hugo/issues/147#issuecomment-29737091
.

@robotamer

This comment has been minimized.

Show comment
Hide comment
@robotamer

robotamer Dec 4, 2013

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/...

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

This comment has been minimized.

Show comment
Hide comment
@robotamer

robotamer Dec 4, 2013

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..

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

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Dec 4, 2013

Contributor

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.

Contributor

spf13 commented Dec 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@luckyrandom

luckyrandom Mar 16, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@cburgdorf

cburgdorf Apr 11, 2014

Contributor

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.

Contributor

cburgdorf commented Apr 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Apr 11, 2014

Contributor

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.

Contributor

spf13 commented Apr 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@cburgdorf

cburgdorf Apr 14, 2014

Contributor

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.

Contributor

cburgdorf commented Apr 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jcw

jcw May 17, 2014

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.

jcw commented May 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 19, 2014

Contributor

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

Contributor

spf13 commented May 19, 2014

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

@RubenN

This comment has been minimized.

Show comment
Hide comment
@RubenN

RubenN May 19, 2014

Contributor

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/spf13/hugo/issues/147#issuecomment-43458988
.

Contributor

RubenN commented May 19, 2014

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/spf13/hugo/issues/147#issuecomment-43458988
.

@jcw

This comment has been minimized.

Show comment
Hide comment
@jcw

jcw May 21, 2014

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.

jcw commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@oscar-b

oscar-b Sep 4, 2014

Contributor

@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 :)

Contributor

oscar-b commented Sep 4, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae Sep 4, 2014

Contributor

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?

Contributor

mohae commented Sep 4, 2014

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?

@stou

This comment has been minimized.

Show comment
Hide comment
@stou

stou Oct 10, 2014

Contributor

I aggree with @jcw that separating content text, and content images and other media in separate folders feels awkward.

Maybe someting like the processing chain used by docpad could be useful:
https://docpad.org/docs/begin#a-note-on-rendering

Just an idea

Contributor

stou commented Oct 10, 2014

I aggree with @jcw that separating content text, and content images and other media in separate folders feels awkward.

Maybe someting like the processing chain used by docpad could be useful:
https://docpad.org/docs/begin#a-note-on-rendering

Just an idea

@spf13 spf13 self-assigned this Oct 19, 2014

@aledalgrande

This comment has been minimized.

Show comment
Hide comment
@aledalgrande

aledalgrande Nov 8, 2014

+1 for separating by context and not application/processing based

+1 for separating by context and not application/processing based

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Nov 8, 2014

Contributor

@stou ,

I've done some work on this already and there's a bit more to do still. I'm a bit confused about your comment about docpad. Docpad takes the exact same approach as Hugo does now by placing all binary files (images) into the /static directory.

I understand the chaining abstraction they provide, but to me that seems like a novelty. Why would anyone what to process files from one markup into another into another? (md/asciidoc/??) -> html seems sufficient.

Contributor

spf13 commented Nov 8, 2014

@stou ,

I've done some work on this already and there's a bit more to do still. I'm a bit confused about your comment about docpad. Docpad takes the exact same approach as Hugo does now by placing all binary files (images) into the /static directory.

I understand the chaining abstraction they provide, but to me that seems like a novelty. Why would anyone what to process files from one markup into another into another? (md/asciidoc/??) -> html seems sufficient.

@stou

This comment has been minimized.

Show comment
Hide comment
@stou

stou Nov 9, 2014

Contributor

@spf13
About the chaining
I think I got mixed up with some of the comment in issue #320

I still think the chaining could be a usefull way to configure processing of files e.g.:

file.html.md --> file.html
file.js.coffee --> file.js
file.html.jade --> file.html
file.xml.jade --> file.xml
file.css.scss --> file.css

if you add more preprocessors in the future.
Consider this a feature request, but maybe the file extension idea could be used as part of the solution to issue #320 instead of adding a lot of configuration options / extra settings in front matter.

Contributor

stou commented Nov 9, 2014

@spf13
About the chaining
I think I got mixed up with some of the comment in issue #320

I still think the chaining could be a usefull way to configure processing of files e.g.:

file.html.md --> file.html
file.js.coffee --> file.js
file.html.jade --> file.html
file.xml.jade --> file.xml
file.css.scss --> file.css

if you add more preprocessors in the future.
Consider this a feature request, but maybe the file extension idea could be used as part of the solution to issue #320 instead of adding a lot of configuration options / extra settings in front matter.

@kot-behemoth

This comment has been minimized.

Show comment
Hide comment
@kot-behemoth

kot-behemoth Jan 7, 2015

Any updates on this? Being able to have each post contain all the assets (be it images or scripts) next to the post's text would be invaluable. I'm thinking of moving to Hugo, so had a look at the docs, but couldn't find a confirmation of being able to do this just yet.

Thanks!

Any updates on this? Being able to have each post contain all the assets (be it images or scripts) next to the post's text would be invaluable. I'm thinking of moving to Hugo, so had a look at the docs, but couldn't find a confirmation of being able to do this just yet.

Thanks!

@mrkishi

This comment has been minimized.

Show comment
Hide comment
@mrkishi

mrkishi Jan 7, 2015

Any updates on the custom processors, as well? It's an idea that also interests me. For instance, one could optimize images on build.

Honestly, I found the content folder somewhat misleading as it's not meant to hold arbitrary site content, but processable inputs.

Also, if we are to think them as raw, unprocessed documents, it makes sense that's the place we'd place related data, full resolution images and etc., as well. They would then be processed on build: charts generated, images resized and optimized, html generated. Of course, a pass-through processor is still a valid processor. :)

As not every file could (easily) have a front matter, @stou's file extensions idea seems like an acceptable solution for processor selection, if slightly magic. Some ideas of what may be possible:

  • /content/articles/lengthy-research.md: Article.
  • /content/articles/lengthy-research/chart1.pngchart.json: json to png charting.
  • /content/articles/lengthy-research/image1.optim.png: image optimization.
  • /content/articles/lengthy-research/image2.optim-600x150.png: image optimization and resizing.
  • /content/articles/lengthy-research/image3.png: pass-through?

mrkishi commented Jan 7, 2015

Any updates on the custom processors, as well? It's an idea that also interests me. For instance, one could optimize images on build.

Honestly, I found the content folder somewhat misleading as it's not meant to hold arbitrary site content, but processable inputs.

Also, if we are to think them as raw, unprocessed documents, it makes sense that's the place we'd place related data, full resolution images and etc., as well. They would then be processed on build: charts generated, images resized and optimized, html generated. Of course, a pass-through processor is still a valid processor. :)

As not every file could (easily) have a front matter, @stou's file extensions idea seems like an acceptable solution for processor selection, if slightly magic. Some ideas of what may be possible:

  • /content/articles/lengthy-research.md: Article.
  • /content/articles/lengthy-research/chart1.pngchart.json: json to png charting.
  • /content/articles/lengthy-research/image1.optim.png: image optimization.
  • /content/articles/lengthy-research/image2.optim-600x150.png: image optimization and resizing.
  • /content/articles/lengthy-research/image3.png: pass-through?
@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Jan 7, 2015

Contributor

I like this idea, but @stou's file extension idea only allows for a single result from the process. What if I want to make a thumbnail, medium size and full size from a single image?

Contributor

spf13 commented Jan 7, 2015

I like this idea, but @stou's file extension idea only allows for a single result from the process. What if I want to make a thumbnail, medium size and full size from a single image?

@mrkishi

This comment has been minimized.

Show comment
Hide comment
@mrkishi

mrkishi Jan 7, 2015

How about introducing the concept of external alternatives to front matter? Appendix, lol?

This could make things slightly more consistent: every input (to be processed) must have a front matter, either embedded (markdown's front matter) or external (stand alone yaml and toml files that select the processor?). On the other hand, it adds to the project complexitivity and, potentially, build time.

  • /content/articles/test.md: embedded front matter.
  • /content/articles/test/image.png: means nothing by itself.
  • /content/articles/test/image.toml: what to do with image.png.

This could get annoying pretty fast, though. Another option would be to add the processing options to the pages' front matter:

  • /content/articles/test/image-{1,2,3}.png: do nothing by themselves.
  • /content/articles/test.md: embedded front matter saying hey, include images 1, 2 and 3, using preprocessor x with arguments y and z.

I think this could work, but it would limit our ability to process arbitrary files: they would have to "belong" to an article. Perhaps on top of that there could exist support for stand alone .toml and .yaml files, that simply contain instructions for other files, similarly to the first suggestion but without the 1:1 toml/file relation.

mrkishi commented Jan 7, 2015

How about introducing the concept of external alternatives to front matter? Appendix, lol?

This could make things slightly more consistent: every input (to be processed) must have a front matter, either embedded (markdown's front matter) or external (stand alone yaml and toml files that select the processor?). On the other hand, it adds to the project complexitivity and, potentially, build time.

  • /content/articles/test.md: embedded front matter.
  • /content/articles/test/image.png: means nothing by itself.
  • /content/articles/test/image.toml: what to do with image.png.

This could get annoying pretty fast, though. Another option would be to add the processing options to the pages' front matter:

  • /content/articles/test/image-{1,2,3}.png: do nothing by themselves.
  • /content/articles/test.md: embedded front matter saying hey, include images 1, 2 and 3, using preprocessor x with arguments y and z.

I think this could work, but it would limit our ability to process arbitrary files: they would have to "belong" to an article. Perhaps on top of that there could exist support for stand alone .toml and .yaml files, that simply contain instructions for other files, similarly to the first suggestion but without the 1:1 toml/file relation.

@bguiz

This comment has been minimized.

Show comment
Hide comment
@bguiz

bguiz Jan 23, 2015

Think we might be getting a little side tracked here, with the discussion on preprocessing files. That's a nice to have for non markdown files, but for a first cut, I will be quite happy in *.md files are the only ones that are processed, and everything else just gets copied as-is.

Creating a rails or docpad style asset pipeline based on multiple file extensions is a nice to have, but I think simply being able to put images referenced in a markdown file in the same folder as the markdown file will aid authoring in Hugo quite a lot.

bguiz commented Jan 23, 2015

Think we might be getting a little side tracked here, with the discussion on preprocessing files. That's a nice to have for non markdown files, but for a first cut, I will be quite happy in *.md files are the only ones that are processed, and everything else just gets copied as-is.

Creating a rails or docpad style asset pipeline based on multiple file extensions is a nice to have, but I think simply being able to put images referenced in a markdown file in the same folder as the markdown file will aid authoring in Hugo quite a lot.

@jcw

This comment has been minimized.

Show comment
Hide comment

jcw commented Jan 23, 2015

+1

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jan 23, 2015

Member

+1 what bguiz says

Member

bep commented Jan 23, 2015

+1 what bguiz says

@stou

This comment has been minimized.

Show comment
Hide comment
@stou

stou Jan 23, 2015

Contributor

+1 I agree. The processing chain can easily be postponed

Contributor

stou commented Jan 23, 2015

+1 I agree. The processing chain can easily be postponed

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jan 23, 2015

Member

One note to he who implements the "copy files from content without processing" -- it would be very nice if static images/css could be treated as their cousins in the /static folder for livereloads (soft, not hard refreshes).

Member

bep commented Jan 23, 2015

One note to he who implements the "copy files from content without processing" -- it would be very nice if static images/css could be treated as their cousins in the /static folder for livereloads (soft, not hard refreshes).

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Jan 23, 2015

Contributor

I'm 90% done with this today.

Steve Francia
spf13.com
@spf13

On Jan 23, 2015, at 11:02 AM, Bjørn Erik Pedersen notifications@github.com wrote:

One note to he who implements the "copy files from content without processing" -- it would be very nice if static images/css could be treated as their cousins in the /static folder for livereloads (soft, not hard refreshes).


Reply to this email directly or view it on GitHub.

Contributor

spf13 commented Jan 23, 2015

I'm 90% done with this today.

Steve Francia
spf13.com
@spf13

On Jan 23, 2015, at 11:02 AM, Bjørn Erik Pedersen notifications@github.com wrote:

One note to he who implements the "copy files from content without processing" -- it would be very nice if static images/css could be treated as their cousins in the /static folder for livereloads (soft, not hard refreshes).


Reply to this email directly or view it on GitHub.

@dcorb

This comment has been minimized.

Show comment
Hide comment
@dcorb

dcorb Feb 7, 2015

Glad to arrive to this issue and it's 90% ready! This improves the UX of writing complex articles.

I was thinking to have a developer blog with "demo.js" or "demo.css" per article or even JSON files .. so each article could be customized. Not only it would be useful for dev blogs.. also is a trend called "JavaScript Journalism", like you can see in some New York Times articles.

dcorb commented Feb 7, 2015

Glad to arrive to this issue and it's 90% ready! This improves the UX of writing complex articles.

I was thinking to have a developer blog with "demo.js" or "demo.css" per article or even JSON files .. so each article could be customized. Not only it would be useful for dev blogs.. also is a trend called "JavaScript Journalism", like you can see in some New York Times articles.

@gima

This comment has been minimized.

Show comment
Hide comment
@gima

gima Feb 15, 2015

+1
The current logic feels counter-intuitive. Some posts need assets, such as images. These images are, by their name, assets, and hence belong with the post. I shouldn't have to worry about where they are located as a result of rendering the website, but currently I have to. I have to either refer to them by their rendered path or use the static folder trick to mirror the post's directory structure, and place my assets there, afterwhich I can then refer to them in the post simply by their name.

This is awkward. Not only for the extra work, but also for the fact that the filesystem already provides for a way for me to bundle things together that belong, together, by using directories. Now if I have to mirror this directory structure, I have broken the connection between the post and it's assets [in the filesystem], then during rendering Hugo rebuilds the connection, and as a result the outcome is the same as if Hugo just let me have my damn files in the post's directory and be done with it.

gima commented Feb 15, 2015

+1
The current logic feels counter-intuitive. Some posts need assets, such as images. These images are, by their name, assets, and hence belong with the post. I shouldn't have to worry about where they are located as a result of rendering the website, but currently I have to. I have to either refer to them by their rendered path or use the static folder trick to mirror the post's directory structure, and place my assets there, afterwhich I can then refer to them in the post simply by their name.

This is awkward. Not only for the extra work, but also for the fact that the filesystem already provides for a way for me to bundle things together that belong, together, by using directories. Now if I have to mirror this directory structure, I have broken the connection between the post and it's assets [in the filesystem], then during rendering Hugo rebuilds the connection, and as a result the outcome is the same as if Hugo just let me have my damn files in the post's directory and be done with it.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Feb 16, 2015

Contributor

100% agree. Working on making it better.

Contributor

spf13 commented Feb 16, 2015

100% agree. Working on making it better.

@spf13 spf13 modified the milestones: v0.13, v0.14 Feb 22, 2015

@marcojakob

This comment has been minimized.

Show comment
Hide comment
@marcojakob

marcojakob Mar 16, 2015

+1 It would be awesome to be able to store assets next to the content files.

As I've outlined in File-Based CMS and Hugo as Static Site Generator it would be great to also allow .toml files as content instead of .md files.

+1 It would be awesome to be able to store assets next to the content files.

As I've outlined in File-Based CMS and Hugo as Static Site Generator it would be great to also allow .toml files as content instead of .md files.

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 Apr 20, 2015

@spf13 You stated the foundation is already in master. Could we get an example of how to use it? I'm currently getting the errors like this:

Hugo Static Site Generator v0.14-DEV-BE01F84 BuildDate: 2015-04-20T08:25:34-04:00

CRITICAL: 2015/04/20 Errors reading pages: Error:No handler found for Dell_H2C_Technology_Hybrid_Cooling_for_Overclocked_CPUs.pdf
Error:No handler found for R201623_Silicon_Image_SIL3132_Controller.zip
Error:No handler found for Utility-Alienware_AlienFX-R202930.zip
Error:No handler found for Utility-Dell_XPS_Thermal_Monitor_A051.0.0.11.zip
Error:No handler found for bios_DellXps730xBios_A11b.zip
Error:No handler found for AlienFX_Lights.png
Error:No handler found for MCBBinaryMap-20100203.xbin

Out of all comments, @gima said it best: it is akward and the file system already provides me a way to organize with directories. 👍

My current blog, started way back in 2002, has been through 3 serious "technology/generator" changes. In doing so, and preventing broken links, I have a wide swath of existing static content next to posts and articles. Things like:

/blog/archives/2015-02-22-hello-world.aspx
/blog/archives/images/hello-world.jpg
/blog/2nd-overhaul-posts.html
/blog/images/newer-images-and-thumbnails-here/...
/current-version-at-root.html
/images/different-format-images

And I have quite a few videos, PDFs and such lined up next to their posts.

I liked Octopress exactly for this, as I was free to create any directory and/or file I wanted anywhere, and it would be copied over in that exact place. I will admit that Hugo's forced separation approach irked me for some time - and still does. I haven't launched my new overhaul yet because of these restrictions - I don't want to separate 1000s of posts and content.

Asking me to break up my static site for a static migration is a deal breaker.

Octopress (aka Jekyll) allowed you to create your own structure - and it would only process files by their extension type. .html files are treated differently than .md files. Have a new .adoc type? No problem, copy a plugin (or write your own) to process that file extension. Have files with .gzip, .tar.gz, .zip, .7z, .7zip and .rar extensions? No problem, they are copied as-is and not processed/touched.

^- Hey, someone had to mention Octopress/Jekyll already does this in this thread (and kind of trains you to do this).

@spf13 You stated the foundation is already in master. Could we get an example of how to use it? I'm currently getting the errors like this:

Hugo Static Site Generator v0.14-DEV-BE01F84 BuildDate: 2015-04-20T08:25:34-04:00

CRITICAL: 2015/04/20 Errors reading pages: Error:No handler found for Dell_H2C_Technology_Hybrid_Cooling_for_Overclocked_CPUs.pdf
Error:No handler found for R201623_Silicon_Image_SIL3132_Controller.zip
Error:No handler found for Utility-Alienware_AlienFX-R202930.zip
Error:No handler found for Utility-Dell_XPS_Thermal_Monitor_A051.0.0.11.zip
Error:No handler found for bios_DellXps730xBios_A11b.zip
Error:No handler found for AlienFX_Lights.png
Error:No handler found for MCBBinaryMap-20100203.xbin

Out of all comments, @gima said it best: it is akward and the file system already provides me a way to organize with directories. 👍

My current blog, started way back in 2002, has been through 3 serious "technology/generator" changes. In doing so, and preventing broken links, I have a wide swath of existing static content next to posts and articles. Things like:

/blog/archives/2015-02-22-hello-world.aspx
/blog/archives/images/hello-world.jpg
/blog/2nd-overhaul-posts.html
/blog/images/newer-images-and-thumbnails-here/...
/current-version-at-root.html
/images/different-format-images

And I have quite a few videos, PDFs and such lined up next to their posts.

I liked Octopress exactly for this, as I was free to create any directory and/or file I wanted anywhere, and it would be copied over in that exact place. I will admit that Hugo's forced separation approach irked me for some time - and still does. I haven't launched my new overhaul yet because of these restrictions - I don't want to separate 1000s of posts and content.

Asking me to break up my static site for a static migration is a deal breaker.

Octopress (aka Jekyll) allowed you to create your own structure - and it would only process files by their extension type. .html files are treated differently than .md files. Have a new .adoc type? No problem, copy a plugin (or write your own) to process that file extension. Have files with .gzip, .tar.gz, .zip, .7z, .7zip and .rar extensions? No problem, they are copied as-is and not processed/touched.

^- Hey, someone had to mention Octopress/Jekyll already does this in this thread (and kind of trains you to do this).

@bguiz

This comment has been minimized.

Show comment
Hide comment
@bguiz

bguiz Apr 21, 2015

@eduncan911 Yup, you're venting the very same frustrations that I have with Hugo, when I commented on this thread earlier: #147 (comment)

Think we might be getting a little side tracked here, with the discussion on preprocessing files. That's a nice to have for non markdown files, but for a first cut, I will be quite happy in *.md files are the only ones that are processed, and everything else just gets copied as-is.
Creating a rails or docpad style asset pipeline based on multiple file extensions is a nice to have, but I think simply being able to put images referenced in a markdown file in the same folder as the markdown file will aid authoring in Hugo quite a lot.

Rather than whitelist a select number of file extensions which should get pre-processed, and error on everything else, I would much rather have a select number of extensions which get pre-processed, and have everything else simply pass through, by simply getting copied from the source folder to the destination folder.

I am currently using Hugo on a couple of static sites, but am still stuck on Docpad for my blog. I would very much like to switch that to Hugo too, but I am waiting for this issue to pan out, mainly due to me not wanting to copy images that are currently in the same folder as my markdown files into a separate parallel folder structure - it would simply be way too much tedious work!

@spf13 could we please get files extensions without a handler simply copied across?

bguiz commented Apr 21, 2015

@eduncan911 Yup, you're venting the very same frustrations that I have with Hugo, when I commented on this thread earlier: #147 (comment)

Think we might be getting a little side tracked here, with the discussion on preprocessing files. That's a nice to have for non markdown files, but for a first cut, I will be quite happy in *.md files are the only ones that are processed, and everything else just gets copied as-is.
Creating a rails or docpad style asset pipeline based on multiple file extensions is a nice to have, but I think simply being able to put images referenced in a markdown file in the same folder as the markdown file will aid authoring in Hugo quite a lot.

Rather than whitelist a select number of file extensions which should get pre-processed, and error on everything else, I would much rather have a select number of extensions which get pre-processed, and have everything else simply pass through, by simply getting copied from the source folder to the destination folder.

I am currently using Hugo on a couple of static sites, but am still stuck on Docpad for my blog. I would very much like to switch that to Hugo too, but I am waiting for this issue to pan out, mainly due to me not wanting to copy images that are currently in the same folder as my markdown files into a separate parallel folder structure - it would simply be way too much tedious work!

@spf13 could we please get files extensions without a handler simply copied across?

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Apr 21, 2015

Contributor

Yes. I'll work on that this week.

Contributor

spf13 commented Apr 21, 2015

Yes. I'll work on that this week.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Apr 29, 2015

Member

"I'm 90% done with this today."

This was January. I understand it's not uncommon in software development that the last 10% is the hardest - but is it possible to get a realistic estimate? Should we remove this from the v.0.14 milestone?

Member

bep commented Apr 29, 2015

"I'm 90% done with this today."

This was January. I understand it's not uncommon in software development that the last 10% is the hardest - but is it possible to get a realistic estimate? Should we remove this from the v.0.14 milestone?

@bguiz

This comment has been minimized.

Show comment
Hide comment
@bguiz

bguiz Apr 30, 2015

I'd really really like to see this feature make it into the next release,
can we please keep it in the milestone?

W: http://bguiz.com

On 30 April 2015 at 04:22, Bjørn Erik Pedersen notifications@github.com
wrote:

"I'm 90% done with this today."

This was January. I understand it's not uncommon in software development
that the last 10% is the toughest - but is it possible to get a realistic
estimate? Should we remove this from the v.0.14 milestone?


Reply to this email directly or view it on GitHub
#147 (comment).

bguiz commented Apr 30, 2015

I'd really really like to see this feature make it into the next release,
can we please keep it in the milestone?

W: http://bguiz.com

On 30 April 2015 at 04:22, Bjørn Erik Pedersen notifications@github.com
wrote:

"I'm 90% done with this today."

This was January. I understand it's not uncommon in software development
that the last 10% is the toughest - but is it possible to get a realistic
estimate? Should we remove this from the v.0.14 milestone?


Reply to this email directly or view it on GitHub
#147 (comment).

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep May 1, 2015

Member

v0.14 is long overdue and we cannot release something that isn't there, but I'm not doing the release, so I wouldn't know.

Member

bep commented May 1, 2015

v0.14 is long overdue and we cannot release something that isn't there, but I'm not doing the release, so I wouldn't know.

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet May 5, 2015

just ran into this problem. it's really annoying, particularly when using hugo as part of a pipeline for a bigger site.

jbenet commented May 5, 2015

just ran into this problem. it's really annoying, particularly when using hugo as part of a pipeline for a bigger site.

@gour

This comment has been minimized.

Show comment
Hide comment
@gour

gour May 7, 2015

Contributor

Let me just add that the other day I was playing with Nikola which allows to use code like this:

/path-to/content/post/hello-world.rst
/path-to/content/post/hello-world/image.jpg

and the image is referenced within the post with:

.. thumbnail:: image.jpg
                  :alt: Some alt-text
                  :align: center
                  :scale: 60        
                  etc.

Simple & clean way to keep images/assets along with posts...

Contributor

gour commented May 7, 2015

Let me just add that the other day I was playing with Nikola which allows to use code like this:

/path-to/content/post/hello-world.rst
/path-to/content/post/hello-world/image.jpg

and the image is referenced within the post with:

.. thumbnail:: image.jpg
                  :alt: Some alt-text
                  :align: center
                  :scale: 60        
                  etc.

Simple & clean way to keep images/assets along with posts...

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 May 7, 2015

Hello @gour

Could you give us more details?

What version were you using? Latest from master?

Can you give/link to a full example? I don't recognize :alt: :scale:.

Thanks!
On May 7, 2015 1:09 AM, "Gour" notifications@github.com wrote:

Let me just add that the other day I was playing with Nikola
https://getnikola.com/ which allows to use code like this:

/path-to/content/post/hello-world.rst
/path-to/content/post/hello-world/image.jpg

and the image is referenced within the post with:

.. thumbnail:: image.jpg
:alt: Some alt-text
:align: center
:scale: 60
etc.

Simple & clean way to keep images/assets along with posts...


Reply to this email directly or view it on GitHub
#147 (comment).

Hello @gour

Could you give us more details?

What version were you using? Latest from master?

Can you give/link to a full example? I don't recognize :alt: :scale:.

Thanks!
On May 7, 2015 1:09 AM, "Gour" notifications@github.com wrote:

Let me just add that the other day I was playing with Nikola
https://getnikola.com/ which allows to use code like this:

/path-to/content/post/hello-world.rst
/path-to/content/post/hello-world/image.jpg

and the image is referenced within the post with:

.. thumbnail:: image.jpg
:alt: Some alt-text
:align: center
:scale: 60
etc.

Simple & clean way to keep images/assets along with posts...


Reply to this email directly or view it on GitHub
#147 (comment).

@gour

This comment has been minimized.

Show comment
Hide comment
@gour

gour May 7, 2015

Contributor

@eduncan911 I am speaking how one can tie one's assets (e.g. images) close to the post in Nikola static-site-generator, iow. it's not about Hugo, but example how it could the problem of tying images close to the post be solved within Hugo.

Contributor

gour commented May 7, 2015

@eduncan911 I am speaking how one can tie one's assets (e.g. images) close to the post in Nikola static-site-generator, iow. it's not about Hugo, but example how it could the problem of tying images close to the post be solved within Hugo.

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 May 7, 2015

Oh, I didn't catch that. Yeah, Octopress/Jekyll does as well.

On Thu, May 7, 2015 at 3:14 PM, Gour notifications@github.com wrote:

@eduncan911 https://github.com/eduncan911 I am speaking how one can tie
one's assets (e.g. images) close to the post in Nikola
https://getnikola.com/ static-site-generator, iow. it's not about
Hugo, but example how it could the problem of tying images close to the
post be solved within Hugo.


Reply to this email directly or view it on GitHub
#147 (comment).

Oh, I didn't catch that. Yeah, Octopress/Jekyll does as well.

On Thu, May 7, 2015 at 3:14 PM, Gour notifications@github.com wrote:

@eduncan911 https://github.com/eduncan911 I am speaking how one can tie
one's assets (e.g. images) close to the post in Nikola
https://getnikola.com/ static-site-generator, iow. it's not about
Hugo, but example how it could the problem of tying images close to the
post be solved within Hugo.


Reply to this email directly or view it on GitHub
#147 (comment).

@derekperkins

This comment has been minimized.

Show comment
Hide comment
@derekperkins

derekperkins May 15, 2015

Contributor

This seems like a great place to hook in an image processing pipeline, which has two major stages I can think of:

  • Compression & Optimization
    We could check for the availability of some commandline tools like optipng, jpegtran, etc and use them if they are available. If not, the user doesn't know the difference. The user could specify in their config file whether they want to enable processing.
  • Resizing & Cropping
    As mentioned in #1014, it would be nice to provide this as an option. Off the top of my head, you could also use the config file in a similar fashion to WordPress to register specific file sizes that can be referenced elsewhere in the code. https://codex.wordpress.org/Function_Reference/add_image_size

This is obviously much more intensive than just generating html files, so it'd have to come with some sort of caching mechanism so it didn't have to copy and regenerate all the image files every single time.

Contributor

derekperkins commented May 15, 2015

This seems like a great place to hook in an image processing pipeline, which has two major stages I can think of:

  • Compression & Optimization
    We could check for the availability of some commandline tools like optipng, jpegtran, etc and use them if they are available. If not, the user doesn't know the difference. The user could specify in their config file whether they want to enable processing.
  • Resizing & Cropping
    As mentioned in #1014, it would be nice to provide this as an option. Off the top of my head, you could also use the config file in a similar fashion to WordPress to register specific file sizes that can be referenced elsewhere in the code. https://codex.wordpress.org/Function_Reference/add_image_size

This is obviously much more intensive than just generating html files, so it'd have to come with some sort of caching mechanism so it didn't have to copy and regenerate all the image files every single time.

@derekperkins

This comment has been minimized.

Show comment
Hide comment
@derekperkins

derekperkins May 15, 2015

Contributor

The more I think about it, the more that seems a little intense for Hugo. While it would be super nice if it could fit the workflow, it may be more suited to a CI environment to go through and build all the right sizes on deployment. The only thing you lose by doing that is not being able to set the right width / height attributes inside your html tags.

Contributor

derekperkins commented May 15, 2015

The more I think about it, the more that seems a little intense for Hugo. While it would be super nice if it could fit the workflow, it may be more suited to a CI environment to go through and build all the right sizes on deployment. The only thing you lose by doing that is not being able to set the right width / height attributes inside your html tags.

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 May 15, 2015

This is not to address only images next to md files, but all file types.

We all agree that Hugo:

  1. should not try to process files it doesn't know about in the /content directory.
  2. move all files it finds in /content over to that same directory in the generated site, keeping the exact same structure.

E.g., side-by-side files:

/content/post/summer-fun/what-i-did-last-summer.md
/content/post/summer-fun/jet-skiing.png
/content/post/summer-fun/jet-skiing.mkv
/content/post/summer-fun/jet-ski-for-sale.zip

What you mention is another idea: file handlers. One could create their own handler and process the files with an external script or something if it matches an extension. But that's a different discussion for another thread. :)

On Thu, May 14, 2015 at 8:19 PM, Derek Perkins notifications@github.com
wrote:

The more I think about it, the more that seems a little intense for Hugo.
While it would be super nice if it could fit the workflow, it may be more
suited to a CI environment to go through and build all the right sizes on
deployment. The only thing you lose by doing that is not being able to set
the right width / height attributes inside your html tags.


Reply to this email directly or view it on GitHub
#147 (comment).

This is not to address only images next to md files, but all file types.

We all agree that Hugo:

  1. should not try to process files it doesn't know about in the /content directory.
  2. move all files it finds in /content over to that same directory in the generated site, keeping the exact same structure.

E.g., side-by-side files:

/content/post/summer-fun/what-i-did-last-summer.md
/content/post/summer-fun/jet-skiing.png
/content/post/summer-fun/jet-skiing.mkv
/content/post/summer-fun/jet-ski-for-sale.zip

What you mention is another idea: file handlers. One could create their own handler and process the files with an external script or something if it matches an extension. But that's a different discussion for another thread. :)

On Thu, May 14, 2015 at 8:19 PM, Derek Perkins notifications@github.com
wrote:

The more I think about it, the more that seems a little intense for Hugo.
While it would be super nice if it could fit the workflow, it may be more
suited to a CI environment to go through and build all the right sizes on
deployment. The only thing you lose by doing that is not being able to set
the right width / height attributes inside your html tags.


Reply to this email directly or view it on GitHub
#147 (comment).

@spf13 spf13 closed this in fc946de May 20, 2015

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 20, 2015

Contributor

To everyone. I committed a generic file handler that simply places the files in the same path in the destination directory. This will enable people to place images and other files along side their content. There's still a bit more to do around this, but the fundamental issue / request in these 3 tickets is solved. It does need a bit of testing so I'd love everyone to check out head and play with it.

Contributor

spf13 commented May 20, 2015

To everyone. I committed a generic file handler that simply places the files in the same path in the destination directory. This will enable people to place images and other files along side their content. There's still a bit more to do around this, but the fundamental issue / request in these 3 tickets is solved. It does need a bit of testing so I'd love everyone to check out head and play with it.

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 May 20, 2015

Awesome Steve!

Will let know in the next few days!

-E
On May 20, 2015 7:06 PM, "Steve Francia" notifications@github.com wrote:

To everyone. I committed a generic file handler that simply places the
files in the same path in the destination directory. This will enable
people to place images and other files along side their content. There's
still a bit more to do around this, but the fundamental issue / request in
these 3 tickets is solved. It does need a bit of testing so I'd love
everyone to check out head and play with it.


Reply to this email directly or view it on GitHub
#147 (comment).

Awesome Steve!

Will let know in the next few days!

-E
On May 20, 2015 7:06 PM, "Steve Francia" notifications@github.com wrote:

To everyone. I committed a generic file handler that simply places the
files in the same path in the destination directory. This will enable
people to place images and other files along side their content. There's
still a bit more to do around this, but the fundamental issue / request in
these 3 tickets is solved. It does need a bit of testing so I'd love
everyone to check out head and play with it.


Reply to this email directly or view it on GitHub
#147 (comment).

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep May 20, 2015

Member

Works for me.

Member

bep commented May 20, 2015

Works for me.

@FooSoft

This comment has been minimized.

Show comment
Hide comment
@FooSoft

FooSoft May 21, 2015

Thank you very much for this change.

FooSoft commented May 21, 2015

Thank you very much for this change.

@FooSoft

This comment has been minimized.

Show comment
Hide comment
@FooSoft

FooSoft May 21, 2015

Running into an issue when I have HTML files (specifically reveal.js stuff) along with markdown files:

ERROR: 2015/05/21 Error rendering site: Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined
Available templates:
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/embedded-media.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown-element-attributes.html
ERROR: 2015/05/21   _internal/shortcodes/test.html
ERROR: 2015/05/21   partials/header.html
ERROR: 2015/05/21   partials/photos.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/barebones.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/notes/notes.html
ERROR: 2015/05/21   
ERROR: 2015/05/21   _internal/shortcodes/ref.html
ERROR: 2015/05/21   _internal/_default/sitemap.xml
ERROR: 2015/05/21   partials/navbar.html
ERROR: 2015/05/21   _internal/google_news.html
ERROR: 2015/05/21   404.html
ERROR: 2015/05/21   partials/article-contents.html
ERROR: 2015/05/21   partials/github.html
ERROR: 2015/05/21   _internal/shortcodes/highlight.html
ERROR: 2015/05/21   _internal/_default/rss.xml
ERROR: 2015/05/21   _internal/disqus.html
ERROR: 2015/05/21   _internal/twitter_cards.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/markdown/example.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/slide-backgrounds.html
ERROR: 2015/05/21   _internal/pagination.html
ERROR: 2015/05/21   _default/single.html
ERROR: 2015/05/21   _internal/shortcodes/relref.html
ERROR: 2015/05/21   _internal/shortcodes/figure.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-pdf.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown-slide-attributes.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test.html
ERROR: 2015/05/21   __research/search/presentation/index.html
ERROR: 2015/05/21   _internal/schema.html
ERROR: 2015/05/21   partials/article-summary.html
ERROR: 2015/05/21   partials/footer.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/index.html
ERROR: 2015/05/21   _internal/opengraph.html
ERROR: 2015/05/21   _default/list.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/math.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown.html
CRITICAL: 2015/05/21 Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined

It appears that Hugo tries to interpret them as templates.

FooSoft commented May 21, 2015

Running into an issue when I have HTML files (specifically reveal.js stuff) along with markdown files:

ERROR: 2015/05/21 Error rendering site: Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined
Available templates:
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/embedded-media.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown-element-attributes.html
ERROR: 2015/05/21   _internal/shortcodes/test.html
ERROR: 2015/05/21   partials/header.html
ERROR: 2015/05/21   partials/photos.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/barebones.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/notes/notes.html
ERROR: 2015/05/21   
ERROR: 2015/05/21   _internal/shortcodes/ref.html
ERROR: 2015/05/21   _internal/_default/sitemap.xml
ERROR: 2015/05/21   partials/navbar.html
ERROR: 2015/05/21   _internal/google_news.html
ERROR: 2015/05/21   404.html
ERROR: 2015/05/21   partials/article-contents.html
ERROR: 2015/05/21   partials/github.html
ERROR: 2015/05/21   _internal/shortcodes/highlight.html
ERROR: 2015/05/21   _internal/_default/rss.xml
ERROR: 2015/05/21   _internal/disqus.html
ERROR: 2015/05/21   _internal/twitter_cards.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/markdown/example.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/slide-backgrounds.html
ERROR: 2015/05/21   _internal/pagination.html
ERROR: 2015/05/21   _default/single.html
ERROR: 2015/05/21   _internal/shortcodes/relref.html
ERROR: 2015/05/21   _internal/shortcodes/figure.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-pdf.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown-slide-attributes.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test.html
ERROR: 2015/05/21   __research/search/presentation/index.html
ERROR: 2015/05/21   _internal/schema.html
ERROR: 2015/05/21   partials/article-summary.html
ERROR: 2015/05/21   partials/footer.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/index.html
ERROR: 2015/05/21   _internal/opengraph.html
ERROR: 2015/05/21   _default/list.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/examples/math.html
ERROR: 2015/05/21   __research/search/presentation/bower_components/reveal.js/test/test-markdown.html
CRITICAL: 2015/05/21 Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined

It appears that Hugo tries to interpret them as templates.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 21, 2015

Contributor

Html files are interpreted as content files and will be parsed as such when in the content directory. 

If you would like them to not be parsed then they need to be in the static directory. 

This error seems to indicate that they are not in the content directory but in layouts as that is the only place where templates are looked for. Can you provide more complete paths for these files?

Best,
Steve

-- 

Steve Francia
steve.francia@gmail.com

Docker Inc
http://spf13.com 

     

On May 21, 2015 at 12:56:46 AM, Alex Yatskov (notifications@github.com) wrote:

Running into an issue when I have HTML files (specifically reveal.js stuff) along with markdown files:

ERROR: 2015/05/21 Error rendering site: Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined
Available templates:
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/embedded-media.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown-element-attributes.html
ERROR: 2015/05/21 _internal/shortcodes/test.html
ERROR: 2015/05/21 partials/header.html
ERROR: 2015/05/21 partials/photos.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/barebones.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/notes/notes.html
ERROR: 2015/05/21
ERROR: 2015/05/21 _internal/shortcodes/ref.html
ERROR: 2015/05/21 _internal/_default/sitemap.xml
ERROR: 2015/05/21 partials/navbar.html
ERROR: 2015/05/21 _internal/google_news.html
ERROR: 2015/05/21 404.html
ERROR: 2015/05/21 partials/article-contents.html
ERROR: 2015/05/21 partials/github.html
ERROR: 2015/05/21 _internal/shortcodes/highlight.html
ERROR: 2015/05/21 _internal/_default/rss.xml
ERROR: 2015/05/21 _internal/disqus.html
ERROR: 2015/05/21 _internal/twitter_cards.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/markdown/example.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/slide-backgrounds.html
ERROR: 2015/05/21 _internal/pagination.html
ERROR: 2015/05/21 _default/single.html
ERROR: 2015/05/21 _internal/shortcodes/relref.html
ERROR: 2015/05/21 _internal/shortcodes/figure.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-pdf.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown-slide-attributes.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test.html
ERROR: 2015/05/21 __research/search/presentation/index.html
ERROR: 2015/05/21 _internal/schema.html
ERROR: 2015/05/21 partials/article-summary.html
ERROR: 2015/05/21 partials/footer.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/index.html
ERROR: 2015/05/21 _internal/opengraph.html
ERROR: 2015/05/21 _default/list.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/math.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown.html
CRITICAL: 2015/05/21 Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined

It appears that Hugo tries to interpret them as templates.


Reply to this email directly or view it on GitHub.

Contributor

spf13 commented May 21, 2015

Html files are interpreted as content files and will be parsed as such when in the content directory. 

If you would like them to not be parsed then they need to be in the static directory. 

This error seems to indicate that they are not in the content directory but in layouts as that is the only place where templates are looked for. Can you provide more complete paths for these files?

Best,
Steve

-- 

Steve Francia
steve.francia@gmail.com

Docker Inc
http://spf13.com 

     

On May 21, 2015 at 12:56:46 AM, Alex Yatskov (notifications@github.com) wrote:

Running into an issue when I have HTML files (specifically reveal.js stuff) along with markdown files:

ERROR: 2015/05/21 Error rendering site: Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined
Available templates:
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/embedded-media.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown-element-attributes.html
ERROR: 2015/05/21 _internal/shortcodes/test.html
ERROR: 2015/05/21 partials/header.html
ERROR: 2015/05/21 partials/photos.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/barebones.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/notes/notes.html
ERROR: 2015/05/21
ERROR: 2015/05/21 _internal/shortcodes/ref.html
ERROR: 2015/05/21 _internal/_default/sitemap.xml
ERROR: 2015/05/21 partials/navbar.html
ERROR: 2015/05/21 _internal/google_news.html
ERROR: 2015/05/21 404.html
ERROR: 2015/05/21 partials/article-contents.html
ERROR: 2015/05/21 partials/github.html
ERROR: 2015/05/21 _internal/shortcodes/highlight.html
ERROR: 2015/05/21 _internal/_default/rss.xml
ERROR: 2015/05/21 _internal/disqus.html
ERROR: 2015/05/21 _internal/twitter_cards.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/markdown/example.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/slide-backgrounds.html
ERROR: 2015/05/21 _internal/pagination.html
ERROR: 2015/05/21 _default/single.html
ERROR: 2015/05/21 _internal/shortcodes/relref.html
ERROR: 2015/05/21 _internal/shortcodes/figure.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-pdf.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown-slide-attributes.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test.html
ERROR: 2015/05/21 __research/search/presentation/index.html
ERROR: 2015/05/21 _internal/schema.html
ERROR: 2015/05/21 partials/article-summary.html
ERROR: 2015/05/21 partials/footer.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/index.html
ERROR: 2015/05/21 _internal/opengraph.html
ERROR: 2015/05/21 _default/list.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/examples/math.html
ERROR: 2015/05/21 __research/search/presentation/bower_components/reveal.js/test/test-markdown.html
CRITICAL: 2015/05/21 Error(s) rendering pages: template: __research/search/presentation/bower_components/reveal.js/plugin/notes-server/notes.html:188: function "socketId" not defined

It appears that Hugo tries to interpret them as templates.


Reply to this email directly or view it on GitHub.

@FooSoft

This comment has been minimized.

Show comment
Hide comment
@FooSoft

FooSoft May 21, 2015

I ended up moving the stuff out of content into static and it's all groovy now. I was just under the impression that with this new change, when processing the content directory, Hugo would convert markdown files to HTML, and pass everything else through without processing it (I thought that the layout directory is the only place that would be processed for templates). I'll post a repro in a few.

FooSoft commented May 21, 2015

I ended up moving the stuff out of content into static and it's all groovy now. I was just under the impression that with this new change, when processing the content directory, Hugo would convert markdown files to HTML, and pass everything else through without processing it (I thought that the layout directory is the only place that would be processed for templates). I'll post a repro in a few.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 21, 2015

Contributor

The intent of /content is things are in there to be processed. This change does permit files to live alongside the content and if a dedicated handler isn't found it will just copy them over. This isn't the safest thing to do as in the future a handler may be defined for the file type and change the behavior. For instance, we could (and probably will) add a handler that does some automatic optimization to images... a generally but not universally desirable feature. If you want the images untouched...

The intent of /static is that things in there are not to be processed and will be copied over exactly as they are.

Contributor

spf13 commented May 21, 2015

The intent of /content is things are in there to be processed. This change does permit files to live alongside the content and if a dedicated handler isn't found it will just copy them over. This isn't the safest thing to do as in the future a handler may be defined for the file type and change the behavior. For instance, we could (and probably will) add a handler that does some automatic optimization to images... a generally but not universally desirable feature. If you want the images untouched...

The intent of /static is that things in there are not to be processed and will be copied over exactly as they are.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 21, 2015

Contributor

It's also the case that hugo supports html, markdown, asciidoc and rst currently as content files.

Contributor

spf13 commented May 21, 2015

It's also the case that hugo supports html, markdown, asciidoc and rst currently as content files.

@eduncan911

This comment has been minimized.

Show comment
Hide comment
@eduncan911

eduncan911 May 21, 2015

There's the list... Was searching the docs for what is currently processes.

Maybe someone with a little more time can update the docs and submit a pull
request. (FYI, the Hugo docs is in github as well, generated by Hugo
itself - by Steve I am guessing).
On May 21, 2015 8:30 AM, "Steve Francia" notifications@github.com wrote:

It's also the case that hugo supports html, markdown, asciidoc and rst
currently as content files.


Reply to this email directly or view it on GitHub
#147 (comment).

There's the list... Was searching the docs for what is currently processes.

Maybe someone with a little more time can update the docs and submit a pull
request. (FYI, the Hugo docs is in github as well, generated by Hugo
itself - by Steve I am guessing).
On May 21, 2015 8:30 AM, "Steve Francia" notifications@github.com wrote:

It's also the case that hugo supports html, markdown, asciidoc and rst
currently as content files.


Reply to this email directly or view it on GitHub
#147 (comment).

@FooSoft

This comment has been minimized.

Show comment
Hide comment
@FooSoft

FooSoft May 21, 2015

In case there is interest, I put up the website that illustrates the issue I was having here (5mb download):

http://foosoft.net/dl/hugo-repro.tar.gz

FooSoft commented May 21, 2015

In case there is interest, I put up the website that illustrates the issue I was having here (5mb download):

http://foosoft.net/dl/hugo-repro.tar.gz

@zachdyer

This comment has been minimized.

Show comment
Hide comment
@zachdyer

zachdyer May 27, 2015

Can you make hugo ignore desktop.ini files? Google Drive puts that file in there if youre using Google Drive sync on Windows. So you have to manually delete all the desktop.ini files to get Hugo to work.

Can you make hugo ignore desktop.ini files? Google Drive puts that file in there if youre using Google Drive sync on Windows. So you have to manually delete all the desktop.ini files to get Hugo to work.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep May 27, 2015

Member

@zachdyer ini-files should be covered by fc946de . Have you tested this with Hugo 0.14?

Member

bep commented May 27, 2015

@zachdyer ini-files should be covered by fc946de . Have you tested this with Hugo 0.14?

@zachdyer

This comment has been minimized.

Show comment
Hide comment
@zachdyer

zachdyer May 27, 2015

Actually no but good job dude yes!

On Wed, May 27, 2015 at 3:48 PM, Bjørn Erik Pedersen <
notifications@github.com> wrote:

@zachdyer https://github.com/zachdyer ini-files should be covered by
fc946de
fc946de
. Have you tested this with Hugo 0.14?


Reply to this email directly or view it on GitHub
#147 (comment).

[image: ZachDyerDesignHeaderGoogle.png]
Zach Dyer
1471 W South St.
Ozark, MO 65721
417.582.5445
www.zachdyerdesign.com
hosting.zachdyerdesign.com

Breach of confidentiality & accidental breach of confidentiality

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.

Actually no but good job dude yes!

On Wed, May 27, 2015 at 3:48 PM, Bjørn Erik Pedersen <
notifications@github.com> wrote:

@zachdyer https://github.com/zachdyer ini-files should be covered by
fc946de
fc946de
. Have you tested this with Hugo 0.14?


Reply to this email directly or view it on GitHub
#147 (comment).

[image: ZachDyerDesignHeaderGoogle.png]
Zach Dyer
1471 W South St.
Ozark, MO 65721
417.582.5445
www.zachdyerdesign.com
hosting.zachdyerdesign.com

Breach of confidentiality & accidental breach of confidentiality

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.

@gima

This comment has been minimized.

Show comment
Hide comment
@gima

gima Jun 8, 2015

Does not work with permalinks.

Files are laid out in a directory path matching the pre-permalink URL, thus effecively ignoring permalinks completely.

Should a new bug report be opened or is this sufficient?

gima commented Jun 8, 2015

Does not work with permalinks.

Files are laid out in a directory path matching the pre-permalink URL, thus effecively ignoring permalinks completely.

Should a new bug report be opened or is this sufficient?

@fazalmajid

This comment has been minimized.

Show comment
Hide comment
@fazalmajid

fazalmajid Nov 27, 2015

Interesting discussion. I am in the process of converting a WP blog to Hugo, and my last big hurdles are image gallery handling and ATOM support. To be a world-class platform, Hugo needs fully integrated media management.

I am experimenting with a different approach than what was suggested above: treat JPEG files in /content as an external media type (the same way asciidoc, mmark, ReST and HTML are treated), copy the file as-is, but process its metadata (EXIF/IPTC/XMP/ICC) as implied front matter, and provide templates with functions that can perform standard image operations like thumbnail generation, resizing, watermarking, cropping, and so on.

This would allow templates to become full-fledged gallery generators, e.g. automatically generate a photoblog or galleries from photos dropped into /content/photos/ by Lightroom et al. This seems to me like more powerful and extensible, and aligned with the design of Hugo (and the limitations of Go in terms of lacking dynamic linking or similar extensibility mechanisms to implement plugins).

I'll share my work if it turns out to be successful. Happy Thanksgiving!

Interesting discussion. I am in the process of converting a WP blog to Hugo, and my last big hurdles are image gallery handling and ATOM support. To be a world-class platform, Hugo needs fully integrated media management.

I am experimenting with a different approach than what was suggested above: treat JPEG files in /content as an external media type (the same way asciidoc, mmark, ReST and HTML are treated), copy the file as-is, but process its metadata (EXIF/IPTC/XMP/ICC) as implied front matter, and provide templates with functions that can perform standard image operations like thumbnail generation, resizing, watermarking, cropping, and so on.

This would allow templates to become full-fledged gallery generators, e.g. automatically generate a photoblog or galleries from photos dropped into /content/photos/ by Lightroom et al. This seems to me like more powerful and extensible, and aligned with the design of Hugo (and the limitations of Go in terms of lacking dynamic linking or similar extensibility mechanisms to implement plugins).

I'll share my work if it turns out to be successful. Happy Thanksgiving!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment