Plugin Development

The capabilities of Girder can be extended via plugins. The plugin framework is designed to allow Girder to be as flexible as possible, on both the client and server sides.

A plugin is self-contained in a single directory. To create your plugin, simply create a directory within the plugins directory. In fact, that directory is the only thing that is truly required to make a plugin in Girder. All of the other components discussed henceforth are optional.

Example Plugin

We’ll use a contrived example to demonstrate the capabilities and components of a plugin. Our plugin will be called cats.

cd plugins ; mkdir cats

The first thing we should do is create a plugin.json file in the cats directory. As promised above, this file is not required, but is strongly recommended by convention. This file contains high-level information about your plugin.

touch cats/plugin.json

This JSON file should specify a human-readable name and description for your plugin, and can optionally contain a list of other plugins that your plugin depends on. If your plugin has dependencies, the other plugins will be enabled whenever your plugin is enabled. The contents of plugin.json for our example will be:

"name": "My Cats Plugin",
"description": "Allows users to manage their cats.",
"dependencies": ["other_plugin"]

This information will appear in the web client administration console, and administrators will be able to enable and disable it there. Whenever plugins are enabled or disabled, a server restart will be required in order for the change to take effect.

Extending the Server-Side Application

Girder plugins can augment and alter the core functionality of the system in almost any way imaginable. These changes can be achieved via several mechanisms which are described below. First, in order to implement the functionality of your plugin, create a server directory within your plugin, and make it a Python package by creating

cd cats ; mkdir server ; touch server/

This package will be imported at server startup if your plugin is enabled. Additionally, if your package implements a load function, that will be called. This load function is where the logic of extension should be performed for your plugin.

def load(info):

This load function must take a single argument, which is a dictionary of useful information passed from the core system. This dictionary contains an apiRoot value, which is the object to which you should attach API endpoints, a config value, which is the server’s configuration dictionary, and a serverRoot object, which can be used to attach endpoints that do not belong to the web API.

Within your plugin, you may import packages using relative imports or via the girder.plugins package. This will work for your own plugin, but you can also import modules from any active plugin. You can also import core Girder modules using the girder package as usual. Example:

from girder.plugins.cats import some_module
from girder import events

Adding a new route to the web API

If you want to add a new route to an existing core resource type, just call the route() function on the existing resource type. For example, to add a route for GET /item/:id/cat to the system,

from girder.api import access

