-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Plugin dependencies
As your plugins become more and more complex, you will find yourself in the need to manage dependencies between plugins. E.g. you want the hooks of a certain plugin to be executed before yours. You can manage these dependencies in your plugin definition file ep.json
:
{
"parts": [
{
"name": "plugin",
"pre": [],
"post": ["ep_onemoreplugin/partone"]
"hooks": {
"toolbarButtons": "ep_monospace/plugin:getSomeToolbarButtons",
"changeToMonospace": "ep_monospace/plugin:getSomePopups",
}
},
{
"name": "otherpart",
"pre": ["ep_my_example/somepart", "ep_otherplugin/main"],
"post": [],
"hooks": {
"somehookname": "ep_my_example/otherpart:somehook",
"morehook": "ep_my_example/otherpart:morehook"
}
}
]
}
Usually a plugin will add only one functionality at a time, so it will probably only use one part
definition to register its hooks. However, sometimes you have to put different (unrelated) functionalities into one plugin. For this you will want use parts, so other plugins can depend on them.
The "pre"
and "post"
definitions, affect the order in which parts of a plugin are executed. This ensures that plugins and their hooks are executed in the correct order.
"pre"
lists parts that must be executed before the defining part. "post"
lists parts that must be executed after the defining part.
You can, on a basic level, think of this as double-ended dependency listing. If you have a dependency on another plugin, you can make sure it loads before yours by putting it in "pre"
. If you are setting up things that might need to be used by a plugin later, you can ensure proper order by putting it in "post"
.
Note that it would be far more sane to use "pre"
in almost any case, but if you want to change config variables for another plugin, or maybe modify its environment, "post"
could definitely be useful.
Also, note that dependencies should also be listed in your package.json, so they can be npm install
'd automagically when your plugin gets installed.
- Docs
- Translating
- HTTP API
- Plugin framework (API hooks)
- Plugins (available)
- Plugins (list)
- Plugins (wishlist)
- Etherpad URIs / URLs to specific resources IE export
- Etherpad Full data export
- Introduction to the source
- Release Procedure
- Etherpad Developer guidelines
- Project to-do list
- Changeset Library documentation
- Alternative Etherpad-Clients
- Contribution guidelines
- Installing Etherpad
- Deploying Etherpad as a service
- Deploying Etherpad on CloudFoundry
- Deploying Etherpad on Heroku
- Running Etherpad on Phusion Passenger
- Putting Etherpad behind a reverse Proxy (HTTPS/SSL)
- How to setup Etherpad on Ubuntu 12.04 using Ansible
- Migrating from old Etherpad to Etherpad
- Using Etherpad with MySQL
- Customizing the Etherpad web interface
- Enable import/export functionality with AbiWord
- Getting a list of all pads
- Providing encrypted web access to Etherpad using SSL certificates
- Optimizing Etherpad performance including faster page loads
- Getting to know the tools and scripts in the Etherpad /bin/ folder
- Embedding a pad using the jQuery plugin
- Using Embed Parameters
- Integrating Etherpad in a third party app (Drupal, MediaWiki, WordPress, Atlassian, PmWiki)
- HTTP API client libraries