@W-21817314@ Improved lwr and ui bundle site's skill to identify what properties should be updated for when user request for site URL update (#157)

* @W-21817314@ Improved lwr and ui bundle site's skill to identify what properties should be updated for when user request for site URL update

Signed-off-by: Daily Dai <lei.dai@salesforce.com>

* fix skill name

Signed-off-by: Daily Dai <lei.dai@salesforce.com>

* fix skill name

Signed-off-by: Daily Dai <lei.dai@salesforce.com>

* move url update into its own doc md file

Signed-off-by: Daily Dai <lei.dai@salesforce.com>

* clarify search_files is an agent tool instead of command line

Signed-off-by: Daily Dai <lei.dai@salesforce.com>

---------

Signed-off-by: Daily Dai <lei.dai@salesforce.com>
This commit is contained in:
lei-dai-sfdc 2026-04-01 20:28:57 -07:00 committed by GitHub
parent 8dc6e7d04d
commit 7d9fc28b4e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 224 additions and 2 deletions

View File

@ -102,6 +102,7 @@ Before doing anything, you **MUST ALWAYS** load them first if they match user in
- [handle-component-and-region-ids.md](docs/handle-component-and-region-ids.md) - **UUID generation (CRITICAL)** for component and region ids used in views and themeLayout. - [handle-component-and-region-ids.md](docs/handle-component-and-region-ids.md) - **UUID generation (CRITICAL)** for component and region ids used in views and themeLayout.
- [handle-ui-components.md](docs/handle-ui-components.md) - Component discovery, schemas, insertion, configuration - [handle-ui-components.md](docs/handle-ui-components.md) - Component discovery, schemas, insertion, configuration
- [configure-guest-sharing-rules.md](docs/configure-guest-sharing-rules.md) - **Guest sharing rules** (`sharingGuestRules`) for public sites — use for any request involving "guest sharing rule", "Site Guest User", or sharing object records with unauthenticated visitors - [configure-guest-sharing-rules.md](docs/configure-guest-sharing-rules.md) - **Guest sharing rules** (`sharingGuestRules`) for public sites — use for any request involving "guest sharing rule", "Site Guest User", or sharing object records with unauthenticated visitors
- [update-site-urls.md](docs/update-site-urls.md) - **Updating site URLs** - URL architecture, workflow for updating `urlPathPrefix` in DigitalExperienceConfig, Network, and CustomSite
## Common Workflows ## Common Workflows
@ -211,6 +212,15 @@ The site developer name can be found in the CustomSite filename (e.g., `sites/My
If the site is not found, an error message will be returned indicating that the site may not be deployed. Ensure the site has been successfully deployed before calling this action. If the site is not found, an error message will be returned indicating that the site may not be deployed. Ensure the site has been successfully deployed before calling this action.
### Updating Experience Site URLs
**Use when** user wants to update or change site URLs (urlPathPrefix).
**Steps** (Follow the steps sequentially. Do not skip any step before proceeding):
- [ ] MUST read [update-site-urls.md](docs/update-site-urls.md) to understand the three-component architecture and URL update workflow
- [ ] Follow the step-by-step workflow in the doc to update URLs consistently across all three components (DigitalExperienceConfig, Network, CustomSite)
### Validation & Deployment ### Validation & Deployment
Use `sf` CLI to validate and deploy. Access help docs by attaching `--help`, e.g.: Use `sf` CLI to validate and deploy. Access help docs by attaching `--help`, e.g.:
@ -230,4 +240,4 @@ sf project deploy validate --metadata DigitalExperienceBundle DigitalExperience
```bash ```bash
sf project deploy start --metadata DigitalExperienceBundle DigitalExperience DigitalExperienceConfig Network CustomSite --target-org ${usernameOrAlias} sf project deploy start --metadata DigitalExperienceBundle DigitalExperience DigitalExperienceConfig Network CustomSite --target-org ${usernameOrAlias}
``` ```

View File

@ -0,0 +1,100 @@
# Updating Experience Site URLs
Experience sites have a three-component architecture with two distinct URL patterns. Understanding this structure is critical when updating site URLs.
## Architecture Overview
Every Salesforce Experience Site consists of three components:
1. **Network** (metadata: `Network`) - Network configuration
2. **ChatterNetwork Site** (metadata: `CustomSite`) - Authentication endpoints and core site services
3. **ChatterNetworkPicasso Site** (metadata: `DigitalExperienceConfig` + `DigitalExperienceBundle`) - Customer-facing pages and content
## URL Pattern
These three components use **two different URLs**:
- **Primary URL** (ChatterNetworkPicasso): Used for customer-facing pages
- Defined in: `DigitalExperienceConfig``<urlPathPrefix>`
- Example: `mysite`
- **Secondary URL** (Network + CustomSite): Used for authentication endpoints and other services
- Defined in: `Network``<urlPathPrefix>` AND `CustomSite``<urlPathPrefix>`
- Example: `mysitevforcesite`
- **Must be synchronized** - both files must have identical values
By default, Salesforce differentiates these URLs by appending `vforcesite` suffix to the Network/CustomSite URL.
## URL Update Workflow
When updating site URLs, follow this workflow:
### Step 1: Discover All URL References
Search for all occurrences of `urlPathPrefix` across the project metadata files.
**For agents**: Use the `search_files` tool with these parameters:
- path: `force-app/main/default`
- regex: `urlPathPrefix`
- file_pattern: `*.xml`
**For humans**: Use your IDE's search functionality or command line tools:
```bash
# Using grep
grep -r "urlPathPrefix" force-app/main/default --include="*.xml"
# Using VS Code: Ctrl+Shift+F (Windows/Linux) or Cmd+Shift+F (Mac)
# Search for: urlPathPrefix
# Files to include: *.xml
```
### Step 2: Identify URL Groups
Determine which files belong to which URL group:
- **Primary URL Group**: `DigitalExperienceConfig`
- **Secondary URL Group**: `Network` AND `CustomSite`
### Step 3: Update URLs Consistently
Update the `<urlPathPrefix>` value in each file:
- **DigitalExperienceConfig**: Update to new primary URL
- **Network**: Update to new secondary URL (typically primary URL + `vforcesite`)
- **CustomSite**: Update to **same value as Network** (must be synchronized)
### Step 4: Validate Naming Convention
Ensure URL values follow best practices:
- Use lowercase letters only
- Avoid special characters except hyphens where appropriate
- Keep URLs concise and meaningful
### Step 5: Verify Consistency
Before deploying, confirm:
- [ ] Primary URL in `DigitalExperienceConfig` is set correctly
- [ ] Secondary URL in `Network` matches `CustomSite` exactly
- [ ] URLs are properly differentiated (typically via suffix)
- [ ] All URL values follow naming conventions
## Example URL Configuration
```
ChatterNetworkPicasso Site (Primary):
DigitalExperienceConfig: <urlPathPrefix>bestsupport</urlPathPrefix>
Network + ChatterNetwork Site (Secondary):
Network: <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
CustomSite: <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
```
## Common Pitfalls to Avoid
**Don't** update only one or two files - all three must be updated
**Don't** use different values in Network and CustomSite
**Don't** use the same URL for both Primary and Secondary groups
**Don't** skip the discovery step with `search_files`
**Do** use `search_files` to find all occurrences first
**Do** maintain URL differentiation between the two groups
**Do** follow lowercase naming conventions

View File

@ -51,6 +51,8 @@ Use the default templates in the docs below. Values in `{braces}` are resolved p
| DigitalExperienceBundle | [configure-metadata-digital-experience-bundle.md](docs/configure-metadata-digital-experience-bundle.md) | | DigitalExperienceBundle | [configure-metadata-digital-experience-bundle.md](docs/configure-metadata-digital-experience-bundle.md) |
| DigitalExperience (sfdc_cms__site) | [configure-metadata-digital-experience.md](docs/configure-metadata-digital-experience.md) | | DigitalExperience (sfdc_cms__site) | [configure-metadata-digital-experience.md](docs/configure-metadata-digital-experience.md) |
For URL updates, see [update-site-urls.md](docs/update-site-urls.md).
### Execution Note for Step 3: Load and use the docs ### Execution Note for Step 3: Load and use the docs
- Agents MUST read the full contents of each docs/*.md file referenced in Step 3 before attempting to populate metadata fields. - Agents MUST read the full contents of each docs/*.md file referenced in Step 3 before attempting to populate metadata fields.
- Use your platform's file-read tool (for example, `read_file`) to load these files in full, then perform placeholder substitution for values in `{braces}` using the resolved properties from Step 1. - Use your platform's file-read tool (for example, `read_file`) to load these files in full, then perform placeholder substitution for values in `{braces}` using the resolved properties from Step 1.
@ -63,7 +65,7 @@ Use the default templates in the docs below. Values in `{braces}` are resolved p
- Read entire file contents, replace placeholders (e.g. `{siteName}`) with the resolved values, then use the expanded templates to populate the metadata XML/JSON content. - Read entire file contents, replace placeholders (e.g. `{siteName}`) with the resolved values, then use the expanded templates to populate the metadata XML/JSON content.
### Step 4: Resolve Additional Configurations ### Step 4: Resolve Additional Configurations
Address any extra configurations the user requests. Use the metadata sections and field context identified in Step 2 to understand each fields purpose and constraints, then update only the minimum necessary fields. Address any extra configurations the user requests. Use the metadata sections and field context identified in Step 2 to understand each field's purpose and constraints, then update only the minimum necessary fields.
## Verification Checklist ## Verification Checklist
Before deploying, confirm: Before deploying, confirm:
@ -76,3 +78,13 @@ Before deploying, confirm:
```bash ```bash
sf project deploy validate --metadata Network CustomSite DigitalExperienceConfig DigitalExperienceBundle DigitalExperience --target-org ${usernameOrAlias} sf project deploy validate --metadata Network CustomSite DigitalExperienceConfig DigitalExperienceBundle DigitalExperience --target-org ${usernameOrAlias}
``` ```
## Common Workflows
### Updating Experience Site URLs
**Use when** user wants to update or change site URLs (urlPathPrefix).
**Steps**:
- [ ] Read [update-site-urls.md](docs/update-site-urls.md) to understand the three-component architecture and URL update workflow
- [ ] Follow the step-by-step workflow in the doc to update URLs consistently across all three components (DigitalExperienceConfig, Network, CustomSite)

View File

@ -0,0 +1,100 @@
# Updating Experience Site URLs
Experience sites have a three-component architecture with two distinct URL patterns. Understanding this structure is critical when updating site URLs.
## Architecture Overview
Every Salesforce Experience Site consists of three components:
1. **Network** (metadata: `Network`) - Network configuration
2. **ChatterNetwork Site** (metadata: `CustomSite`) - Legacy site and proxy core site services
3. **ChatterNetworkPicasso Site** (metadata: `DigitalExperienceConfig` + `DigitalExperienceBundle`) - Customer-facing pages and content
## URL Pattern
These three components use **two different URLs**:
- **Primary URL** (ChatterNetworkPicasso): Used for customer-facing pages
- Defined in: `DigitalExperienceConfig``<urlPathPrefix>`
- Example: `mysite`
- **Secondary URL** (Network + CustomSite): Used for legacy authentication endpoints and other services
- Defined in: `Network``<urlPathPrefix>` AND `CustomSite``<urlPathPrefix>`
- Example: `mysitevforcesite`
- **Must be synchronized** - both files must have identical values
By default, Salesforce differentiates these URLs by appending `vforcesite` suffix to the Network/CustomSite URL.
## URL Update Workflow
When updating site URLs, follow this workflow:
### Step 1: Discover All URL References
Search for all occurrences of `urlPathPrefix` across the project metadata files.
**For agents**: Use the `search_files` tool with these parameters:
- path: `force-app/main/default`
- regex: `urlPathPrefix`
- file_pattern: `*.xml`
**For humans**: Use your IDE's search functionality or command line tools:
```bash
# Using grep
grep -r "urlPathPrefix" force-app/main/default --include="*.xml"
# Using VS Code: Ctrl+Shift+F (Windows/Linux) or Cmd+Shift+F (Mac)
# Search for: urlPathPrefix
# Files to include: *.xml
```
### Step 2: Identify URL Groups
Determine which files belong to which URL group:
- **Primary URL Group**: `DigitalExperienceConfig`
- **Secondary URL Group**: `Network` AND `CustomSite`
### Step 3: Update URLs Consistently
Update the `<urlPathPrefix>` value in each file:
- **DigitalExperienceConfig**: Update to new primary URL
- **Network**: Update to new secondary URL (typically primary URL + `vforcesite`)
- **CustomSite**: Update to **same value as Network** (must be synchronized)
### Step 4: Validate Naming Convention
Ensure URL values follow best practices:
- Use lowercase letters only
- Avoid special characters except hyphens where appropriate
- Keep URLs concise and meaningful
### Step 5: Verify Consistency
Before deploying, confirm:
- [ ] Primary URL in `DigitalExperienceConfig` is set correctly
- [ ] Secondary URL in `Network` matches `CustomSite` exactly
- [ ] URLs are properly differentiated (typically via suffix)
- [ ] All URL values follow naming conventions
## Example URL Configuration
```
ChatterNetworkPicasso Site (Primary):
DigitalExperienceConfig: <urlPathPrefix>bestsupport</urlPathPrefix>
Network + ChatterNetwork Site (Secondary):
Network: <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
CustomSite: <urlPathPrefix>bestsupportvforcesite</urlPathPrefix>
```
## Common Pitfalls to Avoid
**Don't** update only one or two files - all three must be updated
**Don't** use different values in Network and CustomSite
**Don't** use the same URL for both Primary and Secondary groups
**Don't** skip the discovery step with `search_files`
**Do** use `search_files` to find all occurrences first
**Do** maintain URL differentiation between the two groups
**Do** follow lowercase naming conventions