A plugin system should ideally support things like:
- [[todo/lists]] of pages, of mising pages / broken links, of registered users, etc
- a [[todo/link_map]]
- [[pageindexes]]
- Wiki stats, such as the total number of pages, total number of links, most linked to pages, etc, etc.
- wiki info page, giving the ikiwiki version etc
- would it be useful to reimplement the hyperestradier search integration as a plugin?
- Support [[RecentChanges]] as a regular page containing a plugin that updates each time there is a change, and statically builds the recent changes list. (Would this be too expensive/inflexible? There might be other ways to do it as a plugin, like making all links to RecentChanges link to the cgi and have the cgi render it on demand.)
- etc
- For another type of plugin, see [[todo/PluggableRenderers]].
Another, separate plugin system that already (mostly) exists in ikiwiki is
the RCS backend, which allows writing modules to drive other RCS systems
than subversion.
preprocessor plugins
done
case study: Moin Moin plugins
See http://moinmoin.wikiwikiweb.de/MoinDev/PluginConcept
6 different types of plugins:
- actions are possibly out of scope for ikiwiki, this is probably what it uses for cgi script type stuff. Unless ikiwiki wants to allow pluggable CGI script stuff, it doesn't need these.
- parsers and formatters are basically what I've been calling [[PluggableRenderers]]. MoinMoin separates these, so that a page is parsed to (presumbly) some intermediate form before being output as html or some other form. That's a nice separation, but what to do about things like markdown that are both a parser and a formatter?
- macros and processors are analagous to preprocessor directives. A processor can operate on a large block of text though.
- themes should be irrellevant (ikiwiki has [[templates]]).
|
