Experience Cloud Developer Guide

Get Up to Speed with Experience Builder Sites
Develop Experience Builder Sites: The Basics
Brand Your Aura Site
Develop Secure Sites: Authenticated and Guest Users
Develop Secure Sites: CSP, LWS, and Lightning Locker
Analyze and Improve Experience Builder Site Performance
Add Pardot Tracking to Your Experience Builder Site
Use a CMS with Your Experience Builder Site
Report on Deflections: The Deflection Signals Framework
Deploy an Experience Cloud Site from Sandbox to Production
Deploy Your Experience Cloud Site with Change Sets
Deploy Your Experience Cloud Site with the Metadata API
ExperienceBundle for Experience Builder Sites
Avoid Deployment Issues When Moving to Enhanced LWR Sites
Considerations for Deploying Authenticated LWR Sites
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Avoid Deployment Issues When Moving to Enhanced LWR Sites

From Winter ’24, you can no longer disable the enhanced sites and content platform, which was first introduced in Winter ’23. As a result, any site created from an LWR template is now an enhanced LWR site by default. Unlike non-enhanced LWR sites, which use the ExperienceBundle metadata type, enhanced LWR sites use the DigitalExperienceBundle and the DigitalExperienceConfig types. However, if you created a non-enhanced LWR site on a source org such as sandbox before Winter ’24, and you now want to deploy the site for the first time to a target org such as production, this difference in metadata types can cause deployment issues.

In this case, instead of creating the site on the target org prior to deployment, we recommend using the deployment process to create the site. Otherwise, if you first create the site on the target org, the new site is an enhanced LWR site—meaning it uses the DigitalExperienceBundle and the DigitalExperienceConfig types. And because the non-enhanced LWR site on the source org uses ExperienceBundle, if you then try to deploy it to the target org, the deployment fails due to the metadata type mismatch.

However, let’s say that you created the site in the target org prior to deployment. What can you do to resolve deployment errors?

Because you can’t delete Experience Cloud sites, we instead recommend renaming the site and updating the site URL in the target org so that they no longer match the values in the source org. This approach frees up the deployment process to recreate the site in the target org using the source org’s values.

  1. In the target org, on the Settings page of the site’s Administration workspace, rename the site so that it differs from the site in the source org.
    The Settings page in the Administration workspace.
  2. From Setup, in the Quick Find box, enter Custom URLs.
  3. In Custom URLs, locate the two URLs for the site. Each site includes:
    • A Site.com Community URL that maps to the ExperienceBundle or DigitalExperienceBundle and DigitalExperienceConfig metadata types, as appropriate
    • A Community URL that maps to CustomSite
    The Custom URLs page showing the two URLs for a site.
  4. Change both site URLs to ensure that they’re no longer the same as the site URLs in the source org.
  5. After you update the site name and URL, deploy the site again either with change sets or with Metadata API using your preferred deployment tools.
  6. If you’re using Metadata API, remember to retrieve the site and include the Network and CustomSite types to allow the system to automatically create the new non-enhanced LWR site in the target org. If you’re using change sets, remember to recreate the change set before deploying.