Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow inserting file, bypassing rendering #1551

Closed
yitzhakbg opened this issue Nov 5, 2015 · 12 comments
Closed

Allow inserting file, bypassing rendering #1551

yitzhakbg opened this issue Nov 5, 2015 · 12 comments

Comments

@yitzhakbg
Copy link

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
Copy link
Member

bep commented Nov 5, 2015

@bep bep closed this as completed Nov 5, 2015
@yitzhakbg
Copy link
Author

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
Copy link
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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

spf13 commented Nov 28, 2015

Is this resolved now with the release of 0.15?

@yitzhakbg
Copy link
Author

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

@bep
Copy link
Member

bep commented Nov 28, 2015

No.

@yitzhakbg
Copy link
Author

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 [email protected] 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
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 gohugoio#1551
@bep bep closed this as completed in 4f66f79 Mar 31, 2016
@yitzhakbg
Copy link
Author

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

@bep
Copy link
Member

bep commented Mar 31, 2016

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

tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
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 gohugoio#1551
@github-actions
Copy link

github-actions bot commented Apr 8, 2022

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

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

No branches or pull requests

3 participants