Add-ons

This document provides an introduction to the module and add-on concept in the EPiServer platform. The Add-ons system shipped with EPiServer allows site administrators to install add-on modules to EPiServer websites. An add-on can contain components that extend the functionality of the EPiServer website, like initializable modules, gadgets, visitor group criteria, virtual path providers, page and search providers. Add-ons are packaged and deployed as Shell modules.

Configuring Shell modules

Modules are configured in the web.config file to allow EPIServer to associate a virtual path to an assembly containing gadgets and other plug-ins.

Example:

<episerver.shell>
  <publicModules rootPath="~/modules/" autoDiscovery="Minimal">
    <add name="QuickChat">
      <assemblies>
        <add assembly="QuickChat" />
      </assemblies>
    </add>
  </publicModules>
</episerver.shell>

The example above defines a module of the assembly QuickChat.dll and associates it with the virtual path /public/QuickChat.

Example (relocated resource path):

<episerver.shell>
   <publicModules rootPath="~/modules/" autoDiscovery="Minimal">
      <add name="PublicTemplates" resourcePath="~/">
          <assemblies>
             <add assembly="EPiServer.Templates.Public" />
         </assemblies>
      </add>
   </publicModules>
</episerver.shell>

The example above configures a module called “PublicTemplates”. The module’s location on disk is the root of the application (~/). This means that relative references to client resources and menu items will be based on this URL. Furthermore, the module is mapped to an assembly, EPiServer.Templates.Public. This means that controllers in this assembly are routed through the path format “/modules/PublicTemplates/{controller}/{action}”. This route is set up by the shell initialization module.

protectedModules and publicModules

These elements contain collections of shell modules. protectedModules are mapped to a path protected by ASP.NET authorized rules. publicModules’ path is open to everyone.

Attributes:

• rootPath. The root path where modules will be located and routed. Required.
• autoDiscovery. Option for probing the module folder and loading of module assemblies automatically on start-up. The default is “Minimal”. Changing this to “Modules” will result in folders below the root path to be added as modules automatically.

Module (add element)

The publicModules and protectedModules elements themselves in web.config contain a collection of registered modules. These modules define assemblies and virtual paths. By default a module is expected to be found in a folder with the same name as the module itself. This folder should be located in the configured rootPath (as configured per public and protected modules).

Attributes:

• name. The name of the module used to find the module directory. Required.
• resourcePath. The path of the module to override the default location of the module. Optional.
• clientResourcePath. An alternative location for client resources. By default this path is the same as resourcePath. Optional.

Elements:

• assemblies. Assemblies to load and associate with the module. This value may be combined with assemblies defined by the module depending on the auto discovery option.

Example (web.config):

<add name="ShellExtras" 
     resourcePath="~/Somewhere/Else/Extras"&#160;clientResourcePath="~/Somewhere/Else/Entirely/Extras">
   <assemblies>
     <add assembly=" EPiServer.Shell.Extras" />
  </assemblies>
</add>

Module manifest

Each module also has a manifest file (module.config) in the root directory of the module where further module specific settings can be specified.

See also

• Configuring module.config
• Developing add-ons
• Add-on system command line support