Right now, the templates module is inflexible in that only functions the functions registered by Caddy itself are available.
A good refactor would be to make it possible to pass an optional array of modules in the http.handlers.templates.functions.* namespace which get invoked at Provision() time to register additional functions.
The text was updated successfully, but these errors were encountered:
The TemplateContext is responsible for parsing and executing templates. It knows which functions are valid. It's a part of the http.handlers.templates module. That module then must get custom functions at Provision time for hand-off to that context.
Modules would be defined under http.handlers.templates.functions (e.g. http.handlers.templates.functions.bash) which allows for a definition of how to execute the function (e.g. call exec.Command with bash and the script filepath). Adding new function types can be done by adding a module under http.handlers.templates.functions.*, which can be added to a server as a Caddy plugin.
I think you can use caddy.GetModules("http.handlers.templates.functions") to fetch a list of all the registered modules in that namespace, and if they conform to the right interface, you can load them in.
Context: https://caddy.community/t/including-files-scripts/15050/4
Right now, the
templatesmodule is inflexible in that only functions the functions registered by Caddy itself are available.A good refactor would be to make it possible to pass an optional array of modules in the
http.handlers.templates.functions.*namespace which get invoked atProvision()time to register additional functions.The text was updated successfully, but these errors were encountered: