Zola & www.rust-lang.org

Feature requests
1

Hello Zola Contributors & Community,

I’m XAMPPRocky, one of the maintainers of the Rust Lang website, and I want to migrate from the current custom rocket based server app, to being statically generated with Zola. Zola is robust and is quite feature rich for generating static websites. However there are some features that Zola doesn’t currently have that we would need. I would be willing to dedicate the time to add these features and go through code review, but I wanted to know if these would be features that people would be open to having these features.

Required

  • Fluent support
    • Rust uses fluent for localisation, which we use with Pontoon for organising and managing translation teams, and anything we move to would need to support that. I know Zola already has a different localisation system, so I would want people’s thoughts on adding another one.
  • Plugin-style functionality
    • We have a lot of integrations into Rust’s human and machine infrastructure that require custom logic for generating information for certain pages. This functionality doesn’t make sense to include in Zola itself, it would be nice to be able to extend Zola’s functionality with scripts or crates. Something similar to what mdbook provides would be ideal, though I don’t how feasible that is.
    • Adding this could also solve the first problem without including Fluent in Zola.

Nice To Have

  • Multiple RSS feed Support
    • This could already be implemented, but it was hard to tell from the documentation. Currently Rust’s blog is separate codebase, it would be nice if I could merge it into the website with Zola, but the blog currently runs two blogs. The main Rust blog, for announcements and news for users of Rust, and the Inside Rust blog for contributors of Rust. These are two separate RSS feeds because you might not want to subscribe to one or the other.
1 Like
2

I guess one options would be that Mozilla contribute to improve Zola functionality which is a win win for all and may be the quickest to get the features out.

3

@sirinath I’m not an employee of Mozilla, and Rust is not a Mozilla project. As I said, I would be willing contribute to Zola to add these features.

4

Woah I’m glad to see that!

The current system is only there for very basic needs. The end goal is to only have Fluent in Zola so I would welcome that. The only issue is discussing how it’s going to work from a UX pov and its integration with Tera.

I’m not sure how that would work, zola is not even on crates.io. Depending on the amount of work required to support that, it could be done though.

It is not implemented yet but it is on the radar. It’s probably a couple of hours of work to support it.

5

I’m not sure how that would work, zola is not even on crates.io. Depending on the amount of work required to support that, it could be done though.

Well what mdbook provides is that you can specify a plugin like foo, and it will attempt to call a program called mdbook-foo in the environment. Looking through Zola’s documentation, if there was a shortcode for getting JSON from commands in the environment, would probably enough to start with.

6

There is a kinda-related issue where I thought of having a Tera function to execute commands which could then be used in a shortcode.

7

Okay, I’ve made the first steps towards this being a possibility, which is adding support for Fluent in Tera by extending our current plugin for handlebars to support tera as well. Have a look at that function, if that seems satisfactory, I think we should be able to have zola generate the language codes at build time. https://github.com/Manishearth/handlebars-fluent/pull/6

1 Like
8

Stumbled on this thread, thinking on nice ways to do plugins feature here, but also ensure it’s done in a secure way. Thought of a fairly simple way to do it:

Adding an extra template function exec, which takes a name, and some further arguments. It would execute a file inside the plugins directory, and return the JSON-parsed output of the command. ie:

{{ exec('foo', '--some-args', 'value')  }} # Executes plugins/foo --some-args value

That way you could render / parse / do whatever both inside Zola in templates, or using simple script wrapper around existing commands on $PATH.

I’m thinking this shouldn’t be too hard to implement (happy to give it a go myself), but wondering if that would work for people’s needs?

9

I’m also interested in the possibility of extending Zola. It’s a great base, but for my use case I’d love to be able to do server-side rendering of math and auto-generate references using a BibTeX database. I wonder how hard it would be to move the majority of Zola from an executable to a library, then build a “default” executable over it. That would mean for people who are happy with the default functionality nothing would change, but with an ability to add “passes” to, for example, the HTML generation or Markdown processing would make it more of a static site generator framework for people who wanted extra functionality. If there’s interest, maybe I’ll fork it and take a shot?

EDIT: looks like it actually already is. Since an AST is never built, I guess one of the places to modify Zola would be to replace the function mapped over the Pest events, perhaps?

10

Just going to mention that since I wrote this post I’ve spent a lot more time with Zola and I think for my use-case the current load_data functionality works well enough. I can generate the JSON data at build time as a seperate step and pass it to Zola with load_data which is basically all I would want a “plugin” style interface to really be. Executing commands inside Zola directly would be nice but not required.

1 Like