Using for plugins in Hugo?

[natefinch]

So, I wrote a Go package that makes plugins easier to write for Go applications. I think Hugo could get a huge benefit out of this, as everyone always has their pet feature that they want to see implemented.

I’d like to get people’s ideas on what kinds of things they’d like to add to Hugo that could be done via plugins. Loading plugins and all that stuff is easy, but figuring out where we need to add hooks to support extension via plugins is another matter.

Some obvious examples:

• Custom content types (latex, etc)
• Custom shortcodes (highlighting, etc)

Some less obvious and more tricky examples:

• Adding values to the data passed to templates
• Adding functions to the data passed to templates

I’m sure there’s 1000 other things I’m missing, so please help out by posting what you’d like to customize about Hugo.

Note: I started an issue on the Hugo repo, but I think discussion works better here.

[bep]

There’s enough use cases (not sure if it is in the 1000s, though).

There has been a discussion before about expanding the current Pygments-integration in Hugo to a general Exec shortcode, see:

Add exec shortcode

Some use cases to be found in that and linked discussions. Some problems, too, the most notable one being security.

I think someone should make a small proof-of-concept to show how this would feel like.

Maybe a content handler, maybe something already supported by Hugo so we can see before/after; Blackfriday Markdown?

[natefinch]

Yeah, I was thinking exactly that - that I’d make a plugin that duplicates the functionality of something already in Hugo, so it would be the plugin infrastructure that would be tested, and not the logic of the code the plugin provides

[spf13]

I love this idea and reviewed the code and think it has a lot of potential. Really excited to see it implemented.

[Greg_Boggs]

This is a great feature. I haven’t had to patch or modify Hugo yet. But, as I use it on more advanced sites, I’d love to have plugin support as a more standard way to extend things.

[spf13]

Hugo 0.13 was rewritten to add internal support for handlers based on filetype. Currently all are written as part of the Hugo codebase, but it was designed very modularly with plugins in mind. It would be a great place to start with the plugins.

[erlend_sh]

Any news from @natefinch on this?

Another, more actively developed library that came up on GitHub (maybe close that, since it’s best to have discussion in one place) is Pingo:

dullgiulio/pingo

Maybe this completely misses the mark, but the Go-based Packer.io also seem to have come up with a novel way of allowing plugins.

https://www.packer.io/docs/extend/plugins.html
Packer plugins are completely separate, standalone applications that the core of Packer starts and communicates with.

These plugin applications aren’t meant to be run manually. Instead, Packer core executes these plugin applications in a certain way and communicates with them. For example, the VMware builder is actually a standalone binary named packer-builder-vmware. The next time you run a Packer build, look at your process list and you should see a handful of packer- prefixed applications running.

p.s. You can probably close this older topic to keep all discussion over here.

[RingoDS]

The plugin system from Packer can be found here:

hashicorp/go-plugin

This plugin system is used in a number of other Hashicorp tools: Vault, Terraform, …

Credits to @mitchellh.

[AdamIsrael]

What’s the current state of plugin support in hugo, i.e., is there a way to write them now or does work need to be done to add support for it?

[moorereason]

They are not supported. I don’t know of anyone who’s working on that feature right now.

[dc0d]

Any further development on this?

There are (IMO many) cases that can benefit from this. For example customizing the date/time part of a url can com from a plugin.

Instead of 2018/06/12 it can be 2018/Q2 or even comes from other calendars, like Persian Calendar 1397/03/22.