In a multisite solution, you need to decide whether the sites can share the same code base, and if there is content that the sites cannot share.
Optimizely CMS can host multiple websites using a shared database, and the same content assets. You can add new sites from the CMS admin view, and the start pages will share the same root page in the content structure. See Setting up multiple sites.
In DXP, sites use the same Web App, and share the same code base and Optimizely Search & Navigation index. You can have an unlimited number of sites in the Web App. Common scenarios include solutions for the fashion industry, where sites may share the same content types and controllers, but each brand use different views and styles, resulting in different outbound presentations.
Consider how to organize your code using standard conventions and site-specific structures. Can the sites share the same code base, or do you need to separate them? Can you work with shared models and controllers, but use different views?
- Restrict blocks to a single site or share blocks across all sites. If possible, limit the number of site-specific content types (pages, blocks, media).
- Limit access to specific content types by using roles/permissions and the AvailableContentTypes attribute.
- Limit ability to add content by using the AllowedTypes attribute on content areas.
Editors with access to multiple sites will have access to all.
Defined display channels and display options are available across all sites. Consider how to manage these if different websites have different requirements. For example, you can use TemplateResolver to detect which template should be active for a specific site.
Forms in a multisite solution are available for selection across sites. To restrict access to forms, you can apply access rights on form folders, just as you do for other types of content items. You can also create a specific virtual role for managing forms.
Optimizely offers built-in categorization functionality to tag content, and build features based on this. Categories are shared between sites in a multisite solution. You can organize categories by site in a hierarchical structure, or you can build your own category system.
Added visitor groups are available for all sites in edit view. You can create a specific role for managing visitor group criteria (optional), and ensure that editors working with content personalization are included in the group, and well-aware of which visitor groups to use in what context.
If sites in a multisite solution are administered by different editors, you can set up site-specific groups to provide editing access in selected parts of the shared content structure. See access rights in the Optimizely user guide.
While available for on-premises versions of Optimizely,Lucene.NET is not supported with DXP. Instead, Optimizely Search & Navigation is included providing advanced search features, and should be leveraged in your search implementation.
Sites with Optimizely Search & Navigation share the same index, and optimizations apply to all sites. Each site has its own partition of the index, and a shared partition for shared content. You can view search results and statistics per site or across all sites; you can limit search results per site.
When translating user interface texts using the built-in localization service, you can create one or more XML files with any name, in the ~/Resources/LanguageFiles folder.
Content types may have the same class name in code, using a different namespace and class name. To ensure that users can differentiate these, use unique DisplayNames. See Localizing the user interface.
Custom cultures such as ”sv-gb” and ”en-fr”, are currently not supported for solutions running in Optimizely DXP. Cultures are part of the standard operating system, and require changes to the registry to modify or add them. This modification is not allowed by the Azure App Service.
See the blog post Implementing custom cultures, CultureInfo, localize Azure App Service for more information.
Installed add-ons are available across all sites. However, you can restrict access through configuration by setting access rights for the location paths.
You can debug on your local machine and in the Integration environment. Debug in other environments only when absolutely needed. See Troubleshooting.
Updated about 2 months ago