前言

近期，我着手开发一款专为酒店管理与数字化运营专业教学场景定制的 WordPress Markdown 编辑器插件。过程中，从环境配置、依赖管理、权限处理到功能增强，踩过不少“坑”，也积累了许多宝贵经验。本文以技术日志形式，系统梳理整个开发流程，既为团队留下可复用的知识资产，也希望能为同行提供一份实用参考。

一、缘起：为何要自研 Markdown 编辑器？

📌 技术选型原则：

• 前端：EasyMDE（轻量、可定制）

• 后端：纯 WordPress REST API，零额外依赖

• 构建：TypeScript + Webpack（但最终分发包不含构建工具）

二、开发环境搭建与权限陷阱

服务器文件权限“迷局”

❌ 问题：/wp-content/plugins/ 下文件无法删除（权限不足）

• 根因：文件由 Web 服务器用户（www-data）创建，而我的 SSH 用户（ubuntu）非所有者。

• 解决方案：

🔒 安全提醒：777 仅用于临时操作，完成后恢复 755/644。

三、插件打包与依赖管理实战

3.1 打包：确保 ZIP 结构合规

3.2 依赖安装：Composer 的国内加速方案

❌ 问题：composer install 卡死超 5 分钟

• 诊断：ps aux | grep composer 显示进程存在但无网络活动 → 国外源访问超时。

• 终极解法：配置阿里云镜像！ 执行后，依赖安装从“10 分钟无响应”变为 30 秒完成。

💡 插件分发建议：

若插件无需复杂 PHP 依赖（如仅前端功能），直接删除 composer.json，避免用户安装门槛。

四、关键功能实现：剪贴板图片自动上传

4.1 技术方案

• 前端：监听 EasyMDE 的 paste 事件，提取剪贴板图片 Blob；

• 后端：调用 WordPress REST API /wp/v2/media 上传；

• 认证：通过 wp_localize_script 注入 nonce，利用用户已登录状态。

4.2 核心代码片段

4.3 复杂度评估

✅ 结论：功能价值高，实现成本可控，强烈推荐集成。

五、GitHub 协作避坑指南

❌ 问题：error: src refspec main does not match any

• 原因：本地无任何提交，故无 main 分支。

• 修复流程：

⚠️ 血泪教训：

• GitHub 新建仓库时不要勾选 “Add README”，避免初始提交冲突；

• 若 URL 有空格（如复制时误带），用 git remote set-url 重置。

六、插件发布前的精简清单

结语：开发的核心逻辑

• 简化操作：剪贴板粘贴图片 → 降低技术门槛；

• 专注场景：移除冗余功能 → 聚焦酒店实训需求；

• 自主可控：自研插件 → 避免商业工具限制。

不必追求大而全，解决一个具体痛点

代码已开源，欢迎交流：github.com/HotelEnglish/mdeditor