Pushing Lightning Component Metadata Between Experiences

b2b-commerceexperience-cloudlightning-aura-componentslightning-communitylightning-web-components

We are using Experience Cloud with B2B Commerce and are intending on going live very soon. Our marketing department will be handling metadata changes in our components (eg. we have a banner LWC which takes inputs for the text to display, and marketing will make changes to that text), and we're looking for how to sync that between our dev, preproduction and production orgs.

We attempted to retrieve and deploy metadata this way by pulling from our development org and deploying into preproduction, but it created a bit of a mess where the Experience wasn't displaying correctly, was missing our site's custom CSS and so forth even though all indications pointed to it deploying everything without issue.

I notice that in that metadata the components have IDs which on inspection did not match between the two sites (we pulled down the metadata for the sites on both orgs and compared the two prior to the push). Some IDs matched, others did not – is this indicative of a discrepancy between the component version (the component on dev has stuff added to it that hasn't been pushed to preprod yet), or are these site-specific IDs?

All this to say, is there any way we can handle these metadata syncs, and does pushing programmatic changes to a component wipe out the metadata that marketing enters in production?

Best Answer

I have returned with answers! Thank you for any patience and assistance provided. I managed to get everything pushed over via change sets so that the Experiences were on equal footing, pulled down the ExperienceBundles for each, then went from there.

First: Why didn't the IDs of the components match? Answer: This is because they, at the time, were pushed DIRECTLY into the target org from VSCode and NOT through a change set. If your components are pushed through a change set, then the IDs WILL match regardless of any programmatic changes you make to it. This completely alleviated the confusion where all the documentation said that if the source Experience doesn't have a component whose ID is specified, it will be added to the page on the target.

Next: Pushing a component through with a parameter defined in the designer (the metadata) from the source org does not appear overwrite the metadata in the corresponding component in the target org.

Last: what happened to the CSS? No clue there still, but once everything was evened-out, a push of the source org's ExperienceBundle into the target org caused no issues on that front, and I confirmed the overrides were still there. We may have just been so out of sync at that point. If I ever find out the circumstances of this issue, I'll be sure to report back.

Now that we're at a stable position, we know how to go forward. We will checkin pulled-down ExperienceBundle data into source control, and we will likely do a combination of pushing up the ExperienceBundle info from VSCode and using our source control software to manually look over the differences.

Related Topic