Plugins 102 - Site-Specific Multi-Purpose plugins

General discussion about MantisBT Plugins

Moderators: Developer, Contributor

Post Reply
Starbuck
Posts: 219
Joined: 14 Feb 2006, 02:53
Location: USA
Contact:

Plugins 102 - Site-Specific Multi-Purpose plugins

Post by Starbuck »

People have preferences for how they'd like Mantis to work. These preferences don't apply to everyone. So while a general purpose plugin like EmailReporting is very popular, and has its own forum board here, other customizations aren't of interest to a general audience, so they should probably not be published as plugins for everyone else to consider.

For example, today there was a post about how to change the request URL from HTTP to HTTPS. Note here that @atrol suggests letting the web server do the routing. The point for purposes here is that there is no one solution that fits all sites or preferences, and this specific function would probably not be a good candidate for a general-purpose plugin.

Some functionality can be achieved with just a single line of code. It usually doesn't make sense to have a whole plugin dedicated to that one line, as it adds a lot of overhead to your site.

You might want a bunch of small features and tweaks to Mantis that are not available as general-purpose plugins. Rather than creating a separate plugin for each purpose, and just not publishing it, it might be better to create a single multi-purpose plugin just for internal use.

To start, go through the documentation and create for yourself a single plugin that does nothing. Just get to a point where you can activate and de-active this do-nothing plugin.

If your company is ABC Corp, you might want to name it as the "ABC Corp Mantis Plugin", which is of no use to any other site. If you support more than one Mantis installation, it might be better to give it a generic name, like "Site-Specific Features", and just install that "toolkit" wherever you go. If the plugin requires changes for one site, that might be a clue that you should make it more generic in places to accommodate similar changes for other sites.

Now add a single, simple feature. Don't challenge yourself yet to do something huge. Allow yourself the opportunity to be successful with something small.

On success, add documenation for the code, and for the feature in general - you'll appreciate this within days, certainly weeks, months, or years later.

Over time add functionality to it. As you find valuable HowTo's around here, incorporate them into your own multi-purpose plugin.

Be careful not to break existing functionality as you make changes. I'd advise that you do not use your primary plugin for experiments and new development. Create another plugin for each new experiment, get it to work, port your code into the primary multi-purpose plugin, and then remove the experiment. It should go without saying (to experienced developers anyway) that you should do all of this in a test environment, use common techniques to ensure there aren't conflicts with other code, and that you should QA your code under various conditions to ensure you're not breaking other things. When you get it all working, port it to your live system.

It would be a good practice to allow for enabling/disabling any single functionality in your multi-purpose plugin using config_inc.php, just like we see for the Mantis Core. At some point you might want to publish your plugin in a public repository, add documentation for each function, and note that while it's free to whomever wants to use it, it is not "supported" for general use. This allows others to learn from it, use just what they want by toggling config settings, and improve on it for you. This is the spirit of FOSS.

It's easy to see that anyone doing this will quickly develop great skills for plugin maintenance. I encourage you to post your challenges here for others, your successes and failures. Post your code snippets and share with others how you interfaced with Mantis to achieve your goals. From this we'll all learn, improve our skills, and create better plugins to add into this ecosystem.

I'll stop here, but there's more to be said for managing multi-purpose plugins. For example, how exactly do we code these concepts into our plugins? how do we port a plugin from a test site to live? How do we handle a new installation versus an upgrade? How do we break functionality out of a multi-purpose plugin and offer it as a general-purpose plugin? I'll go over these topics later.
If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!
Post Reply