You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/merchants/quick-start/content-model.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,20 +18,20 @@ Splitting styling from content this way keeps site design consistent.
18
18
19
19
## How the roles work together
20
20
21
-
A layout option must exist before a Content Author can pick it. But that doesn't mean the two roles always work one after the other. A Page Designer can build new layout options directly in the storefront's code while a Content Author picks from options that already exist and builds pages without touching code.
21
+
A layout option must exist before a Content Author can pick it. However, the two roles do not always work sequentially. A Page Designer can build new layout options directly in the storefront's code while a Content Author picks from options that already exist and builds pages without modifying code.
22
22
23
23
A hero banner, for example, might offer a two-column layout and a full-width layout, each built and tested ahead of time.
24
24
25
25
{/* TODO: replace with a concrete, publishable example of a variation set (for example, a hero banner). Pending: access to genericized OPTP/eLuscious walkthroughs (blocked on clearance for public use), or an example built from this boilerplate's own blocks/section metadata instead. */}
26
26
27
-
When a Content Author needs a layout option that doesn't exist yet, or an entirely new kind of block, the request goes to the Page Designer. If that need is a new drop-in, live catalog data, or a change to existing behavior, it becomes a developer task instead — the drop-in work outside a Page Designer's scope. See [Author and developer tasks](/merchants/blocks/author-and-developer-tasks/) for how to file that request.
27
+
When a Content Author needs a layout option that doesn't exist yet, or an entirely new kind of block, the request goes to the Page Designer. If that need is a new drop-in, live catalog data, or a change to existing behavior, it becomes a developer task outside the Page Designer's scope. See [Author and developer tasks](/merchants/blocks/author-and-developer-tasks/) for how to file that request.
28
28
29
29
## Templates for content pages
30
30
31
-
Page Designers create templates for common content pages, such as a landing page or a category page, so Content Authors can start from the right baseline instead of an empty page. A Content Author selects the template that most closely matches their needs and builds from there.
31
+
Page Designers create templates for common content pages, such as a landing page or a category page, so Content Authors can start from the right baseline instead of starting from an empty page. A Content Author selects the template that most closely matches their needs and builds from there.
32
32
33
33
## Reference implementations
34
34
35
35
Reference implementations for this page are coming soon.
36
36
37
-
{/* TODO: add reference implementation examples built from this boilerplate's own blocks and section metadata. OPTP/eLuscious access was declined for public use (Oleg Posyniak, Slack, 2026-08); this page stays in the Commerce storefront docs, not Experience League, per the same thread. */}
37
+
{/* TODO: add reference implementation examples built from this boilerplate's own blocks and section metadata. Access was restricted for public use (Oleg Posyniak, Slack, 2026-08); this page stays in the Commerce storefront docs, not Adobe Experience League, per the same thread. */}
0 commit comments