如何进行现代 WordPress 开发（第 1 部分）

已发表: 2022-03-11

WordPress 代码库一团糟已经不是什么秘密了。 就我个人而言，每次经历它，我只想蜷缩起来哭泣。 另一方面，WordPress 远远领先于竞争对手。 易于使用且功能强大的 CMS 是一项艰巨的任务，而 WordPress 仍然很受欢迎，因为它提供了这一点。

那么我们为什么要关心 WordPress 核心中的代码质量呢？ 它有效，对吧？

是的，它可以工作，而且这个有 15 年历史的代码库不太可能被它的志愿者维护者完全重构。 不幸的是，这意味着它也可以作为编码“WordPress 方式”的示例，为许多开发人员不遵循最佳实践和现代开发技术开脱。 如此多的 WordPress 插件和主题的代码臭名昭著，盲目地遵循传统做法只会继续这种趋势。

但是谁在乎仍然有效的糟糕代码呢？ 好吧，没有什么是免费的，有人会为做得不好的工作买单。 谢天谢地，有了 WordPress 代码库本身，它的维护者付出了他们的时间。 但是使用您自己的代码，支付费用的是您的客户。

对于任何即使是中等复杂的系统，初始开发的成本与维护成本相比都是微不足道的，维护也意味着添加新功能。 聘请开发人员来修复设计和实施不佳的软件的成本将比从一开始就正确开发软件的成本高出数倍。

从长远来看，廉价的解决方案总是最昂贵的。 或者他们在预算用完后被放弃。 当我们遵循经过验证的软件设计原则和实践时，我们实际上可以节省客户的资金。 这些方法不是炒作的时尚，也不是为了改变而改变。 这里的智慧源于集体开发人员的经验，遵循它确实有回报。

显然，这不适用于真正简单的任务，例如添加几行 CSS 或几个自定义帖子和重写。 但无论如何，将几个插件（或更常见的几十个插件）拼凑在一起或制作一个由 Visual Composer 提供支持的网站都不是软件工程。

这本身并不是一件坏事——一些解决方案如此简单的事实就是 WordPress 如此受欢迎的原因。 但在本系列中，我将讨论真正的WordPress 开发：编写重要的 PHP、HTML、CSS 和 JavaScript 代码。 我将从一般工作流程开始，然后在本文中关注 WordPress 前端开发。

现代 WordPress 开发工作流程

一般来说，质量代码是：

  • 可读。 很容易理解代码的作用和原因。
  • 模块化的。 目的明确的小代码块易于理解、开发和测试。
  • 可重复使用的。 重新使用已经开发的模块来解决类似的问题可以显着加快开发速度。
  • 可维护。 修改旧功能或引入新功能很容易。

主要结果——更低的开发成本和拥有成本——有许多附带的好处，我不会在这里讨论。

相反，我将关注哪些开发技术和最佳实践可以帮助您生成高质量的代码。 让我们从版本控制开始。

使用版本控制

这意味着使用 Git。 可悲的是，通过 FTP 进行生产的“牛仔编码”几乎仍然是一回事。 就在最近，我在一家位于英国的机构工作，他们的代码库中都有类似以下名称的文件：

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

使用 WordPress 网站时，您应该做的第一件事就是将其置于版本控制之下。 Tanking Servers 是对 WordPress 开发错误的有趣回顾。 使用 Git 来修改那些可能发生在每个人身上的类似事故是非常容易的。

你的代码出错了，整个网站都崩溃了？ git reset让一切恢复原状。 新版本更新破坏了一切？ git reset作为时间机器工作。 一些恶意代码不知从何而来？ git status显示任何新文件、已删除文件或任何跟踪文件的更改。 然后你只需git checkout ，恢复原件。

小心暴露.git文件夹

好的，使用 Git 显然很重要。 但是当你这样做时，避免让你的 Git 存储库被黑客入侵同样重要。 当您公开.git文件夹并将您的凭据存储在其中时，问题就来了。

标准的 WordPress 安装完全存在于公共网络文件夹中，并且.git文件夹也很可能在那里。 显然，不应将登录凭据存储在 Git 存储库中，但碰巧大多数存储库确实包含一些不应泄露到外部的敏感信息。

所以应该阻止对.git文件夹的公共访问。 如果您使用的是 Apache，在.htaccess文件顶部添加下面的代码段将阻止对.git文件夹和日志文件的访问。 日志文件通常包含敏感信息，因此明智的做法是让它们也不可用。 对于不同的 Web 服务器设置，请向您的 DevOps 专家寻求帮助。

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

使用单独的环境

不要在实时站点上进行开发——这是停机和客户不满意的秘诀。 好的，但是你应该如何设置呢？

