Overview

This page gives a general overview about the plugin architecture used in MediaPortal 2. It describes the idea behind plugins, what a plugin is able to achieve in MediaPortal 2 and how plugins should be designed. To learn about the underlaying plugin management service or about the technical file layout of plugins, see the PluginManager wiki page.

The Idea Behind Plugins

The MediaPortal 2 application provides a small and (hopefully) stable core system which provides the basic MediaCenter functionality for both the MediaPortal 2 client and server system parts. The core system parts themselves don't provide enough functionality to work as a MediaCenter, as important modules are missing.

Plugins are needed to fill out those missing functionality and to build up a cool and effective MediaCenter application.

Plugins can add functionality to and change many areas of the system. Those areas include:

• Skins or skin enhancements
• Additional languages or single additional language files
• Workflows to be presented in the main menu structure (like the Media workflow)
• Additional services to be called from own or from other code
• Arbitrary active code to be run automatically or in special contexts

There are many plugins included in the default MediaPortal 2 configuration. Some of them are very basic ones like the SkinEngine, which provides the application's UI and the loading of skins and themes. Another basic plugin is the Configuration UI plugin, which provides the configuration interface inside the MediaPortal 2 client. Many other plugins depend on this Configuration plugin.

But there are other plugins which are not that basic. For example, there are several plugins providing access protocols for media files (from the local HDD, via UPnP, via SMB, ...). Disabling some of them means, MediaPortal 2 will no longer be able to access media files via the disabled protocol, which might be a desired behavior. It is also possible to add such protocol plugins, called _ResourceProvider_s, very easily.

Those are only some examples for plugins. The default system provides many more.

Plugin integration

To make a plugin work with MediaPortal 2, its plugin folder must be copied into the Plugins directory of MediaPortal 2. The name and path of that folder can also be controlled by the PLUGINS path configuration in the Paths.xml file, so in some configurations, the plugin folder might be located somewhere else.

Inside the plugin folder, a plugin.xml file is necessary to make that folder a plugin directory. That file is called plugin descriptor.

The plugin descriptor contains all the plugin's metadata like id, name, authors etc. It also registers all skin, localization and code resources to the system.

Dependencies between system parts

Plugins will typically need to reference other system parts. That might be because code in the plugin uses classes from the other system part or because the provided skin is inherited from a skin defined somewhere else (which is typically in plugin SkinBase). System resources (that is all resources of the projects MediaPortal.Utilities, MediaPortal.Common, MediaPortal.UI, MediaPortal.Backend) can simply accessed; for code plugins you can simply add a project reference to those projects.

But to access other plugins, it is important to declare such dependencies in the plugin.xml file! If you don't do so, the plugin loading mechanism doesn't know in which order to load plugins and might load your plugin before the other plugin is loaded, which might lead to unexpected system behaviour.

So please, avoid such implicit dependencies, make them explicit by declaring them in the plugin descriptor, even if the referenced plugin is a very basic plugin like the Configuration, SkinBase or SkinEngine plugins.