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

Allow inserting file, bypassing rendering #1551

Closed
yitzhakbg opened this Issue Nov 5, 2015 · 11 comments

Comments

Projects
None yet
3 participants
@yitzhakbg

See my post on incorporating remark.js.
It required pulling in a markdown file without hugo rendering it (remark does the rendering). I had to trick hugo by placing the md file in the partials directory and pulling it in from there as a partial. But why sneak in the back door? The capability of pulling other files in could be useful in many situations.

@bep bep closed this Nov 5, 2015

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Nov 5, 2015

Thanks for the info. I see you closed this. .RawContent isn't in v0.14, so I can't use it.
I would suggest making it more flexible so that it can raw load any file and not only the equivalent of the .Content file.

Thanks for the info. I see you closed this. .RawContent isn't in v0.14, so I can't use it.
I would suggest making it more flexible so that it can raw load any file and not only the equivalent of the .Content file.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 5, 2015

Member

Well, any new suggested features wouldn't be in 0.14 either. Raw content include is, kind of, already covered by the Exec issue and pull request. But I'll reopen this to keep track of it. Someone may make a cross platform "cat file" feature.

Member

bep commented Nov 5, 2015

Well, any new suggested features wouldn't be in 0.14 either. Raw content include is, kind of, already covered by the Exec issue and pull request. But I'll reopen this to keep track of it. Someone may make a cross platform "cat file" feature.

@bep bep reopened this Nov 5, 2015

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Nov 5, 2015

body p { margin-bottom: 0cm; margin-top: 0pt; } 


Thanks

On 5/11/15 16:17, Bjørn Erik Pedersen
  wrote:


  Well, any new suggested features wouldn't be in 0.14 either.
    Raw content include is, kind of, already covered by the Exec
    issue and pull request. But I'll reopen this to keep track of
    it. Someone may make a cross platform "cat file" feature.
  —
    Reply to this email directly or view
      it on GitHub.
body p { margin-bottom: 0cm; margin-top: 0pt; } 


Thanks

On 5/11/15 16:17, Bjørn Erik Pedersen
  wrote:


  Well, any new suggested features wouldn't be in 0.14 either.
    Raw content include is, kind of, already covered by the Exec
    issue and pull request. But I'll reopen this to keep track of
    it. Someone may make a cross platform "cat file" feature.
  —
    Reply to this email directly or view
      it on GitHub.

@bep bep added the Enhancement label Nov 5, 2015

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Nov 9, 2015

I think that enhancing the partial functionality is the way to go. Allow pulling in different content types from a range of locations. Could open the way to future innovation

I think that enhancing the partial functionality is the way to go. Allow pulling in different content types from a range of locations. Could open the way to future innovation

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Nov 28, 2015

Contributor

Is this resolved now with the release of 0.15?

Contributor

spf13 commented Nov 28, 2015

Is this resolved now with the release of 0.15?

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Nov 28, 2015

I'd also like to know if this is resolved with 0.15

I'd also like to know if this is resolved with 0.15

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 28, 2015

Member

No.

Member

bep commented Nov 28, 2015

No.

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Nov 29, 2015

With your kind permission, I'd like to expand on why this is a valuable addition IMHO:
Remark.js, which renders slides with its own engine, is but an example of a wide range of possible intermediate processing applications which can be performed during rendering outside of but not interfering with Hugo. Remark.js renders Markdown, but many applications might need intermediate processing of different types altogether.
Optimally, it should be made available to users within the context of Hugo syntax without having to invoke an API call.
Thanks

On 29 בנוב 2015, at 01:34, Bjørn Erik Pedersen notifications@github.com wrote:

No.


Reply to this email directly or view it on GitHub.

With your kind permission, I'd like to expand on why this is a valuable addition IMHO:
Remark.js, which renders slides with its own engine, is but an example of a wide range of possible intermediate processing applications which can be performed during rendering outside of but not interfering with Hugo. Remark.js renders Markdown, but many applications might need intermediate processing of different types altogether.
Optimally, it should be made available to users within the context of Hugo syntax without having to invoke an API call.
Thanks

On 29 בנוב 2015, at 01:34, Bjørn Erik Pedersen notifications@github.com wrote:

No.


Reply to this email directly or view it on GitHub.

bep added a commit to bep/hugo that referenced this issue Mar 25, 2016

Add readFile template func
This also includes a refactor of the hugofs package and its usage.

The motivation for that is:

The Afero filesystems are brilliant. Hugo's way of adding a dozen of global variables for the different filesystems was a mistake. In readFile (and also in some other places in Hugo today) we need a way to restrict the access inside the working dir. We could use ioutil.ReadFile and implement the path checking, checking the base path and the dots ("..") etc. But it is obviously better to use an Afero BasePathFs combined witha ReadOnlyFs. We could create a use-once-filesystem and handle the initialization ourselves, but since this is also useful to others and the initialization depends on some other global state (which would mean to create a new file system on every invocation), we might as well do it properly and encapsulate the predefined set of filesystems. This change also leads the way, if needed, to encapsulate the file systems in a struct, making it possible to have several file system sets in action at once (parallel multilanguage site building? With Moore's law and all...)

Fixes #1551

@bep bep closed this in 4f66f79 Mar 31, 2016

@yitzhakbg

This comment has been minimized.

Show comment
Hide comment
@yitzhakbg

yitzhakbg Mar 31, 2016

I'm having trouble understanding this. Could you kindly provide some non-technical documentation with an example of how to use this?

I'm having trouble understanding this. Could you kindly provide some non-technical documentation with an example of how to use this?

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 31, 2016

Member

Use https://discuss.gohugo.io/ for questions.

Member

bep commented Mar 31, 2016

Use https://discuss.gohugo.io/ for questions.

tychoish added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

Add readFile template func
This also includes a refactor of the hugofs package and its usage.

The motivation for that is:

The Afero filesystems are brilliant. Hugo's way of adding a dozen of global variables for the different filesystems was a mistake. In readFile (and also in some other places in Hugo today) we need a way to restrict the access inside the working dir. We could use ioutil.ReadFile and implement the path checking, checking the base path and the dots ("..") etc. But it is obviously better to use an Afero BasePathFs combined witha ReadOnlyFs. We could create a use-once-filesystem and handle the initialization ourselves, but since this is also useful to others and the initialization depends on some other global state (which would mean to create a new file system on every invocation), we might as well do it properly and encapsulate the predefined set of filesystems. This change also leads the way, if needed, to encapsulate the file systems in a struct, making it possible to have several file system sets in action at once (parallel multilanguage site building? With Moore's law and all...)

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