wordpress-plugin-to-emdash

将 WordPress 插件移植到 EmDash

保留插件对用户可见的行为和数据模型，不要逐行翻译 PHP。WordPress 和 EmDash 对职责的划分不同，因此首先要判断每项功能应归属站点架构、Astro 代码、沙盒化插件还是受信任的原生插件。

实现插件代码前，请先加载 creating-plugins。如果移植会改变集合、种子数据、查询或前端模板，请加载 building-emdash-site。这些技能定义了当前 API；本技能介绍迁移决策。

了解源插件

检查插件源代码、安装行为、数据库变更、钩子、REST 端点、定时任务、管理界面、短代码或区块、前端输出、权限和外部服务。将用户依赖的行为与 WordPress 特定实现区分开来。

记录：

• 必需的内容和配置数据；
• 修改或发布数据的操作；
• 授权和信任边界；
• 后台或重试行为；
• 前端和管理员交互；
• 导入、迁移和回滚需求；
• 复制的资源或代码所涉及的许可义务。

如果缺少源代码、预期行为或目标 EmDash 环境，请报告缺失之处，而不是臆造等效方案。

分配各项职责

WordPress 职责	EmDash 对应项
自定义文章类型、分类法或元数据	通过站点架构或种子数据创建的集合、分类法和字段
全站展示设置	Astro 模板读取的站点设置
插件自有用户设置	ctx.settings；将凭据声明为加密的 secret 字段
插件自有游标、缓存或内部状态	插件作用域内的 ctx.kv
插件自有可查询记录	声明的 ctx.storage.<collection> 存储
内容发现、翻译或发布	由能力控制的 ctx.content 和 ctx.schema；策略钩子和操作拥有独立权限
运行时分类法或重定向管理	具有有限读写能力的 ctx.taxonomies 或 ctx.redirects
评论管理	ctx.comments；读取会暴露个人数据，审核时使用预期状态
WordPress REST 端点	声明插件路由，并显式指定方法、输入、标头和响应模式
计划事件	cron 钩子和 ctx.cron 调度
管理页面或表单	沙盒插件使用 Block Kit；仅可信原生插件使用 React
文章编辑器元框或已保存条目操作	私有路由上的 admin.editorPanels 或 admin.editorActions
用户或作者查询	具有 users:read 权限的 ctx.users
出站 HTTP 请求	具有 network:request 权限且包含 allowedHosts 条目的 ctx.http.fetch()
媒体操作	将元数据读取、字节读取、元数据写入和上传／删除权限分开
WP_Query 或模板标签	Astro 站点代码中的 EmDash 内容 API
短代码或编辑器区块	尽可能使用现有 Portable Text 内容；自定义 Portable Text 区块需要可信原生插件
原始 head 标记或脚本	可信原生插件的 page:fragments；通过注册表安装的插件只能提供经过验证的 page:metadata

不要通过访问 EmDash 系统表来创建集合或分类法。请使用公共架构、种子数据、CLI 或管理边界。不要使用内部 REST 路由来模拟并不存在的沙盒 API。

保持权限分离：读取媒体元数据不授予读取字节的权限，审核不授予删除权限，发布策略不授予发布操作权限，内容恢复也不授予常规内容读取权限。

选择插件格式

默认使用沙箱化插件。它通过安装时的信任约定，支持可移植钩子、路由、声明式存储、媒体、网络访问、MCP 工具和 Block Kit 管理界面。

仅当功能需要访问宿主进程、React 管理代码、Astro 渲染组件、原始页面片段或自定义 Portable Text 区块定义时，才使用受信任的原生插件。在迁移计划中说明额外权限和分发限制。

有些 WordPress 插件不需要 EmDash 插件。自定义文章类型加前端模板，可能只需转换为架构、种子数据和 Astro 页面。如果静态站点结构足以实现相关行为，就不要添加运行时扩展。

规划数据迁移

编写运行时代码前，先说明现有 WordPress 数据的映射方式：

• 映射文章 ID、别名、语言区域、作者、状态、修订版本和发布日期；
• 保留文章、分类项、媒体和插件自有记录之间的关系；
• 区分一次性导入与需要持续同步的数据；
• 确保导入可重新启动，并定义重复项的检测方式；
• 在需要用于数据协调或重定向时保留源标识符；
• 确定哪些内容无法表示，除非先做出产品决策。

新站点的初始架构和示例内容使用种子数据。现有站点的生产数据则使用导入器或迁移路径；种子既不是备份，也不是持续同步机制。

验证等效行为

通过用户和运行时实际使用的边界进行测试：

• 针对内容模型变更，断言架构和导入的数据；
• 针对沙箱钩子、路由、存储和权限，进行生产边界插件测试；
• 通过浏览器验证管理界面和前端操作流程；
• 如果源功能依赖相关行为，则测试重启、重复投递、授权和故障场景。

比较可观察到的行为，而非内部结构。记录有意做出的差异，以及仍不受支持的 WordPress 功能。

交付迁移成果

提供：

1. 对 WordPress 行为和数据的简明清单；
2. 职责映射以及沙箱化或原生插件的选择；
3. 数据迁移或种子数据计划；
4. 插件和站点代码中的实现；
5. 验证证据和已知缺口；
6. 复用代码或素材的署名和许可声明。