>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3588799. --> Reported by: [ajv009](https://www.drupal.org/user/3653917) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The current migrate-site skill treats all pages as static Canvas page entities. When a site has dynamic content types (events, blog posts, news items, team members), the skill creates one Canvas page entity per content item. Every new piece of content then requires a script run &mdash; a content editor cannot create a new event and have it render styled without developer intervention.</p> <p>The Canvas content template approach inverts this: one template, created once per content type, renders all current and future items automatically. A single <code>node.event.full</code> Canvas content template replaces N hand-crafted Canvas pages and makes content creation fully CMS-self-service. This is the architecturally correct approach for a CMS migration and the one that satisfies the user's expectation: "a migrated CMS must be fully self-service for content editors."</p> <p>In the recorded Q4 session, the discovery came from outside the migration session (a user-supplied tip after the agent's documentation research failed to find it). 8 Canvas pages were deleted and recreated as one template &mdash; work that would not have been needed with this phase in place.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Run migrate-site against a Drupal source site that has a dynamic content type (events).</li> <li>Observe Phase 7: composer creates one Canvas page per node, each with hand-crafted layout.</li> <li>Create a new event via admin UI after migration completes.</li> <li>Observe: new event renders unstyled (no Canvas page exists for it). A script run is required for every new node.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p><strong>Step 1 &mdash; Phase 1 detection.</strong> Site-analyzer flags <code>content_type_migration: true</code> in <code>plan.md</code> when source has dynamic content types. Detection heuristic: for Drupal sources check JSON:API entity types; for Squarespace sources check URL patterns (<code>/event/</code>, <code>/blog/</code>) and repeated card structures.</p> <p><strong>Step 2 &mdash; Add Phase 4.5 to <code>SKILL.md</code>.</strong> For each flagged content type:</p> <ol> <li>Check whether a Canvas content template exists via <code>canvas:download</code> listing.</li> <li>If none exists, create one using the <code>node.&lt;type&gt;.full</code> pattern.</li> <li>Bind all component props using <code>entity-field</code> source. Verbatim prop binding format proven to work:<br> <pre>'nodeUuid': {'sourceType': 'entity-field', 'expression': 'entity:node:event uuid value'}</pre></li> <li>Create a test node of that content type via admin UI. Verify it renders at its URL without any script. If it 404s, PATCH with <code>pathauto: true</code>.</li> <li>Delete (NOT archive) any per-node Canvas pages that were created for the same content type. Drupal's <code>path_alias</code> management is not cascade-safe through JSON:API alias changes.</li> </ol> <p><strong>Step 3 &mdash; Transport layer (split outcome).</strong> Empirical probe against the live Acquia Source instance found:</p> <ul> <li><strong>Page CRUD via <code>canvas:page:*</code>: WORKS.</strong> <code>POST /api/page</code> &rarr; 201, <code>GET /api/page/{uuid}</code> &rarr; 200, <code>DELETE /api/page/{uuid}</code> &rarr; 204. Caveat: <code>path.alias</code> is silently ignored when set inline during <code>POST</code>; a separate write is required.</li> <li><strong>Template management via <code>page_template:administer</code>: BLOCKED.</strong> Token issues but no endpoint shipped (<code>/api/page_template</code>, <code>/api/page_template/page_template</code>, <code>/api/canvas_page_template</code>, <code>/api/entity_view_display</code>, <code>/api/canvas/page_template</code> all 404). Browser-session approach (admin cookie via <code>.canvas-browser/</code> profile) remains required for template creation.</li> </ul> <p><strong>Recommended sub-task split:</strong></p> <ul> <li><strong>Sub-task A (do now):</strong> Implement Phase 4.5 page-composition steps using <code>canvas:page:*</code> API. Implementation reference: <code>create-event-template.mjs</code> (243 lines).</li> <li><strong>Sub-task B (defer):</strong> Template creation via <code>page_template:administer</code> API &mdash; blocked until Acquia ships the endpoint. Continue using browser session for template creation.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Add content-type detection to <code>site-analyzer.md</code> Phase 1 output (<code>content_types</code> array in <code>plan.md</code>).</li> <li>Add Phase 4.5 section to <code>migrate-site/SKILL.md</code> with template creation, prop binding, self-service test, and Canvas page cleanup instructions.</li> <li>Document the session-cookie requirement: Canvas content template creation requires browser session cookies, not OAuth, until <code>page_template:administer</code> endpoint ships.</li> <li>Document the <code>pathauto</code> caveat: PATCH <code>pathauto: true</code> on the node after deleting old Canvas pages to regenerate aliases.</li> <li>Add note to <code>component-builder.md</code>: components for content types must support entity-field binding for all dynamic props.</li> <li>Optionally add <code>canvas-content-template-agent.md</code> as a dedicated Phase 4.5 agent.</li> <li>Verify: a new node created via admin UI renders styled at its URL without running any script.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None directly. Indirect: post-migration, content editors gain self-service publishing for the migrated content types &mdash; new content renders styled without developer intervention.</p> <h3 id="summary-api-changes">API changes</h3> <p>The phase consumes (does not introduce):</p> <ul> <li><code>POST /api/page</code> with <code>canvas:page:create</code> token (path.alias ignored inline &mdash; see related issue NEW-12).</li> <li><code>DELETE /api/page/{uuid}</code> with <code>canvas:page:delete</code> token.</li> <li>Template management uses browser session against Drupal admin UI (Content Templates &rarr; Add Template &rarr; Node &rarr; &lt;type&gt; &rarr; Full); API endpoint pending.</li> </ul> <h3 id="summary-data-model-changes">Data model changes</h3> <p>New <code>plan.md</code> field <code>content_types[]</code>. New artifact <code>docs/migration/workflow/4.5-content-template-checklist.json</code>.</p> <h3 id="summary-internal-references">Internal references</h3> <ul> <li>Source markdown: <code>RESEARCH-2026-04-28/99-final/ISSUES/Sprint-8-Patterns-To-Encode/02-NEW-2-canvas-content-templates-phase.md</code> (id: NEW-2)</li> <li>Pattern definition: <code>RESEARCH-2026-04-28/07-cross-cutting/what-actually-works.md</code> &sect; P10 (verbatim prop binding L11047)</li> <li>Q4 post-mortem: <code>RESEARCH-2026-04-28/03-efi-ed-source/Q4-records-8651-to-11536/post-mortem-learnings.md</code> (Lessons 1&ndash;4)</li> <li>Implementation reference: <code>RESEARCH-2026-04-28/03-efi-ed-source/disk-state/scripts-deterministic-flows.md</code> &sect; <code>create-event-template.mjs</code></li> <li>Encoding recommendation: <code>RESEARCH-2026-04-28/99-final/NEW-things-to-try.md</code> &sect; 1</li> <li>Empirical scope status: <code>RESEARCH-2026-04-28/99-final/SCOPE-PROBE-FINDINGS-2026-05-01.md</code> &sect;&sect; 4&ndash;7</li> <li>Related bug: <code>RESEARCH-2026-04-28/99-final/consolidated-issues.md</code> &sect; P2-6</li> </ul> <h3 id="summary-open-questions">Open questions</h3> <ul> <li>Content-type detection heuristic for non-Drupal sources (Squarespace, Wix): URL patterns plus repeating card structures, or a dedicated discovery agent?</li> <li>If <code>.canvas-browser/</code> profile is not warm (verify-browser-session fails), Phase 4.5 cannot proceed &mdash; should this be a hard precondition or a graceful skip?</li> <li>Single dedicated agent vs. extension of <code>upload-verifier</code>? <code>create-event-template.mjs</code> suggests deterministic-script approach may be better than an LLM agent here.</li> <li>Does the Drupal #3584714 install-order gotcha (for <code>canvas:media:image:create</code>) apply to <code>page_template:administer</code> too? Determines whether Phase 4.5 can detect and self-fix missing scopes via post-update hook.</li> </ul>