@W-22849705 feat(content): support Page Designer content blocks (fragments) - #500
Open
clavery wants to merge 5 commits into
Open
@W-22849705 feat(content): support Page Designer content blocks (fragments)#500clavery wants to merge 5 commits into
clavery wants to merge 5 commits into
Conversation
…ments)
Content blocks are reusable, shared `fragment.*`-typed Page Designer content.
Previously the SDK bucketed them as components, so they were invisible as a
distinct, shared concept across the SDK, CLI, and VS Code extension.
SDK (@salesforce/b2c-tooling-sdk):
- Add `FRAGMENT` to `LibraryNodeType`; classify `fragment.*` content as FRAGMENT
- Parse and expose `LibraryNode.displayName` (content blocks always have one)
- Add `Library.getContentBlocks()`: deduplicated catalog of a library's blocks,
including unlinked ones (scans full content set, not just the linked tree)
- Render blocks distinctly in `getTreeString` ("(CONTENT BLOCK: <typeId>)", magenta)
- Promote and count fragments in `exportContent` (new `fragmentCount`)
CLI (@salesforce/b2c-cli):
- `content export`/`list` render blocks distinctly and count them separately
- `content list --type fragment` lists the dedup catalog via getContentBlocks
VS Code extension (b2c-vs-extension):
- Per-library "Content Blocks" group is the single source of truth for a block
(full child subtree). Because blocks are shared singletons, every page/component
that links a block shows a non-expanding reference (↗) that reveals the canonical
block in the group — so a block is only ever edited in one place
- Right-click "Convert to Content Block" rewrites a component's <type> to
fragment.* + adds a display-name and re-imports the element
- Extract reusable importLibraryXML helper; remove leftover debug temp-file write
Verified end-to-end against the zzpq-023 MarketStreet site library (leaf, Layout,
shared, nested, and unlinked content blocks). The bundled library.xsd is
byte-identical to the instance's 26.6 schema (fragment.* already validates), so no
schema change was needed.
…te+recreate+relink The initial convert prototype rewrote an element's <type> and re-imported it, but live testing against instances proved a site-archive MERGE import silently ignores <type> changes on an existing content element (verified by importing a real fragment from one instance into another — the element stayed a component). Empirically characterized the platform's actual contract (zzpq-019/013/023): - IMPEX can CREATE a net-new fragment element fine. - IMPEX merge will NOT change an existing element's type. - `mode="delete"` on a content element DEEP-deletes its whole subtree AND strips every incoming content-link. - So a faithful in-place conversion (matching Page Designer's "Convert to Content Block") requires, in ONE archive: delete the target, recreate it as fragment.*, recreate all descendants (cascade-deleted), and re-import every referrer so incoming content-links survive. Implements that as `Library.buildContentBlockConversionXML(contentId, displayName)`: - delete marker + recreated fragment (display-name first for XSD order; own region content-link types flipped component.<base>.<region> -> fragment.<base>.<region>) - all descendants recreated; all referrers re-imported The extension convert command now builds this archive via the SDK and imports it. Verified end-to-end: the SDK-built archive imported into zzpq-013 produces an element BYTE-IDENTICAL to a manual BM/PD conversion, with the parent's content-link preserved. Added SDK tests (archive structure: delete/recreate/ descendants/referrers, region-link rename) including xmllint validation against the bundled library.xsd.
… plain merge import Re-tested the platform on the same instances (zzpq-019 fragment / zzpq-013 component, neither the default): a plain site-archive MERGE import of a re-typed element now applies the component.* -> fragment.* change IN PLACE and preserves incoming content-links. This is the behavior that was broken when the feature was built; it has since been fixed on the platform. Verified live: merging just the convertToFragment()-transformed element into zzpq-013 flips the type (byte-identical to the manual conversion on zzpq-019) with the parent carousel's content-link intact. (Also observed the merge is one-way: it promotes component->fragment but won't demote fragment->component.) The delete+recreate+recreate-descendants+re-import-referrers machinery built to work around the old immutability is therefore no longer needed — and was heavier and riskier (deep-deletes subtrees). Removed it: - SDK: drop Library.buildContentBlockConversionXML() and the childLinkIds helper; keep LibraryNode.convertToFragment() (type rewrite + display-name in schema order + own region-link type flip). - Extension: convertToBlock now calls convertToFragment() + generateContentXML() + a normal importLibraryXML() merge (the same single-element import path used elsewhere). - Tests: drop the conversion-archive suite; convertToFragment tests (incl. xmllint schema validation) remain.
# Conflicts: # packages/b2c-vs-extension/src/content-tree/content-fs-provider.ts
Contributor
📘 Docs previewYour documentation changes are published at: https://d3uhw92m2zac57.cloudfront.net/pr-500/ Commit This preview updates on every push and is removed when the PR is closed. |
…ps region links Re-tested convert on a Layout grid WITH children (zzpq-019 MarketStreet-SharedLibrary). The simple single-element merge — which I switched to in d20c0ad after finding the platform now applies component.*->fragment.* type changes in a merge — turns out to DROP the converted element's own region content-links. A converted grid loses its column_N links and its children are orphaned (they still exist, but the block no longer references them). Reproduced by importing an XSD-valid archive that DID include the flipped fragment.Layout.grid.column_N links; the platform discarded them on the in-place type change. Delete+recreate preserves the region links (verified live: the grid re-exports as fragment.Layout.grid with both column links intact and children attached). So the machinery removed in d20c0ad is required after all — this reverts that simplification and restores Library.buildContentBlockConversionXML() + the extension wiring + tests. Updated the rationale in comments/docstrings: the reason delete+recreate is needed is region-link preservation (merge drops them), not type immutability (merge now handles the type change). This reverts commit d20c0ad.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds first-class support for Page Designer content blocks — reusable, shared
fragment.*-typed content — across the SDK, CLI, and VS Code extension. Previously the SDK bucketed these as components, so they were invisible as a distinct, shared concept.This work item was a title-only stub ("Support 'Content Blocks' in Content Topic and Page Designer tree views"); the data model was established by exploring a live instance (
zzpq-023MarketStreet site library).What a content block is (verified against the instance)
<content>element typedfragment.*(e.g.fragment.Content.contentCard,fragment.Layout.grid) with a<display-name>.<content-link>s. The same block — and its identical children — appears everywhere it's linked; there is no per-placement override.component.*(converting a block does not convert its children). Blocks can nest inside other blocks.<type>fromcomponent.*tofragment.*and adds a<display-name>on the same content object — same content-id, no link rewiring.library.xsd(26.6) is byte-identical to the bundled copy andfragment.*already validates.Changes
SDK (
@salesforce/b2c-tooling-sdk)FRAGMENTtoLibraryNodeType; classifyfragment.*content asFRAGMENT.LibraryNode.displayName.Library.getContentBlocks()— a deduplicated catalog of a library's blocks, including unlinked ones (scans the full content set, not just the linked tree).getTreeString((CONTENT BLOCK: <typeId>), magenta); promote and count fragments inexportContent(newfragmentCount).CLI (
@salesforce/b2c-cli)content export/content listrender blocks distinctly and count them separately.content list --type fragmentlists the deduplicated catalog.VS Code extension (
b2c-vs-extension)<type>+ adds display-name, re-imports the element).importLibraryXMLhelper; remove a leftover debug temp-file write incontent-fs-provider.ts.Docs/skills — updated the CLI content reference, the VS Code extension overview, and the
b2c-contentskill.Notes
siteArchiveImportpath, but could not be exercised in the Extension Dev Host headlessly — confirm the tree rendering and convert round-trip interactively before release.convertToBlockis a prototype write-action; it mirrors the platform's observed mutation.