本文概述
WordPress代码库一团糟, 这已经不是什么秘密了。就个人而言, 每次经历时, 我只想curl缩并哭泣。另一方面, WordPress在竞争中遥遥领先。易于使用且功能强大的CMS是一项艰巨的任务, 而WordPress仍然很受欢迎, 因为它提供了这一点。
那么, 为什么我们要关心WordPress核心中的代码质量？可以, 对吧？
是的, 它可以正常工作, 拥有15年历史的代码库不太可能被其志愿者维护者完全重构。不幸的是, 这意味着它还充当了” WordPress方式”编码的示例, 使许多开发人员不遵循最佳实践和现代开发技术而成为原谅。如此众多的WordPress插件和主题代码臭名昭著, 盲目地遵循传统做法只会继续保持这种趋势。
但是, 谁在乎仍然可以发挥作用的不良代码呢？好吧, 没有什么是免费的, 有人为做得不好的工作付钱。有了WordPress代码库本身, 其维护人员便付出了宝贵的时间。但是用你自己的代码, 是你的客户付款。
对于任何什至中等复杂的系统, 初始开发的成本与维护它的成本相比都是微不足道的, 维护也意味着添加新功能。雇用开发人员修复设计和实施不当的软件, 其成本将比从一开始就正确开发它的成本高出数倍。
从长远来看, 廉价的解决方案始终是最昂贵的解决方案。否则他们会在预算用完后被抛弃。遵循公认的软件设计原则和实践, 实际上可以为客户省钱。这些方法不是一时兴起的时尚, 也不是为了改变而改变。这里的智慧源于集体开发人员的经验, 遵循它确实可以带来回报。
显然, 这不适用于真正简单的任务, 例如添加几行CSS或几个自定义帖子和重写。但是, 将几个插件(或者更常见的是几十个插件)放在一起或者创建一个由Visual Composer驱动的网站并不是软件工程。
就本质而言, 这并不是一件坏事, 因为某些解决方案是如此简单, 这就是WordPress如此受欢迎的原因。但是在本系列中, 我将讨论真正的WordPress开发：编写重要的PHP, HTML, CSS和JavaScript代码。我将从常规的工作流程开始, 然后在本文中重点介绍WordPress前端开发。
现代WordPress开发工作流程
通常, 质量代码是：
- 可读。很容易理解代码的作用和原因。
- 模块化。用途明确的小代码块易于理解, 开发和测试。
- 可重用。重复使用已经开发的模块来解决类似问题, 可以大大加快开发速度。
- 可维护的。修改旧功能或引入新功能很容易。
主要结果-较低的开发和拥有成本-具有许多我不会在这里得到的附带利益。
相反, 我将重点介绍哪些开发技术和最佳实践可以帮助你产生高质量的代码。让我们从版本控制开始。
使用版本控制
这意味着使用Git。可悲的是, 通过FTP进行生产时的”牛仔编码”仍然是一回事。最近, 我在一家英国代理机构工作, 他们的代码库中都有这样的文件名：
- 函数copy.php
- 函数复制2.php
- 功能test.php
- functions2.php
- 函数test2.php
在使用WordPress网站时, 你应该做的第一件事就是将其置于版本控制之下。 Tanking Servers是对WordPress开发错误的有趣回顾。使用Git修正那些以及可能发生在每个人身上的类似不幸事件将非常容易。
你的代码有误, 整个网站都崩溃了？ git reset使一切恢复原状。新版本更新破坏了一切？ git reset可以用作时间机器。一些恶意代码从无处出现？ git status显示任何新文件, 已删除文件或对任何跟踪文件的更改。然后, 你只需git checkout即可恢复原始文件。
当心暴露.git文件夹
好的, 使用Git很重要。但是, 当你这样做时, 同样重要的是要避免使Git存储库受到黑客攻击。当暴露了.git文件夹并将凭据存储在其中时, 就会出现问题。
标准WordPress安装完全位于公共Web文件夹中, 并且.git文件夹也很可能也位于该文件夹中。显然, 不应将登录凭据存储在Git存储库中, 但是这种情况经常发生, 大多数存储库确实包含一些不应泄漏到外部的敏感信息。
因此, 应禁止对.git文件夹的公共访问。如果你使用的是Apache, 则将以下代码段添加到.htaccess文件顶部, 将会阻止对.git文件夹和日志文件的访问。日志文件通常包含敏感信息, 因此也应使其不可用。对于不同的Web服务器设置, 请向你的DevOps专家寻求帮助。
RedirectMatch 404 /\.git
RedirectMatch 404 ^.*\.log
使用单独的环境
不要在实时站点上进行开发-这是停机和客户不满的良方。好的, 但是你应该如何设置呢？
理想情况下, 应该有三个开发环境, 并且代码总是朝一个方向发展：本地→过渡→生产。这是避免冲突的行之有效的方法。所有核心, 插件和主题更新都首先在本地完成, 然后在阶段进行测试, 最后部署到生产中。
例如, 特定于服务器的配置可以存储在单独的文件中。你可以为每个本地和暂存环境创建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项目而言, 这可能是不堪重负的。根据你的托管服务提供商, 某些选项甚至可能无法实现。但是, 对于团队和大型项目而言, 高级部署是必不可少的。
使用棉绒
但是, 对于任何规模的项目, 棉绒对大多数开发人员来说都是福音。整理意味着自动检查你的代码是否有错误。诸如PHPStorm之类的功能完备的IDE可以立即实现。但是, 更简单的编辑器(例如VSCode或Sublime Text)需要一个名为linter的专用程序。进行此设置的一种方法是将编辑器配置为在保存文件时运行linter。
PHP_CodeSniffer是PHP的实际应用。除了检查语法错误之外, 它还可以检查你的代码是否遵循样式准则, 例如PSR-2。这大大简化了以下编码标准。
对于JavaScript, ESLint是一种流行的短毛猫。它具有广泛的规则集, 并支持所有JavaScript版本和框架的自定义配置。
一个强大的用例是将棉绒并入CI / CD构建管道, 以便在部署之前自动验证所有代码。
现代WordPress前端开发技术
现在, 为你的整个WordPress项目设置了适当的工作流程, 让我们深入了解前端的最佳做法。
使用现代工具：Sass和ES6 +
前端开发世界在不断变化, 并且始终处于动态状态。一旦我们认为Sass是编写CSS的最佳工具(对于古腾堡WordPress之前的开发而言, 它仍然是), 但是后来每个人都开始谈论CSS-in-JS和样式化组件。
甚至WordPress也无法抗拒并采用了其中一些新技术。新的块编辑器Gutenberg基于React和REST API构建。
你绝对应该掌握以下这些核心前端技术：
- ES6 +。 WordPress文档将其称为ESNext, 甚至鼓励使用它。
- ass子WooCommerce使用它作为编写CSS的最佳方法(如果你还不喜欢CSS-in-JS的话)。
- Webpack。甚至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。并非总是需要它, 但是例如Gutenberg开发确实需要它。
使用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项目页面
古腾堡确实得到了WordPress开发人员的大力支持。反对将其合并到WordPress核心中的一些论点是：
- 大量最终用户不需要它, 因此它应该是可选插件, 而不是核心的一部分
- 它破坏了一些网站
- 它根本还没有准备好, 可以使用更多的修饰和更少的错误。
但是, 对于使用WordPress作为博客平台的内容作者, 古腾堡显然提供了比旧编辑器更好的体验。
只要需要, 就会支持禁用Gutenberg。但是现在放松一下是一个明智的主意：当客户接近你并要求进行古腾堡开发时, 你就准备好了。
加快速度的时间：甚至” WordPress方式”也在不断发展
反对在WordPress开发中使用上述所有工具和技术的最常见论点是：做事的” WordPress方式”仍然有效, 并且该方式应该比所有这些新的闪亮事物都要好。
但是你现在已经看到WordPress核心开发人员对所有最新开发都非常了解。不仅如此, 由于其明显的优势, 他们在核心的较新部分中尽可能多地使用它们。唯一使我们退缩的是没有人会重构的遗留代码。
一段时间以来, WordPress和WooCommerce一直遵循开发实现和使用新技术的”功能插件”的做法。在适当的时候, 这些插件会像Gutenberg一样合并到核心中。 WooCommerce也有自己的React项目。 WordPress REST API也从一个单独的插件开始, 现已成为WordPress核心的一部分。
问题不是我们是否应该学习新事物并在日常工作中使用它们, 而是如何。答案是”逐步”, 一次只一步。学习新事物或以新的和不同的方式做自己熟悉的事情。
例如, 学习如何将Webpack与所有旧脚本一起使用。 Webpack可以将你的新ES6 +代码转换为与普通浏览器兼容的”普通” JavaScript。它还可以缩小脚本并将它们捆绑在一起。那是一件事。做完了吗然后利用ES6功能重写JavaScript。这是一种新的方式来做你熟悉的事情。
结果：你将学习Webpack和ES6。作为专业人士, 我们应该加强而不是退缩。始终保持学习。并在执行时分享：srcmini维护WordPress开发最佳实践的列表, 并欢迎社区对此做出贡献。
在本系列的第2部分中, 我们将深入探讨现代WordPress后端开发的PHP部分。
