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

Quick & useful: Configurable file extension #320

Closed
ghost opened this Issue Jun 4, 2014 · 16 comments

Comments

Projects
None yet
6 participants
@ghost

ghost commented Jun 4, 2014

Quick but very useful feature request: Permit the user to configure a preferred file extension for generated HTML files, i.e. keep allow the user to specify .htm , .aspx , .php or any other file extension instead of .html

Use cases: Sites where content is well served by a static site generator, but which need a PHP contact us form / guest book / statistics package etc. On most hosts, the pages will only be parsed by the PHP interpreter if they have the right extension.

Proposal: Ideally, this could be a site-wide default setting, with a per-page override in the page frontmatter. I.e. a site config setting and page frontmatter setting called extension, with a default value of html .

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Jul 1, 2014

Contributor

I think this is a good idea. Would need to figure out the right way to do it.... I have some ideas.

Contributor

spf13 commented Jul 1, 2014

I think this is a good idea. Would need to figure out the right way to do it.... I have some ideas.

@mohae

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae Aug 24, 2014

Contributor

What were your ideas?

I was thinking:

  • Add Content Extension to SiteInfo
  • Make Hugo's default html; this preserves original functionality.
  • Expose the setting as contentextension in Hugo's config file.
  • Expose the setting for use in front matter.
  • Change the creation of the filename to use the SiteInfo.ContentExtension setting.

I think that would address the use cases and proposal above. I prefer contentextension because its name reflects its purpose, but changing it is no biggie. This would also make the addition backwards compatible and be consistent with the way Hugo handles settings.

Is there anything that's missing or needs to be addressed? Or needs to be changed?

Contributor

mohae commented Aug 24, 2014

What were your ideas?

I was thinking:

  • Add Content Extension to SiteInfo
  • Make Hugo's default html; this preserves original functionality.
  • Expose the setting as contentextension in Hugo's config file.
  • Expose the setting for use in front matter.
  • Change the creation of the filename to use the SiteInfo.ContentExtension setting.

I think that would address the use cases and proposal above. I prefer contentextension because its name reflects its purpose, but changing it is no biggie. This would also make the addition backwards compatible and be consistent with the way Hugo handles settings.

Is there anything that's missing or needs to be addressed? Or needs to be changed?

@mohae

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae Sep 5, 2014

Contributor

I was taking another look at this and I think my original thoughts were insufficient.

I have a questions about https://github.com/spf13/hugo/blob/master/target/file.go:L64. Where is the list of markup types in page.go? Were you referring to the guessType() function in https://github.com/spf13/hugo/blob/master/hugolib/page.go? Or something else?

It seems like, given those comments it might be good to have both a default extension, and a mapping of source extensions to destination extensions, for those that want more granular control.

This would preserve existing functionality while providing a more holistic solution to the changing of file extensions.

This would result in changes to configuration, both the config file and front matter, for per page override) along with changes to how Hugo determines what extension to use. There may be other related issues too. #147 might be an example of one.

Any thoughts or alternative suggestions? Any sharp edges I should look out for?

Contributor

mohae commented Sep 5, 2014

I was taking another look at this and I think my original thoughts were insufficient.

I have a questions about https://github.com/spf13/hugo/blob/master/target/file.go:L64. Where is the list of markup types in page.go? Were you referring to the guessType() function in https://github.com/spf13/hugo/blob/master/hugolib/page.go? Or something else?

It seems like, given those comments it might be good to have both a default extension, and a mapping of source extensions to destination extensions, for those that want more granular control.

This would preserve existing functionality while providing a more holistic solution to the changing of file extensions.

This would result in changes to configuration, both the config file and front matter, for per page override) along with changes to how Hugo determines what extension to use. There may be other related issues too. #147 might be an example of one.

Any thoughts or alternative suggestions? Any sharp edges I should look out for?

@jcw

This comment has been minimized.

Show comment
Hide comment
@jcw

jcw Sep 21, 2014

If all it does is copy the file to the static area, then that would already address issue #147 of having images in the source area end up in the right spot for use as generated content.

At the risk of delaying this basic but already very practical feature, here's another idea to consider: if the processing is fully generic, driven by the file extension, you could set up basic image processing tasks such as resizing or format conversion, i.e. "bigimg-320x240.jpg" could be recognised by the extension to mean: resize (e.g. with imagemagick) the result and then generate "bigimg.jpg" in the destination area.

It's all very low-tech, and much neater conversion options can be added later, but... "perfect" tends to be the enemy of "done", right?

jcw commented Sep 21, 2014

If all it does is copy the file to the static area, then that would already address issue #147 of having images in the source area end up in the right spot for use as generated content.

At the risk of delaying this basic but already very practical feature, here's another idea to consider: if the processing is fully generic, driven by the file extension, you could set up basic image processing tasks such as resizing or format conversion, i.e. "bigimg-320x240.jpg" could be recognised by the extension to mean: resize (e.g. with imagemagick) the result and then generate "bigimg.jpg" in the destination area.

It's all very low-tech, and much neater conversion options can be added later, but... "perfect" tends to be the enemy of "done", right?

@mohae

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae Oct 2, 2014

Contributor

@jcw the initial implementation would probably cover the basics. I don't see why hooks wouldn't be supportable as long as they are consistent with @spf13's vision for Hugo.

While generating the images during site generation may seem appealing, that is the sort of thing I'd rather lazily generate on demand on the serving side, rather than the content generation side, but that's me.

