Thanks to the awesome community Hugo, gets better with each release. With the latest one we come big steps closer towards Hugo v1.0. But we’ve still some big milestones to tackle on the roadmap.
Therefore, I would compiled a list of features (based on the following feedback) that you would like to see implemented. Feel free to jump into a discussion and share your thoughts and ideas.
This discussion is intended to move this milestones into the spotlight. We also highly appreciate any kinds of contributions.
These are the parts of Hugo that most of us define as essential for such a release. Until the release of Hugo v1.0 we should have created a stable foundation. This means that we are happy with our data model and interface.
At the moment Hugo rebuilds the entire website even if you change just a single line in a file while saving it. Instead, we could optimize this process: e.g. by only rerendering the post itself and all pages that are associated with it (like tags/category lists or the homepage showing the latest post).
Corresponding issue: #1643
localized content and assets
Currently a document is only defined by it’s content and some metadata in the frontmatter. But documents can be more complex and rely on their own assets. Alternatively, we could define a directory and it’s files that would allow more customizable content structures. Read more on this approach.
better asset handling
Example: the community has high demand for the dynamic resizing and cropping of images (e.g. with shortcodes).
Corresponding issue: #1024
plugins: a plugin system would make Hugo even more powerful. Extend Hugo’s functionality easily with a plugin while keeping Hugo itself fast and bloat-free. Some users requested:
- an interactive web-based editor
- support for HTML/JS/CSS pre-processors (see #16)
- minification (#1251) and compression (#1674) support
We need to develope an interface that defines how plugins can interact with Hugo.
These are features that are appreciated by users but they shouldn’t block the release of Hugo v1.0. Consider their implementation as independent feature requests.
easier migration: new users have mostly to convert their content. Currently, we’ve a wide variety of third-party scripts. Until now, Hugo has built-in support for Jekyll via an import commands (see #101)
easier deployment: better deployment support to push your generated content to Amazon S3, Heroku, Google Cloud Storage etc.
Corresponding issue: #1543
suggestions for related posts: clearly a very useful feature for bloggers and theme creators.
Go implementation of content formats: currently Hugo relies on third-party helpers written in Python and Ruby. A native implementation in Go would cut the time needed to generate/parse the content. Since it’s beyond the capabilities of Hugo, see it as a request to the Go community.