Would you merge support for plugins?

[toadslop]

Hey, I love Zola and want to give back something. One feature that I find Zola lacks compared to other similar solutions is a way to add extensions. If you'd be willing to merge extensions support, I'd love to work on it.

Since Tera already supports extensions for filters, functions, and tests, I would propose to provide a system that allows users to define their own filters, functions, and tests. I already have a POC working where I use quickjs to make it possible to define these Tera extensions using JavaScript.

Anyway, if you're interested in adding a feature like this, let me know and I'd be happy to work on it.

[Keats]

I do want something similar but in Tera itself, see Keats/tera#637 (comment)

What does your PoC look like?

[toadslop]

What I built was pretty rough but I verified the following are possible:

1. Write a function in JavaScript
2. Load function in QuickJS
3. Wrap the function in a Tera Function
4. Call the function from a Tera template, passing in a value and rendering the result.

Regarding wasm plugins, although I'm a big fan of wasm, I think its not a good idea to make wasm plugins the default for Zola, for the following reasons:

Too Much Complexity

Plugins for static site generators are usually trivial functions -- a simple transformation, a boolean check, perhaps a manipulation of the site context. Setting up a wasm toolchain and a wasm project to hold the sourcecode and compile it is not a trivial task. In many cases it would take more time to set up a plugin than it would to write it. This could be remediated by providing template projects for various languages, but that isn't scalable.

Unfamiliarity

People who write static sites are likely to be very familiar with HTML, CSS, and JavaScript. They are not likely to be familiar with wasm. This means that before they can even get started on writing their trivially simple plugin, they have to learn a significant amount about wasm and how to compile it.

Given the above two reasons coupled with the fact that anyone writing a static site will already necessarily know a thing or two about JavaScript, making the plugin system be based on JavaScript makes the most sense to me.

That said, it might be nice to provide multiple plugin solutions and hide them behind feature flags. The default could be JavaScript, but other scripting languages and even wasm could be made available for those who are interested.

[jomiq]

Hi, I'm working on a project where I generate an staff list/taxonomy from a spreadsheet. To this end I wrote some Python to read, manipulate and write the zola content file tree. I would propose a way simpler plugin structure that just lets me run whatever at certain points in the build process. Hooks essentially. I'm not familiar with zola source so I don't know if this would make sense, but maybe the interface could be something like this in config.toml:

[hooks]
pre_build = ["some_script.sh", ...]
...
post_render = ["daddys_hardcore_minify.sh", ...]

As it is now I'm just wrapping my "plugin" in a script that watches the relevant files and then that triggers zola rebuild in a sort of Rube Goldberg fashion. It works fine but I think that exposing some hooks would make this much leaner, and also be a very powerful feature in general.

Thanks for making great software by the way!