I added a topic to Hugo's discussion board for further discussion on this topic: http://discuss.gohugo.io/t/discussion-for-configurable-file-extension-320/157

Contributor

mohae commented Oct 2, 2014

@jcw the initial implementation would probably cover the basics. I don't see why hooks wouldn't be supportable as long as they are consistent with @spf13's vision for Hugo.

While generating the images during site generation may seem appealing, that is the sort of thing I'd rather lazily generate on demand on the serving side, rather than the content generation side, but that's me.

I added a topic to Hugo's discussion board for further discussion on this topic: http://discuss.gohugo.io/t/discussion-for-configurable-file-extension-320/157

@jcw

This comment has been minimized.

Show comment
Hide comment
@jcw

jcw Oct 2, 2014

Thanks for adding this to the Discourse discussions.

The reason for bringing up image processing, is that I'm looking for a way to run everything as a 100% static site, using low-power (i.e. low energy consumption) hardware. Client-side can use JavaScript where needed, but the server only serves static files.

jcw commented Oct 2, 2014

Thanks for adding this to the Discourse discussions.

The reason for bringing up image processing, is that I'm looking for a way to run everything as a 100% static site, using low-power (i.e. low energy consumption) hardware. Client-side can use JavaScript where needed, but the server only serves static files.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Oct 19, 2014

Contributor

I've been working on this feature for the past week. I've made a lot of progress. Will submit a complete update here once I've got it working.

Contributor

spf13 commented Oct 19, 2014

I've been working on this feature for the past week. I've made a lot of progress. Will submit a complete update here once I've got it working.

@jcw

This comment has been minimized.

Show comment
Hide comment
@jcw

jcw Oct 23, 2014

Great - I'm really looking forward to this. Am currently setting up a new weblog to follow up on what I have been using for years based on WordPress. No problem putting images in a specific place for now, but I'll move them over next to the posts once this feature is ready in Hugo. It'll be a real time-saver for all subsequent posts, I expect.

The workflow I have in mind is to write new posts on a Mac using "Mou" for side-by-side previews (or perhaps Scrivener and Marked 2, we'll see), and then finish off by running Hugo to update the public site. Posts will usually be time-stamped for release some time in the future, so I'll be re-running Hugo periodically to adjust the website accordingly.

Steve, many thanks for pushing this forward.

jcw commented Oct 23, 2014

Great - I'm really looking forward to this. Am currently setting up a new weblog to follow up on what I have been using for years based on WordPress. No problem putting images in a specific place for now, but I'll move them over next to the posts once this feature is ready in Hugo. It'll be a real time-saver for all subsequent posts, I expect.

The workflow I have in mind is to write new posts on a Mac using "Mou" for side-by-side previews (or perhaps Scrivener and Marked 2, we'll see), and then finish off by running Hugo to update the public site. Posts will usually be time-stamped for release some time in the future, so I'll be re-running Hugo periodically to adjust the website accordingly.

Steve, many thanks for pushing this forward.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jul 25, 2015

Member

@spf13 any updates on this?

Member

bep commented Jul 25, 2015

@spf13 any updates on this?

@bep bep modified the milestones: v0.15, v0.14 Jul 25, 2015

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 9, 2015

Member

@spf13 update?

Member

bep commented Oct 9, 2015

@spf13 update?

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 18, 2015

Member

@spf13 update?

Member

bep commented Nov 18, 2015

@spf13 update?

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 Nov 18, 2015

Contributor

I'll review tomorrow or Friday. Working through the windows memory fs bug
now.
On Wed, Nov 18, 2015 at 6:00 PM Bjørn Erik Pedersen <
notifications@github.com> wrote:

@spf13 https://github.com/spf13 update?


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

Contributor

spf13 commented Nov 18, 2015

I'll review tomorrow or Friday. Working through the windows memory fs bug
now.
On Wed, Nov 18, 2015 at 6:00 PM Bjørn Erik Pedersen <
notifications@github.com> wrote:

@spf13 https://github.com/spf13 update?


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

@anthonyfok anthonyfok modified the milestones: v0.16, v0.15 Nov 30, 2015

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jan 8, 2016

Member

See

https://discuss.gohugo.io/t/how-to-change-file-extension-for-homepage/2418

We have a defaultExtension. All page generation should use it.

Member

bep commented Jan 8, 2016

See

https://discuss.gohugo.io/t/how-to-change-file-extension-for-homepage/2418

We have a defaultExtension. All page generation should use it.

@bep bep added Bug and removed Enhancement labels Jan 8, 2016

@moorereason moorereason modified the milestones: future, v0.16 May 7, 2016

@bep bep modified the milestones: v0.17, future Jul 21, 2016

@bep bep modified the milestones: future, v0.17 Sep 16, 2016

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Feb 28, 2017

Member

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

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.

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

Member

bep commented Feb 28, 2017

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

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.

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

@bep bep added the Stale label Feb 28, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 1, 2017

Member

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

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

Member

bep commented Mar 1, 2017

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

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

@bep bep added Keep and removed Stale labels Mar 1, 2017

@bep bep modified the milestones: v0.20, future Mar 14, 2017

@bep bep self-assigned this Mar 14, 2017

@bep bep referenced this issue Mar 14, 2017

Closed

Add custom output formats #2828

26 of 26 tasks complete
@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 31, 2017

Member

This will be fixed as part of #2828

Member

bep commented Mar 31, 2017

This will be fixed as part of #2828

bep added a commit to bep/hugo that referenced this issue Apr 4, 2017

@bep bep closed this in 7da1b65 Apr 4, 2017

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