moin-2.0 / docs / devel / plugins.rst


Partly implemented and need more work.


Plugin development

Creating custom plugins

The best way to create a plugin is by making a separate Python package.


You can use ExamplePlugin package located in :file:`contrib` directory as a starting point.

Plugin system is based on OO principles and uses Python ABCs . All plugin types must implement their specific base class provided by MoinMoin package. All base classes are currently located in :keyword:`MoinMoin.plugin` module.

Distribution / Installation / Discovery / Loading

Plugins must be on sys.path so that they can be imported. The most convent method of distribution is creating a package. List of plugin packages which should be loaded is stored in configuration under key plugins_enabled.

Example configuration:

from wikiconfig import *

class LocalConfig(Config):
    plugins_enabled = [
MOINCFG = LocalConfig


Plugin Configuration


As of now there aren't too many examples. There is an example plugin located in :file:`contrib/ExamplePlugin`. Also most of the plugin types have built-in plugins in :keyword:`MoinMoin` package itself and you can use them as reference.

Plugin system development


New code

If possible new modules which are implemented as plugins shouldn't use wrappers as it's extra code and complexity which is not needed. Wrappers as they are used now is a simple way out of a lot of refactoring to make already written functionality into something that fits with the plugin system.

Plugin loading/config chicken-egg problem

For now I'm solving it by moving some of the function calls out of config. It seems very logical that config doesn't call major app functions when it's made (util functions are fine) and those are all called when config has been parsed/initialized.


At the moment already defined themes have higher priority than those defined in Blueprint Plugin package. For example if blueprint tries to render "index.html" template and it has it in "BlueprintPlugin/templates/index.html" folder, it will still render the default "index.html" template found in :file:`MoinMoin/templates` directory. I think I can "fix" it by changing theme code a bit (the render_template method which I already changed in themes plugin implementation). Another way is to simply prefix templates in Blueprint packages. Basically have to chose which have higher priority, as it is now, it makes sense considering how themes work.


Currently we have no way to read it without initializing the plugin itself. This should be fixed somehow later on.


Should be handled by plugin authors, Moin should expose helper functions and provide examples to make it easier for plugin authors.

Plugin loading

So far it works more or less like this:

  1. Admin provides list of enabled plugin packages.
  2. System loads all of these packages.
  3. System initializes all clases which implement PluginBase, giving as parameter their config.

You can quite easily add more layers of who enables what especially if you have layered configuration.


  • Write the rest of the wrappers, not all inbuilt functionality have wrappers. Finish writing those so all already written code can be used in configuration.
  • Finish the rest of the plugin types
  • Slowly move away from wrappers around already supported classes and integrate plugin system more tightly with the core code. This requires quite a lot refactoring.
  • If new plugin types are introduced or new code "modules" which could become type of a plugin, they shouldn't use wrappers, but instead have most of the code in the plugin base class.
  • More configuraton, plugin examples are needed. Still a good reference is inbuilt plugins.
  • i18n helper functions just to make it easier for plugin authors to implement i18n. (Some examples would also help)
  • Refactor startup code, right now the code seems very non-linear and all over the place which means there are sometimes problems accessing things which are not initialized yet. There should be a clear pipeline of what starts after what and where.
  • Need more core plugin system tests.
  • Refactor theme code, it should be more straight forward.
  • Introduce a plugin container so you don't have to rewrite all the meta information if it stays the same across multiple plugin types in a plugin package.
  • Add signals to the core code. Some good examples which need to be added: - Stores are ready (plugins can write stuff to store) - App has been created and can be accessed.
  • Some day we could have nice web interface for site admins to enable/disable plugins.
  • Maybe ACL helper functions for plugins, need more research.
Plugin types and other functionality


  • Auth

  • Themes

  • Stores

  • Blueprints

  • Serialized items
    • Not tested but should be doable with most plugins, need a way to initiate the process (Could be Blueprint or Commandline Script)

On hold:

  • Items
    • Too volatile, more than one person working on them at the moment.

Not done:

  • Adding signals to moinmoin core code where it makes sense

  • Commandline Scripts

  • Other mimetype support plugins

  • Converters/macros

  • Other implementation of groups/dicts/etc. (low priority)
    • Need more info
  • Backend (low priority)

  • Notifications (low priority)