Disclaimer: This website requires Please enable JavaScript in your browser settings for the best experience.

HomeDev GuideRecipesAPI Reference
Dev GuideAPI ReferenceUser GuideLegal TermsGitHubNuGetDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Package and deploy CMS apps

Describes the CMS app (add-on) concept, and how to package and deploy apps.

An add-on contains components that extend the functionality of an Optimizely Content Management System (CMS) website, such as initializable modules, gadgets, visitor group criteria, virtual path providers, page and search providers, and so on.

Configure shell modules

An add-on is packaged and deployed as a shell module. 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 /modules/QuickChat.

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

<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. Optimizely 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 module assemblies automatically on start-up. The default is minimal. If you change this to modules, folders are automatically added as modules below the root path.

Module (add element)

The publicModules and protectedModules elements in web.config contain a collection of registered modules. These modules define assemblies and virtual paths. By default, you should find a module in a folder whose name matches the module. This folder is 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 overrides 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):

<add name="ShellExtras" 
     resourcePath="~/Somewhere/Else/Extras"
     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, where you can specify additional module-specific settings.