理想情况下，应该有三个开发环境，代码总是朝着一个方向发展：本地→登台→生产。 这是一种经过验证的避免碰撞的方法。 所有核心、插件和主题更新首先在本地完成，然后在 staging 上进行测试，最后部署到生产环境。

例如，特定于服务器的配置可以存储在单独的文件中。 您可以为每个本地和临时环境创建一个wp-config-local.php 。 （不要忘记将它添加到您的.gitignore文件中！）然后将以下代码段添加到wp-config.php ：

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

通常设置不同环境的最佳方法是使用环境变量。 如果您不熟悉这个概念，我建议您使用像 Roots 这样的完整现代解决方案。

使用 WP-CLI

WordPress 命令行界面 (WP-CLI) 是用于管理 WordPress 安装的非常有用的工具。 访问 WP-CLI 意味着能够运行几乎任何 WordPress API 功能。 例如，您可以使用 WP-CLI 添加、删除和编辑用户及其密码。 如果您刚刚继承了一个站点并且所有者已将自己锁定，则很有用。

另一个例子是使用 WP-CLI 可以轻而易举地进行初始部署。 这些可以通过几个命令来完成：

  • 下载核心、主题和插件
  • 在数据库中搜索和替换
  • 添加管理员用户

此外，这些动作可以脚本化和自动化。

使用高级部署选项

说到自动化，值得学习一些部署技术和流程，例如：

  • 持续集成/持续部署/交付 (CI/CD)
  • 码头工人
  • 自动化测试（包括前端回归测试）

诚然，从不使用版本控制到处理 Docker 是一个巨大的飞跃，对于一个典型的单人 WordPress 项目来说可能是压倒性的。 根据您的托管服务提供商，某些选项甚至可能无法实现。 但是对于团队和大型项目来说，高级部署是必不可少的。

使用 Linting

但是，对于任何规模的项目，linting 对大多数开发人员来说都是一个福音。 Linting 意味着自动检查您的代码是否有错误。 PHPStorm 等功能齐全的 IDE 已经开箱即用。 然而，像 VSCode 或 Sublime Text 这样更简单的编辑器需要一个称为 linter 的专用程序。 一种设置方法是将编辑器配置为在保存文件时运行 linter。

PHP_CodeSniffer 是 PHP 的事实上的 linter。 除了检查语法错误之外，它还可以检查您的代码是否遵循 PSR-2 等样式指南。 这大大简化了以下编码标准。

对于 JavaScript，ESLint 是一种流行的 linter。 它有一个广泛的规则集，并支持所有 JavaScript 风格和框架的自定义配置。

这里一个强大的用例是将 linting 合并到 CI/CD 构建管道中，以便在部署之前自动验证所有代码。

现代 WordPress 前端开发技术

现在为您的整个 WordPress 项目设置了适当的工作流程，让我们深入研究前端的最佳实践。

使用现代工具：Sass 和 ES6+

前端开发世界瞬息万变，始终处于动态之中。 曾经我们认为 Sass 是编写 CSS 的最佳工具——对于古腾堡之前的 WordPress 开发来说，它仍然是——但后来每个人都开始谈论 CSS-in-JS 和样式化组件。

甚至 WordPress 也无法抗拒并采用了其中的一些新技术。 新的块编辑器 Gutenberg 建立在 React 和 REST API 之上。

您绝对应该了解这些核心前端技术：

  • ES6+。 WordPress 文档将其称为 ESNext，甚至鼓励使用它。
  • 萨斯。 由 WooCommerce 使用，如果您还没有进入 CSS-in-JS 的领域，这是编写 CSS 的最佳方式。
  • 网页包。 甚至 WordPress 核心现在也使用 Webpack 和 Babel。

ES6 和 Sass 分别是现代 JavaScript 和 CSS，而 Webpack 是一个允许使用所有这些现代特性而无需担心向后兼容性的工具。 Webpack 可以称为前端应用程序编译器，它生成文件以供在浏览器中使用。

从 jQuery 过渡到 Vue.js 或 React

WordPress 核心和几乎所有 WordPress 插件都依赖于 jQuery，所以你不能停止使用它。 实际上，当您习惯于这样做时，停止将它用于简单的任务（例如隐藏几个<div>或执行一次性 AJAX 请求）是没有意义的。 无论如何都会加载 jQuery，而且它简单易用。

复杂的应用程序是 jQuery 苦苦挣扎的地方：难以遵循的逻辑、回调地狱、全局变量和没有 HTML 模板。 这显然需要一种不同的方式来组织前端应用程序。

React 等现代前端库使用面向对象编程 (OOP) 原则，并将前端应用程序架构组织成模块化、可重用的组件。 组件包含特定元素的所有代码、标记和“组件状态”（变量）。 元素几乎可以是任何东西：按钮、输入字段、用户表单或显示来自 WordPress REST API 后端的最新帖子的小部件。 组件可以包含其他组件，形成层次关系。

