Quick & useful: Configurable file extension

[ghost]

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]

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

[mohae]

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]

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]

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]

@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]

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]

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]

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]

@spf13 any updates on this?

[bep]

@spf13 update?

[bep]

@spf13 update?

[spf13]

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

[bep]

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]

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]

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]

This will be fixed as part of #2828

[github-actions]

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.