Try our conversational search powered by Generative AI!

Loading...
Area: Optimizely CMS
ARCHIVED This content is retired and no longer maintained. See the latest version here.

Recommended reading 

An add-on contains components that extend the functionality of the EPiServer website, such as initializable modules, gadgets, visitor group criteria, virtual path providers, page and search providers, and so on. An add-on is packaged and deployed as a Shell module.

EPiServer provides add-ons for site administrators to install to EPiServer websites. 

Configuring Shell modules

Configure modules in web.config to associate a virtual path to an assembly that contains gadgets and other plug-ins. The following example defines a module of the assembly QuickChat.dll and associates it with the virtual path /public/QuickChat.

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

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

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

protectedModules and publicModules

These elements contain collections of shell modules. EPiServer maps protectedModules to a path protected by ASP.NET authorized rules, and maps publicModules to a path that is open to everyone.

Attributes:

  • rootPath. The root path where modules are 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 results in automatically adding folders as modules below the root path.

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. Required. The name of the module used to find the module directory.
  • resourcePath. Optional. The path of the module to override the default location of the module.
  • clientResourcePath. Optional. An alternative location for client resources. By default this path is the same as resourcePath.

Elements:

  • assemblies. Assemblies to load and associate with the module. You can combine this value with assemblies defined by the module depending on the auto discovery option.

Example (web.config):

XML
<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 has a manifest file (module.config) in the root directory of the module where you can specify further module specific settings.

Related topics

Do you find this information helpful? Please log in to provide feedback.

Last updated: Feb 23, 2015

Recommended reading