Making a Plug-In part of the Core Code

Owned by Jessica Crouch
Last updated: Jul 23, 2020 by Christine Di Bella
2 min read

A plugin is an enhancement that overrides or extends functionality of ArchivesSpace without requiring changes to the application’s own code. ArchivesSpace’s architecture is designed to support a range of plugins, and plugins can be a great introduction to developing for ArchivesSpace.

Advantages to writing plugins include:

  • Lower technical barrier than for writing for the core code or a custom build.
  • Plugins can support many different ways of doing something, or ways that deviate from the practices supported by the ArchivesSpace standard distribution.
  • Plugins are optional; only those that want to use a particular plugin will be affected by the changes it makes in the application.
  • Writing a plugin can often be quick and requires little consultation with others or adherence to the standards of others.

Disadvantages to writing plugins include:

  • You will need to maintain and support the plugin yourself.
  • Enabling a plugin requires access to the ArchivesSpace server and some IT providers limit or restrict the use of plugins. This will limit the audience for your feature.
  • There may be duplication of effort across the community, as you may not realize that someone else has already written a plugin that does the same thing yours does.

People in the ArchivesSpace community have written a lot of great plugins, some having limited applicability to other institutions, while others do things that many people want. If your plugin is in the latter category, it may be worth considering for the core code of ArchivesSpace.

One of the simplest and quickest ways to begin writing for the ArchivesSpace core code is to take an existing plugin and convert it into a pull request to the master branch of ArchivesSpace. Because plugins override or extend code that’s in the core code, turning them into pull requests for additions to the core code can be as easy as checking the difference between the lines in the plugin files and those in ArchivesSpace master, revising the lines that are different in the files from ArchivesSpace master, and creating a pull request. Information about submitting a pull request is at https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/39682053/Submitting+a+Pull+Request.

The exception to the rule of plugins being easy to convert is if the plugin impacts the data model of ArchivesSpace. In such cases, additional care will need to be taken to determine whether and how best to represent the feature in ArchivesSpace, especially if the data model in the core code has changed since the plugin was written. Even so, converting the plugin is often simpler than starting from scratch.

If you’re thinking about turning a plugin into a potential submission for the core code of ArchivesSpace, especially when it comes to a larger feature, we encourage you to read through ArchivesSpace Process for Evaluating Potential Feature Contributions to the Core Code. Step 1 will be especially relevant, but the others may apply as well, depending on the complexity of your feature and plugin. Contact Christine Di Bella, the ArchivesSpace Program Manager (christine.dibella@lyrasis.org), if you’d like to start the process.

If you need help converting your plugin into a core code submission, ArchivesSpace developers and members of the Core Committers group would be glad to advise.