As some of you probably know, right now, I’m building a file manager plugin and I want to, somehow, “rebuild” hugo plugin to make it better. But, let’s see something: what does the hugo plugin offer?
Browse, rename, edit and upload files
Change hugo settings, edit markdown toml/json/yaml files for hugo
Run Hugo
Oh… you’re seeing it now. The only thing that differs between hugo and filemanager plugins is the hugo part. So, what are you thinking Henrique? I was thinking about hugo plugin being a filemanager plugin! A plugin for a plugin!!! Got it?
Imagine this situation:
hugo henriquedias.com
In this case, hugo plugin would somehow require the filemanager plugin on henriquedias.com folder and then let the filemanager plugin answer all requests except the ones related to markdown files and/or settings. And the best: as I’m the developer of both plugins they could have a very consistent interface and work very nice together.
The problem is: can I require another plugin inside a plugin?
Hey! That would be a good idea, but I don’t see the point of doing that because it’s a very small plugin. And if you want to use it as a library just import github.com/hacdias/caddy-filemanager and use its structs and methods cause they’re all exported.
Hey Henrique, great question! Plugins can indeed have plugins. For example, the ACME DNS challenge solvers are each a plugin to the caddytls package, which is itself a plugin.
A plugin is a plugin if it can be plugged in by importing it from any file in the program (typically run.go, which I think is where the build server will put them). Then the plugin will register itself with the package it is plugging into, in your case, the hugo package you created.