随着当今网页的复杂性，将应用程序组织成组件是构建任何复杂性的可维护、快速 Web 应用程序的一种行之有效的方法。 组件是高度可重用、隔离的，因此易于测试的“砖块”，因此学习这个概念真的很值得。

目前有两个流行的基于组件的库：Vue.js 和 React。 React 将是一个显而易见的选择，因为它已经被 Gutenberg 使用。 然而，对于新接触现代 JavaScript 的人来说，Vue.js 可能会更好。

React 通过使用 ES6 特性、类、专有 JSX 语法和 Webpack 构建管道直接将您带入深渊。 学习曲线相当陡峭。

另一方面，Vue.js 对初学者更加友好，只需放入<script>标记即可使用。 Vue.js 使用纯 JavaScript (ES5)、HTML 和 CSS。 新概念的引入要循序渐进。

在完成了几个 Vue.js 项目之后，您将更好地准备深入研究 React。 并不是说它总是需要，但例如古腾堡开发确实需要它。

使用 WordPress REST API

WordPress 的 REST API 只是一个标准化接口，用于从 WordPress 远程请求和修改数据。 它更像是一种软件架构，而不是一种完全不同的编码方式。 相同的旧 jQuery AJAX 片段可以使用稍有不同的参数。

最重要的好处？ 由于 WordPress REST API 标准化了后端和前端之间的通信，因此这是朝着代码模块化、可重用性和可读性迈出的重要一步。 那些将 HTML 和 PHP 混合在一起的可怕模板以及一些混合在一起的 SQL 必须删除。 一旦模板只是带有作为参数传递的数据的占位符的 HTML，那么在 PHP 中或通过 REST API 将数据传递到前端应用程序之间没有重大区别。

您可能还想查看 WPGraphQL。 它最终可能会或可能不会取代 WordPress REST API，但它正在迅速获得关注。

学习古腾堡（客户很快就会需要它）

Gutenberg 的最终目标是全站点定制，以及其他计划。

这为 WordPress Core 的新模型奠定了基础，该模型最终将影响平台的整个发布体验。

GitHub 上的 WordPress Gutenberg 项目页面

Gutenberg 确实受到了 WordPress 开发人员的强烈反对。 反对将其合并到 WordPress 核心中的一些论点是：

  • 很大一部分最终用户不需要它，因此它应该是一个可选插件，而不是核心的一部分
  • 它破坏了一些网站
  • 它根本没有准备好，可以使用更多的抛光和更少的错误

但是，对于使用 WordPress 作为博客平台的内容作者来说，Gutenberg 显然提供了比旧编辑器更好的体验。

只要需要，就会支持禁用古腾堡，是的。 但现在放松是一个明智的想法：当客户接近您并要求进行 Gutenberg 开发时，您将做好准备。

是时候加快速度了：即使是“WordPress 方式”也在不断发展

反对在 WordPress 开发中使用上述所有工具和技术的最常见论点是：“WordPress 方式”做事仍然有效，而且这种方式应该比所有这些新的闪亮的东西更好。

但是您现在已经看到，WordPress 核心开发人员非常了解所有最新发展。 不仅如此，由于其明显的优势，他们在核心的更新部分尽可能多地使用它们。 唯一阻碍我们的是没有人会重构的遗留代码。

一段时间以来，WordPress 和 WooCommerce 一直在遵循开发实现和使用新技术的“功能插件”的做法。 时机成熟时，这些插件会像 Gutenberg 那样合并到核心中。 WooCommerce 也有自己的 React 项目。 WordPress REST API 也开始作为一个单独的插件，现在是 WordPress 核心的一部分。

问题不在于我们是否应该学习新事物并在我的日常工作中使用它们，而是如何。 答案是“循序渐进”，一步一步。 要么学习新事物，要么以新的不同方式做你熟悉的事情。

例如，学习如何将 Webpack 与所有旧脚本一起使用。 Webpack 可以将您的新 ES6+ 代码转换为与旧浏览器兼容的“普通”JavaScript。 它还可以缩小脚本并将它们捆绑在一起。 这是一件新鲜事。 完毕？ 然后利用 ES6 特性重写你的 JavaScript。 这是一种新的方式来做你所熟悉的事情。

结果：您将学习 Webpack 和 ES6。 作为专业人士，我们应该站出来，而不是退后。 永远保持学习。 并在您这样做时分享：Toptal 维护着一个 WordPress 开发最佳实践列表，并欢迎社区对其做出贡献。

在我们系列的第 2 部分中，我们将深入探讨现代 WordPress 后端开发的 PHP 部分。