acquia-source-canvas-pages

分类: 工具与效率 | 上传者: acquia | 下载: 0 | 版本: v1.0（最新）

通过 Source MCP 在 Acquia Source 上发布和更新远程 Canvas 页面 — 图像、道具、布局；页面 JSON 不会通过 CLI 同步到源。 --- # Acquia Source — 通过 Source MCP 的 Canvas 页面 ## 当适用时当满足以下条件时使用此技能： 1. 目标是 **Acquia Source** Drupal/Canvas 站点（请参阅 [`AGENTS.md`](../../../AGENTS.md) 中的主机名信号和 **`CANVAS_SITE_URL`**）。 2. 工作是在 **远程** 站点上的 **Canvas 页面**（创建页面、放置组件、更新布局/道具、发布），而不是仅限本地的 Workbench 预览。 ## 不要对远程页面使用 Canvas CLI **`canvas push`/`canvas pull` 目前不支持将页面 JSON 同步到远程 Acquia Source 环境或从远程 Acquia Source 环境同步。** 不要指示用户依赖该租户的 CLI 页面同步。 - **组件：**当用户要求推送组件源时，继续使用 Canvas CLI (`npx canvas push`) 和 [`canvas-component-push`](../canvas-component-push/SKILL.md) 推送 **JavaScript 组件**。 - **页面：** 在配置的服务器上使用 **源 MCP 工具**。 ## 图像和媒体（页面不进行 CLI 同步）因为 **`canvas push` / `canvas pull` 不会将页面 JSON** 同步到 Acquia 源，**存储库 `pages/*.json` 中没有任何内容会自动在远程站点上提供文件或图像道具。** 本地页面规范可能使用 HTTPS 占位符、`placehold.co` 或示例路径，以便 **Workbench** 渲染；这些价值观作为遥远的事实来源并不可靠。将图像处理视为 **仅限远程** 的关注点： ### 该怎么做 1. **发现 prop 形状** — 每个组件的 `component.yml` 定义如何对图像字段进行建模（`image`、`heroImage`、嵌套对象等）。更新服务器上的实例时保持该形状。 2. **获取 Drupal 托管的媒体** - 优先选择源站点上的资产： - **上传** - 使用源 MCP（`create_media` + 签名的上传 URL 模式等 - 读取实时工具架构）。请参阅 [`acquia-source-site-build`](../acquia-source-site-build/SKILL 中的**阶段 A5**

更新日志: Source: GitHub https://github.com/acquia/nebula

目录结构

当前层级: tree/main/.agents/skills/acquia-source-canvas-pages/

📄 SKILL.md 6.0 KB

SKILL.md

---
name: acquia-source-canvas-pages
description:
  Publishes and updates remote Canvas pages on Acquia Source via Source MCP —
  images, props, layout; page JSON does not CLI-sync to Source.
---

# Acquia Source — Canvas pages via Source MCP

## When this applies

Use this skill when **all** of the following hold:

1. The target is an **Acquia Source** Drupal/Canvas site (see hostname signal
   and **`CANVAS_SITE_URL`** in [`AGENTS.md`](../../../AGENTS.md)).
2. The work is **Canvas pages** on the **remote** site (create page, place
   components, update layout/props, publish)—not local-only Workbench preview.

## Do not use Canvas CLI for remote pages

**`canvas push` / `canvas pull` do not support syncing page JSON to/from the
remote Acquia Source environment today.** Do not instruct users to rely on CLI
page sync for that tenant.

- **Components:** Continue to use the Canvas CLI (`npx canvas push`) and
  [`canvas-component-push`](../canvas-component-push/SKILL.md) for pushing
  **JavaScript components** when the user asks to push component source.
- **Pages:** Use **Source MCP tools** on the configured server.

## Images and media (pages do not CLI-sync)

Because **`canvas push` / `canvas pull` do not sync page JSON** to Acquia
Source, **nothing in repo `pages/*.json` automatically provisions files or image
props on the remote site.** Local page specs may use HTTPS placeholders,
`placehold.co`, or example paths so **Workbench** renders; those values are not
reliable as the remote source of truth.

