云策 WordPress 开发者社区

社区新闻

利用 WordPress Playground 和 GitHub 简化区块主题开发

查看官方原文 ↗

区块主题和站点编辑器已经改变了 WordPress 的设计格局，使得偏好视觉界面而非代码的设计师也能进行专业的主题开发。这一转变向生态系统引入了一群新的创作者，他们之前依赖外部设计工具。然而，一个重大障碍依然存在：如何将站点编辑器数据库中的更改提取到主题的文件系统中，并集成到版本控制的工作流中？

本文详细介绍了一种“无代码”开发工作流，它结合了强大的工具——WordPress Playground、Create Block Theme (CBT) 插件和 GitHub——来弥合基于浏览器的设计与专业版本控制之间的鸿沟。

站点编辑器更改的核心挑战

在 WordPress 区块编辑器环境中，设计和样式存在于四个层面：

  • 默认：主要是 WordPress 核心的样式和布局。
  • 区块级：样式可以通过插件更改，并覆盖默认样式。
  • 主题级：样式是整个设计工具套件，由活动主题控制。它覆盖默认和区块级的样式和布局（例如模板和模板部件）。
  • 用户级：样式使用站点编辑器内的设计工具来修改样式和布局。这些更改存储在数据库中，并覆盖主题级样式。

主题更改的层级关系。

如前所述，当设计师在站点编辑器中修改模板时，这些更改会作为“用户级”定制存储在数据库中。如果没有办法将这些更改同步回主题文件（“主题级”），它们就无法在其他站点上轻松重用、进行版本控制，或在更新期间防止被覆盖。

深入了解工具

要理解此工作流如何弥合视觉设计与版本控制开发之间的差距，了解堆栈中每个工具的具体角色会很有帮助。

WordPress Playground 使用 WebAssembly (WASM) 在您的 Web 浏览器中完全运行一个完整的 WordPress 实例。它无需安装、无需服务器设置，也无需传统数据库。它充当一个“一次性”工作台，您可以启动特定环境、测试设计，完成后关闭标签页。

Create Block Theme (CBT) 插件提供了关键的 保存更改到主题 功能。它获取存储在 WordPress 数据库中的修改，并将其直接写入 Playground 内主题的虚拟文件系统，自动更新 theme.json 和 HTML 模板。

GitHub 提供版本控制 (Git)，允许您跟踪更改并进行协作。在此工作流中，GitHub 是“永久存储”。通过将 Playground 连接到 GitHub 仓库，您可以从“一次性”建站转变为专业生命周期，其中更改通过 Pull Requests (PRs) 提交。

设置工作台

工作流从启动一个预配置的 Playground 实例开始。您可以通过在 Playground URL 后附加插件 slug 来启动已安装必要工具的工作台：https://playground.wordpress.net/?plugin=gutenberg&plugin=create-block-theme

注意： 实例加载后，在 Playground 设置（站点管理器图标 ）中将存储类型设置为 “浏览器”，以确保在意外刷新页面时更改得以保留。

保存 Playground 实例的屏幕

从 GitHub 导入主题

要处理现有项目，必须从其 GitHub 仓库导入主题：

  1. 打开 Playground 菜单，选择 从 GitHub 导入。
  2. 验证与 GitHub 的连接。
  3. 提供仓库 URL，并指定导入的是 主题。
  4. 识别正确的目录（通常是根目录 /）。

Playground 将下载主题文件并在浏览器实例中激活主题，然后重新加载站点。

步骤 1：连接到 GitHub
步骤 2：识别 GitHub 仓库
步骤 3：告知 Playground GitHub 仓库的性质

设计和同步更改

主题激活后，修改直接在 站点编辑器 中进行。在站点编辑器中保存更改后，必须将其写入主题文件：

  1. 在编辑器内打开 CBT 侧边栏（点击顶部工具栏的扳手图标）。
  2. 选择 保存更改到主题。
  3. 可选地选择 本地化图像，将上传的媒体从数据库移动到主题的 /assets 文件夹。该文件夹可通过 WordPress 过滤器自定义。

此步骤将修改从 WordPress 数据库移动到 Playground 实例的虚拟文件系统中，为 GitHub 提交做好准备。

Create Block Theme 插件：保存更改 第 1 部分
Create Block Theme 插件：保存更改 第 2 部分

通过 Playground 提交 Pull Request

一旦设计同步到文件，就可以在不离开浏览器的情况下将更改提交回 GitHub：

  1. 打开 Playground 菜单，选择 导出到 GitHub。
  2. Playground 会自动填充仓库信息。
  3. 输入描述性的 提交信息。
  4. 点击 创建 Pull Request。

步骤 1：导出到 GitHub
步骤 2：导出到 GitHub 并附带提交信息
步骤 3：成功消息 + 指向 GitHub 上 PR 的链接。

在最后一步，您将找到一个指向已创建 GitHub PR 的链接，您可以在那里继续将其作为代码提交。

由 Playground 创建的 Pull Request 截图。

然后，开发人员可以访问 GitHub 来审查更改并将 Pull Request 合并到主项目中。

此工作流的用例

设计师到开发人员的交接： 设计师在站点编辑器中可视化工作，通过 CBT 保存更改，并提交 PR。开发人员在 GitHub 中审查代码，确保其符合标准后再合并。这消除了从设计工具到代码的“翻译”阶段。

快速原型设计和客户预览： 启动一个 Playground 实例，可视化地进行请求的布局更改，并与客户共享项目的 Playground URL 以获取即时反馈——无需触及暂存服务器。

开源主题贡献： 这使贡献民主化。任何人都可以点击链接在 Playground 中打开主题，可视化地修复样式错误，并提交 PR，而无需打开终端或代码编辑器。

通过使用这些强大工具的组合，WordPress 社区正在走向一个“用户”和“开发者”之间界限持续模糊的未来。这种基于浏览器的工作流提供了一种安全、可扩展且专业的方式来构建下一代区块主题，同时保持版本控制的完整性。