def myHandler(id, params):
    return {
       'itemId': id,
       'cat': params.get('cat', 'No cat param passed')

def load(info):
    info['apiRoot'].item.route('GET', (':id', 'cat'), myHandler)

You should always add an access decorator to your handler function to indicate who can call the new route. The decorator is one of @access.admin (only administrators can call this endpoint), @access.user (any user who is logged in can call the endpoint), or @access.public (any client can call the endpoint).

If you do not add an access decorator, a warning message appears: WARNING: No access level specified for route GET item/:id/cat. The access will default to being restricted to administrators.

When you start the server, you may notice a warning message appears: WARNING: No description docs present for route GET item/:id/cat. You can add self-describing API documentation to your route as in the following example:

from girder.api.describe import Description
from girder.api import access

def myHandler(id, params):
    return {
       'itemId': id,
       'cat': params.get('cat', 'No cat param passed')
myHandler.description = (
    Description('Retrieve the cat for a given item.')
    .param('id', 'The item ID', paramType='path')
    .param('cat', 'The cat value.', required=False)

That will make your route automatically appear in the Swagger documentation and will allow users to interact with it via that UI. See the RESTful API docs for more information about the Swagger page.

If you are creating routes that you explicitly do not wish to be exposed in the Swagger documentation for whatever reason, you can set the handler’s description to None, and then no warning will appear.

myHandler.description = None

Adding a new resource type to the web API

Perhaps for our use case we determine that cat should be its own resource type rather than being referenced via the item resource. If we wish to add a new resource type entirely, it will look much like one of the core resource classes, and we can add it to the API in the load() method.

from import Resource

class Cat(Resource):
    def __init__(self):
        self.resourceName = 'cat'

        self.route('GET', (), self.findCat)
        self.route('GET', (':id',), self.getCat)
        self.route('POST', (), self.createCat)
        self.route('PUT', (':id',), self.updateCat)
        self.route('DELETE', (':id',), self.deleteCat)

    def getCat(self, id, params):

def load(info):
    info['apiRoot'].cat = Cat()

Adding a new model type in your plugin

Most of the time, if you add a new resource type in your plugin, you’ll have a Model class backing it. These model classes work just like the core model classes as described in the Models section. They must live under the server/models directory of your plugin, so that they can use the ModelImporter behavior. If you make a Cat model in your plugin, you could access it using

self.model('cat', 'cats')

Where the second argument to model is the name of your plugin.

The events system

In addition to being able to augment the core API as described above, the core system fires a known set of events that plugins can bind to and handle as they wish.

In the most general sense, the events framework is simply a way of binding arbitrary events with handlers. The events are identified by a unique string that can be used to bind handlers to them. For example, if the following logic is executed by your plugin at startup time,

from girder import events

def handler(event):

events.bind('some_event', 'my_handler', handler)

And then during runtime the following code executes:

events.trigger('some_event', info='hello')

Then hello would be printed to the console at that time. More information can be found in the API documentation for Events.

There are a specific set of known events that are fired from the core system. Plugins should bind to these events at load time. The semantics of these events are enumerated below.

  • Before REST call

Whenever a REST API route is called, just before executing its default handler, plugins will have an opportunity to execute code or conditionally override the default behavior using preventDefault and addResponse. The identifiers for these events are of the form rest.get.item/:id.before. They receive the same kwargs as the default route handler in the event’s info.

  • After REST call

Just like the before REST call event, but this is fired after the default handler has already executed and returned its value. That return value is also passed in the for possible alteration by the receiving handler. The identifier for this event is, e.g., rest.get.item/:id.after. You may alter the existing return value or override it completely using preventDefault and addResponse on the event.

  • Before model save

You can receive an event each time a document of a specific resource type is saved. For example, you can bind to if you wish to perform logic each time a folder is saved to the database. You can use preventDefault on the passed event if you wish for the normal saving logic not to be performed.

  • After model save

You can also receive an event after a resource of a specific type is saved to the database. This is useful if your handler needs to know the _id field of the document. You cannot prevent any default actions with this hook. The format of the event name is, e.g.

  • Before model deletion

Triggered each time a model is about to be deleted. You can bind to this via e.g., model.folder.remove and optionally preventDefault on the event.

  • Override model validation

You can also override or augment the default validate methods for a core model type. Like the normal validation, you should raise a ValidationException for failure cases, and you can also preventDefault if you wish for the normal validation procedure not to be executed. The identifier for these events is, e.g., model.user.validate.

  • Override user authentication

If you want to override or augment the normal user authentication process in your plugin, bind to the auth.user.get event. If your plugin can successfully authenticate the user, it should perform the logic it needs and then preventDefault on the event and addResponse containing the authenticated user document.

  • On file upload

This event is always triggered asynchronously and is fired after a file has been uploaded. The file document that was created is passed in the event info. You can bind to this event using the identifier data.process.


If you anticipate your plugin being used as a dependency by other plugins, and want to potentially alert them of your own events, it can be worthwhile to trigger your own events from within the plugin. If you do that, the identifiers for those events should begin with the name of your plugin, e.g., events.trigger('cats.something_happened', info='foo')

Automated testing for plugins

Girder makes it easy to add automated testing to your plugin that integrates with the main Girder testing framework. In general, any CMake code that you want to be executed for your plugin can be performed by adding a plugin.cmake file in your plugin.

cd plugins/cats ; touch plugin.cmake

That file will be automatically included when Girder is configured by CMake. To add tests for your plugin, you can make use of some handy CMake functions provided by the core system. For example:

add_python_test(cat PLUGIN cats)
add_python_style_test(python_static_analysis_cats "${PROJECT_SOURCE_DIR}/plugins/cats/server")

Then you should create a plugin_tests package in your plugin:

mkdir plugin_tests ; cd plugin-tests ; touch

The file should look like:

from tests import base

def setUpModule():

def tearDownModule():

class CatsCatTestCase(base.TestCase):

    def testCatsWork(self):

You can use all of the testing utilities provided by the base.TestCase class from core. You will also get coverage results for your plugin aggregated with the main Girder coverage results if coverage is enabled.

Extending the Client-Side Application

The web client may be extended independently of the server side. Plugins may import Jade templates, Stylus files, and JavaScript files into the application. The plugin loading system ensures that only content from enabled plugins gets loaded into the application at runtime.

All of your plugin’s extensions to the web client must live in a directory in the top level of your plugin called web_client.

cd plugins/cats ; mkdir web_client

Under the web_client directory, there are three optional subdirectories that can be used to import content:

  • stylesheets: Any files ending with .styl in this directory or any of its subdirectories will be automatically built into CSS and loaded if your plugin is enabled. These files must obey Stylus syntax. Because these CSS scripts are imported after all of the core CSS, any rules you write will override any existing core style rules.
  • templates: Any files ending with .jade in this directory or any of its subdirectories will be automatically built as templates available in the application. Just like in core, these templates are uniquely identified by the name of their file; e.g., myTemplate.jade could be rendered at runtime by calling jade.templates.myTemplate(). So, if you want to override an existing core template, simply create one in this directory with the same name. If you want to create a template that is not an override of a core template, but simply belongs to your plugin, convention dictates that it should begin with your plugin name followed by an underscore to avoid collisions, e.g., cats_catPage.jade. Documentation for the Jade language can be found here.
  • js: Any files ending with .js in this directory or any of its subdirectories will be compiled using uglify and imported into the front-end application. The compiled JavaScript file will be loaded after all of the core JavaScript files are loaded, so it can access all of the objects declared by core. The source map for these files will be automatically built and served as well.
  • extra: Any files in this directory or any of its subdirectories will be copied into the extra directory under your plugin’s built static directory. Any additional public static content that is required by your plugin that doesn’t fall into one of the above categories can be placed here, such as static images, fonts, or third-party static libraries.

Executing custom Grunt build steps for your plugin

For more complex plugins which require custom Grunt tasks to build, the user can specify custom targets within their own Grunt file that will be executed when the main Girder Grunt step is executed. To use this functionality, add a grunt key to your plugin.json file.

"name": "MY_PLUGIN",
    "file" : "Gruntfile.js",
    "defaultTargets": [ "MY_PLUGIN_TASK" ]

This will allow to register a Gruntfile relative to the plugin root directory and add any target to the default one using the “defaultTargets” array.


The file key within the grunt object must be a path that is relative to the root directory of your plugin. It does not have to be called Gruntfile.js, it can be called anything you want.

All paths within your custom Grunt tasks must be relative to the root directory of the Girder source repository, rather than relative to the plugin directory.

module.exports = function (grunt) {
    grunt.registerTask('MY_PLUGIN_TASK', 'Custom plugin build task', function () {
        /* ... Execute custom behavior ... */

JavaScript extension capabilities

Plugins may bind to any of the normal events triggered by core via the object. This will accommodate certain events, such as before and after the application is initially loaded, and when a user logs in or out, but most of the time plugins will augment the core system using the power of JavaScript rather than the explicit events framework. One of the most common use cases for plugins is to execute some code either before or after one of the core model or view functions is executed. In an object-oriented language, this would be a simple matter of extending the core class and making a call to the parent method. The prototypal nature of JavaScript makes that pattern impossible; instead, we’ll use a slightly less straightforward but equally powerful mechanism. This is best demonstrated by example. Let’s say we want to execute some code any time the core HierarchyWidget is rendered, for instance to inject some additional elements into the view. We use the girder.wrap function to wrap the method of the core prototype with our own function.

girder.wrap(girder.views.HierarchyWidget, 'render', function (render) {
    // Call the underlying render function that we are wrapping;

    // Add a link just below the widget
    this.$('.g-hierarchy-widget').after('<a class="cat-link">Meow</a>');

Notice that instead of simply calling render(), we call That is important, as otherwise the value of this will not be set properly in the wrapped function.

Now that we have added the link to the core view, we can bind an event handler to it to make it functional:['click'] = function () {

This demonstrates one simple use case for client plugins, but using these same techniques, you should be able to do almost anything to change the core application as you need.