search

getzola / zola

A fast static site generator in a single binary with everything built-in. https://www.getzola.org
https://www.getzola.org
MIT License
13.54k stars 946 forks source link

Support for non-HTML templates #905

Closed rotty closed 4 years ago

rotty commented 4 years ago

Feature Request

Environment

Zola version: 0.9.0

Feature Proposal

As I've initially described this in #840, it is currently impossible (AFAICT) to manually emulate the generate-rss feature by using an appropriate template, as Zola assumes all pages to render to HTML output. There are two aspects to this:

Thus, I'd like to discuss the following potential change to Zola:

When a template is specified with a path that does not end in .html, use the extension from the template to form the resulting path, and don't do the index.html transformation. For example, a foo.md page specifying template = "feed.xml" in its frontmatter will be rendered to section/foo.xml instead of section/foo/index.html. When a path is specified for such a page, the given path would be used verbatim.

With this change, I think one would get pretty close to being able to implement the generate-rss feature in "user-space", so to speak, which would be nice from an elegance and versatility perspective, besides allowing for my specific use-case.

Drawbacks

Implementing the proposed change will still treat templates with the .html extension specially, as it does the index.html transformation. However, if that were to be made configurable, as proposed in #840, .html and other templates would be treated exactly the same, which mitigates that concern, I think.

Keats commented 4 years ago

I like that change. I don't really want to support ugly urls if possible so I don't mind not having a configuration option for now.

I'm wondering if it conflicts with https://zola.discourse.group/t/proposal-custom-output-formats/68 or not at all, I'm still unclear on that.

rotty commented 4 years ago

Quoting from your comment on #840:

Hmm so for that specific usecase I think it would make sense for section to be able to have a rss = true setting that automatically create a RSS feed for that section which could use its own issue.

This would go in the section's frontmatter, i.e., in _index.md, right? It would be a handy shortcut, like the global generate-rss setting is. It does not allow for multiple feeds per section, or different templates for different sections, or to influence how the generated RSS is named, which are all useful features to support, I think, especially in migrating from generators that allow for that flexibility.

Regarding the multiple output formats proposal, I still have to look into that in detail, but it seems there is quite some overlap. The principal difference seems to be that the output format proposal achieves its goals through extending the configuration, while my idea is instead to make Zola more flexible in how templates are able to be used. I think my proposal subsumes the functionality proposed in the "Custom Output Formats" pad. On the other hand, it can be argued that my proposal is a bit more involved to set up, as it involves creating a file with frontmatter, instead of editing the project configuration.

Keats commented 4 years ago

Hmm how would you render both a .html and a .xml for a section if you have only one template field in the frontmattter? I think that's where output format comes in but I'm not sure exactly how.

rotty commented 4 years ago

Couldn't you just add a regular page to a section, and render the RSS from there? Granted, you'd have to access the parent object (i.e., its section) in the template, which makes this not as nice, but it still should be possible, right?

skyfaller commented 4 years ago

I'm also interested in this feature, so that I could use Zola to produce websites for the Gopher protocol ("phlogs") or for the Gemini protocol. Neither protocol uses HTML. Here's an article on generating a Gopher site with Hugo.

Here's a comprehensive list of Gemini-related software.

dancek commented 4 years ago

I also got my gemini site up a couple of days ago and would like to use Zola to generate the content. I'll try to make a PR this week if we agree on the details.

My vision for the first iteration:

Future enhancements could include

dancek commented 4 years ago

When it comes to text/gemini, we'll also need a way to get page content without rendering markdown to html, but that's another discussion.

skyfaller commented 4 years ago 
* multiple templates for a single markdown file (eg. `templates = ["post.html", "post.gemini"]`).

This is what I really want! I want a blog that can crosspost to the Web, Gopher, and Gemini (and Hypercore, but that's not relevant here since Hypercore uses HTML), and it would be convenient if it could produce all of the files in a single run, rather than having to run zola multiple times with different templates.

dancek commented 4 years ago

I've been working on this, and it mostly works by now. There's still something wrong with page_template which makes it annoying to use in practice. You can see my work at https://github.com/getzola/zola/compare/next...dancek:zomini .

Note that I will break the branch by force-pushing, so do not depend on its contents. I'll submit a PR once the code fully works (but feel free to comment in the meantime).

dancek commented 4 years ago

After the discussions in #1059 I suggest closing this issue and restricting the scope of Zola to HTML output.

southerntofu commented 4 years ago

@dancek I'm very interested in gemini support for zola since i already use zola as a SSG on a french-speaking tilde server i operate. I want to support gemlogs on there and don't want to introduce a new tool that users would have to become familiar with.

zola is built for HTML only and it will not be trivial to implement support for Gemini pages (eg. internal links in a gemini templates will have to resolve to their gemini output paths, etc). However, zola has support for many features you would have to reimplement on your new project: taxonomies, internal links, translations..

In my opinion it may be easier to reimplement basic features from scratch, but in the long run patching zola should be less of a burden. Also, there's already tons of plaintext-friendly SSGs out there so maybe there's no need to rewrite one if that's the way you wanna go.

If your mind is set, i wish you good luck on your next project, but if you're simply feeling overwhelmed, i'd be delighted to help you implement this. Maybe @skyfaller would also be willing to help? Thanks for your work so far anyway!

dancek commented 4 years ago

@southerntofu see #1059. I already implemented the main part and I had a plan of how to move forward. Feel free to use my branch or fork from there.

dancek commented 4 years ago

I'm not opposed to this feature and could keep working on it, but having maintained FLOSS myself I can see the maintenance burden it would bring. Zola is great for HTML because it's built for HTML, and bypassing that will bring a lot of corner cases.

I think having great software for one use case is better than mediocre software for many different ones. So mainly the question is one of maintenance and continuing development.

(Nb. If I go ahead with an ssg of my own I'm not planning on anything fancy: no taxonomies, no translations, and most importantly no maintenance.)

skyfaller commented 4 years ago

If your mind is set, i wish you good luck on your next project, but if you're simply feeling overwhelmed, i'd be delighted to help you implement this. Maybe @skyfaller would also be willing to help? Thanks for your work so far anyway!

I'm happy to help test stuff, but I'm a noob and can't help write code anytime soon.