Plugin hooks.json gains a modules key for code-registered hooks, off unless enabled remotely.
A full JavaScript hook engine with register(on, options) and chained next() sits behind tengu_plugin_hooks_modules, off by default.
What's wrong with this entry?
A plugin can now ship a JavaScript module that registers hooks in code with register(on, options), instead of only declarative matchers in hooks.json. That file gains a modules key alongside hooks, and either or both may be present. The engine loads and evaluates the module, dispatches each hook event through a chain with next(), reports failures, and reloads or prunes when a plugin is disabled. It is controlled by tengu_plugin_hooks_modules, whose built-in fallback is off, so nothing loads unless server config turns it on.
- A plugin manifest may declare a hooks module path, and hook config parsing now returns both the matchers and the modules.
- The gate also drives a new plugin-types entry in the capability and notice map.
`hooks.json must have hooks (the hook matchers) or modules (hooks modules), or both, var Lnt = "tengu_plugin_hooks_modules"`
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.247
Clickable buttons in plugin UI, built end to end but dark in this build
Both mention module