Treat image handling as a **remote-only** concern:

### What to do instead

1. **Discover the prop shape** — Each component’s `component.yml` defines how
   image fields are modeled (`image`, `heroImage`, nested objects, etc.). Keep
   that shape when updating instances on the server.

2. **Obtain Drupal-hosted media** — Prefer assets that live on the Source site:
   - **Upload** — Use Source MCP (`create_media` + signed upload URL pattern,
     etc.—read the live tool schema). See **Phase A5** in
     [`acquia-source-site-build`](../acquia-source-site-build/SKILL.md) for the
     end-to-end upload and **`target_id`** bookkeeping workflow.
   - **Reuse** — If media already exists, resolve ids via JSON:API, MCP entity
     tools, or admin UI and map them to the right component instances.

3. **Wire props through MCP, not through pushed JSON** — After
   `get_page_layout`, update each relevant instance with
   **`update_component_props`** so image props reference Drupal media as the
   Canvas API expects on that site (commonly media reference objects such as
   **`{ "target_id": <id> }`** inside the prop name your component
   defines—confirm against Canvas resolved output, not assumptions from local
   placeholder URLs).

4. **Verify on the remote layout** — Re-fetch layout or preview the live page
   and confirm **`resolved`** image URLs are non-null before considering the
   page ready to publish.

### Practical split

| Context                | Images                                                                                                                  |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Repo `pages/` JSON** | OK for Workbench previews (placeholders, dev URLs); document that authors must replace with MCP-driven props on Source. |
| **Acquia Source**      | Must use media that Drupal can resolve; wire via MCP after components exist on the server.                              |

If you are running the full migration pipeline, **do not publish** until every
image prop on every placed instance is wired—see the Phase A5 gate in
[`acquia-source-site-build`](../acquia-source-site-build/SKILL.md).

## MCP workflow (outline)

Always **read each tool’s schema** in the MCP filesystem before calling
`call_mcp_tool`.

1. **Discover remote components** (for `component_id` values):

   ```text
   canvas://components
   ```

   Use `ReadMcpResourceTool` / list resources per your environment’s Source MCP
   server id.

2. **Create or select a page** — `create_canvas_page`, or locate an existing
   page id via layout/list flows your server exposes (`get_page_layout`, etc.).

3. **Place and configure instances** — `add_component_to_page`,
   `add_component_to_page_region`, `update_component_props`, `move_component`,
   `remove_component`, as needed for the layout.

4. **Publish** — Use the tool that matches the goal:
   - **`publish_canvas_page`** — make a page publicly visible and commit pending
     draft changes when going live is the objective.
   - **`publish_auto_saves`** — commit pending Canvas edits (including layout)
     when the workflow uses autosave keys (see
     [`acquia-source-site-build`](../acquia-source-site-build/SKILL.md) Phase C
     for the autosave pattern).

Use **`update_canvas_page`** for metadata (title, path, description, status)
when appropriate.

For translating **local** `pagesDir` JSON into MCP calls, treat repo page files
as the structural source of truth per
[`canvas-page-definition`](../canvas-page-definition/SKILL.md); map `elements`,
slots, and props to the MCP operations above.

## Related skills

| Skill                                                                          | Role                                                      |
| ------------------------------------------------------------------------------ | --------------------------------------------------------- |
| [`canvas-page-definition`](../canvas-page-definition/SKILL.md)                 | Local page JSON contract                                  |
| [`canvas-component-push`](../canvas-component-push/SKILL.md)                   | CLI push for **components** only                          |
| [`acquia-source-navigation-menus`](../acquia-source-navigation-menus/SKILL.md) | Drupal **menus** on Source (URLs nav links should target) |
| [`acquia-source-site-build`](../acquia-source-site-build/SKILL.md)             | End-to-end pipeline including page assembly               |

登录后下载/点赞/收藏 ❤ 10 | ★ 0

acquia-source-canvas-pages

目录结构

SKILL.md

举报内容

提示