Wikis are extensible. Plugins add features the core doesn't provide: custom rendering, integrations, workflows, analytics. Plugin systems vary by wiki platform.
This page covers the patterns for developing plugins that work and stay maintainable.
Convert custom syntax to HTML. [{Calendar}]() becomes a calendar widget.
Pre/post-process content. Strip HTML; apply transformations; insert metadata.
React to events: page saved, user logged in, comment posted.
Pluggable storage: page provider, attachment provider, user provider, search provider.
Custom UI elements: toolbar buttons, custom forms, dashboard widgets.
Connect to external systems: Slack notifications, JIRA links, GitHub commits.
Hook-based. Each extension registers for hooks and provides handlers.
Mature; many available; well-documented.
Atlassian Connect / Forge. Cloud-based; more constrained model than self-hosted plugins.
Action plugins, syntax plugins, helper plugins. Object-oriented.
Multiple extension mechanisms (per CLAUDE.md):
[{Plugin}]() syntaxEach plugin does one thing. Plugins that try to do many things become brittle.
Plugins should be configurable. Hard-coded behavior limits reuse.
plugin_name:
enabled: true
some_setting: value
Out of the box, plugin should work without configuration. Custom config for advanced needs.
What happens when the plugin fails? Wiki should continue; just the plugin's portion broken.
A plugin that takes the wiki down on error is a bad plugin.
Plugin uses only the platform's stable API. Doesn't reach into internals; doesn't depend on undocumented behavior.
Plugins typically have:
Handle each appropriately.
Some plugins have configuration UIs. The platform usually provides framework for this.
For complex config, separate page; simple config can be inline.
Each plugin needs:
Without this, users can't adopt.
Plugins evolve. Semantic versioning helps consumers know about breaking changes.
For widely-distributed plugins, version compatibility matrices.
Unit tests for plugin logic; integration tests against the wiki platform.
For complex plugins, automated testing is essential. For simple, smoke tests may suffice.
Plugins that render on every page view affect performance. See WikiPerformanceTuning.
Cache renderer output where possible.
Hooks that fire on every page save: keep them fast. Slow hooks slow saves.
Plugin makes API calls to external service: each call adds latency.
For non-critical: async (fire and forget). For required: timeout aggressively; handle failure.
Plugins that query the database: indexed queries; pooling; pagination.
Most plugin slowness comes from one of these.
Plugins age. Wiki platform updates; plugin may break. Maintain or deprecate.
For platform upgrades: test plugins. Update for new APIs.
When a plugin is no longer needed, remove cleanly. Deactivate; remove; verify wiki still works.
Some plugins ship with the wiki. Pre-installed.
Public plugins available for installation. Atlassian Marketplace for Confluence; Extension:Distribution for MediaWiki.
For organization-specific plugins, internal distribution.
Clone from source; build; install. Common for custom plugins.
Per the codebase context:
[{Plugin}]() syntax: e.g., a [{TableOfContents}]() plugin auto-generates a TOCStructuralSpinePageFilter enforces structural-spine schema at save timeFileSystemProvider for page storageThe Wikantik plugin pattern uses standard interfaces; implementations registered via configuration or auto-discovery.
Unhandled exceptions in hooks. Catch; log; continue.
Reaches into internals not in the public API. Breaks on platform updates.
Users can't install or configure.
Plugin is fast in isolation; slow at scale.
New version incompatible with old; users can't upgrade gracefully.
Plugin requires extensive configuration; nobody understands the options.
For new plugin development: