Sitecore Experience Accelerator (SXA) FAQ

Find the answers to commonly asked questions on SXA installations.

Yes (and no). The challenges of mixing SXA with other solutions are the same as with running any two solutions from different implementers on a single Sitecore instance. Non-SXA sites and SXA sites share pipelines, and both attempt to add processors and modify Sitecore behavior to its needs.

SXA did extensive reviews of all pipelines within recent releases. We have made sure we abort our processors whenever we detect that they are running outside of the context of SXA sites, for the very purpose of limiting any interference that SXA could cause for another solution.

We have tested it working with the Habitat and confirmed that they could run side by side. SXA should be as unobtrusive as any Sitecore solution can be to another solution.

On the other hand, SXA is not in control of the behavior of the processors from the other solution - which means the cohabiting code also needs to be a good neighbor and check for interference with SXA’s operation if it is to be deployed to the instance that co-hosts SXA.

Important

Integration due diligence QA is always necessary when there are two solutions running in a single process.

Yes. A non-SXA site does not participate in a tenant's operations, but it should not cause problems either. For SXA, a tenant is mostly a container for templates and the grouping under /sitecore/content is only reflecting that. It is the site that is a unit of execution.

Yes. SXA pages can contain both SXA and non-SXA components. You can include these components in sitecore/Content/Tenant/Site/Presentation/Available renderings. The components can be placed on the page and will function as long as they are not making assumptions as to the site structure that is conflicting with SXA. If this happens, you can usually mitigate this fairly easily.

You can choose to create an SXA rendering of your component. If you choose not to convert the component into SXA components, the component will not be able to:

  • Use SXA styles. Styling these components can be more difficult.

  • Use SXA grid settings. Resizing these components can be more difficult.

  • Participate in the Creative Exchange styling process.

No. SXA components do not function outside of SXA sites. Because SXA components make many assumptions about, for example, the site structure, the data sources, this possibility is disabled.

No. SXA has no inherent limit other than those of the platform itself. SXA is as scalable as the Sitecore environment to which you deploy it. Please consult the general platform architecture recommendations with your partner.

No. SPE module is only used or required for certain Content Management tasks, and you should not deploy it on Content Delivery servers.

There is a matching SPE WDP file on the download page in the Azure section for every SXA release.

  • Most of the components are rendered using Rendering Variants that are defined as Sitecore items and are in full control of the client/developers.

  • The JavaScript that provides functionality for a component exists in a Base theme that is under SXA’s control. Extracting the JavaScript from the site theme means that when we find a problem or need to provide additional functionality, Sitecore can do it without interfering with the client theme.

  • The markup of components does not change often.

  • SXA 1.8 introduced the ability to replace markup for existing components, which means that even if we changed it in a future version, you could revert it to the old markup if needed.

  • When SXA introduces a big change to a component, it is marking the old component as obsolete (and does not deploy it to sites that you create after the upgrade). Your existing sites can keep using the old version.

  • When the data structures for components change (data source or rendering parameters), we provide migration scripts that perform the transformation to a new structure.

Important

You must always verify that your website looks and feels consistent with how it worked before the upgrade. Themes are considered customization and Sitecore does not modify your themes to comply with any possible changes introduced to the markup.