高级 WordPress 开发人员犯的 12 个最严重的错误

已发表: 2022-03-11

WordPress 是一种非常流行的快速启动和运行网站的方式。 然而，在匆忙中，许多开发人员最终做出了可怕的决定。 一些错误，例如将WP_DEBUG设置为true可能很容易犯。 其他的，比如将你所有的 JavaScript 集中到一个文件中，就像懒惰的工程师一样常见。 无论您犯了哪个错误，请继续阅读以找出新老开发人员所犯的 12 个最常见的 WordPress 错误。 如果您发现自己犯了这些错误之一，请不要绝望。 每个错误都是一次学习的机会。

WordPress 开发人员犯的主要错误

1. 将 WordPress 主题 JavaScript 代码放入一个主文件

有一次，在为客户的网站进行页面速度优化时，我注意到他们使用了一个高级主题，其中包含他们正在使用的所有库，包括自定义代码，在一个名为main.js 、 theme.js或custom.js的文件中. 这种做法是不好的，原因如下：

  1. 该文件随着时间的推移会变得非常大，因为正在积极开发的主题会增加功能，有时您会看到大至 1 MB 的文件。 即使某些页面只需要文件中 10% 的代码，该文件也会在站点范围内加载。 这将使页面下载时间更长，渲染速度更慢，特别是如果它在页面的 head 部分呈现阻塞代码。
  2. 它使管理文件中的代码更加困难，因为您不能使用诸如wp_dequeue_script()之类的函数来卸载某些页面中的某些代码以提高页面速度或防止与其他 JavaScript 代码发生冲突由活动插件之一加载。 当然，该文件可以拆分为多个文件并在 WordPress 中排队，但如果稍后网站管理员对主题的main.js文件执行更新，则整个过程必须重新开始。

2. 使用对变量、函数、常量或类来说太常见的名称

在开发插件时，最好使用一种命名约定，以防止代码冲突，以防有其他插件使用相同的名称。 这就是为什么许多开发人员在他们的变量和函数名称前加上一些独特的和与插件本身相关的东西。 除了消除代码冲突之外，当您启用大量插件时，它还可以让您更容易找到。

另一方面，有些开发人员更喜欢使用 PHP 命名空间来封装项目，并解决库和应用程序的作者在创建类或函数等可重用代码元素时遇到的两个问题：

  1. 他们创建的代码与内部 PHP 或第三方、类、函数或常量之间的名称冲突
  2. 能够为Extra_Long_Names起别名（或缩短），旨在解决第一个问题或提高源代码的可读性。 这是我最喜欢的一个，因为我经常开发包含大量代码的主题或插件。 有了这个，我可以轻松地阅读和管理代码，而不必担心有长的唯一名称。

我建议在使用命名空间之前对它们有一个很好的了解，因为它们经常会以错误的方式使用。

根据您将参与的项目，您可能必须坚持现有的编码风格，除非您的工作大部分与现有的编码风格分开。 如果您必须扩展已经遵循 WordPress 的 PHP 编码标准的现有插件或主题，那么最好坚持使用它们以保持一致的风格，从而使代码变得干净且易于阅读。 请注意，有些规则是普遍应用的，以提高性能，而忽略编码风格。 例如，如果您不评估字符串中的任何内容，最好使用单引号（而不是双引号）。 此外，代码必须缩进才能被阅读，特别是如果它有嵌套代码（例如， IF s 中的IF s，嵌套FOREACH s 和FOR s）。

3. 没有利用现有的 WordPress 核心功能发挥其真正潜力

由于 WordPress 带有一套定期更新的库，可以在我们的插件和主题中调用，因此最好尽可能多地利用现有的核心功能。 我已经看到 WordPress 主题和插件在其资产目录中有文件，而这些文件已经在 WordPress 核心文件中（例如，jQuery 或 Color Picker）。 除了包会变得更大并且通过网络加载需要更长的时间之外，您还必须确保定期更新所有第三方库，这只是另一件需要注意的事情。

利用 WordPress 已经提供的功能，因为库已经由 WordPress 开发核心团队更新，您可以拥有一个轻量级且更易于维护的项目。 通过定期进行 WordPress 更新，您可以获得更多功能（无论是插件、主题还是 WordPress 核心本身，因为它的仪表板一直在改进）并在旧代码版本中发现漏洞时使网站更加安全。

4. 不能通过操作和过滤器使插件或主题易于更改

直接编辑 WordPress 插件或主题不是一个好主意，当然，除非您直接参与该软件包的开发并为其代码做出贡献。 如果对插件或主题执行自动更新，则对包的任何直接更改都将丢失，您将不得不重新编辑文件。

这就是为什么使用动作和过滤器以及创建子主题（扩展父主题）是修改主题的最有效方法，因为您可以在不编辑父主题或插件本身的情况下更改现有功能。 此外，如果您在 WordPress.org 上提供免费下载的插件，并且稍后您想创建一个依赖于父插件的高级扩展，那么您应该以这样的方式开发免费插件：易于扩展和添加高级扩展。

5. 使用WP_DEBUG设置为false进行开发

默认情况下， WP_DEBUG常量设置为“false”以避免打印任何 PHP 错误、警告和通知。 在实时环境中，这是一个推荐的选择，因为它可以将私有服务器路径和脚本隐藏在公众视野之外，这对于安全原因来说非常有用。 但是，在开发阶段，最好将其设置为“true”，因为它会通知我们代码中的任何错误。 即使错误不会直接影响功能，它通常也会迫使您编写更好的代码并养成更好的编码习惯。 它发生在我身上。 这也将确保您开发的插件或主题不会在任何 WordPress 安装中生成 PHP 错误。

虽然这是大多数有经验的开发人员都会做的事情，但它确实会发生，尤其是在匆忙中。 无论工作多么紧迫，开发人员都应始终尝试维护 WordPress 编码标准，并明显关注 PHP 最佳实践。

6. 编写 PHP 代码而不考虑页面可能会被缓存

这是一个常见的 PHP 错误，与前一个错误一样，如果您坚持 PHP 编码标准，则相对容易避免。

一些开发人员习惯于将 PHP 代码片段实现到主题和插件中，这些代码片段只有在 PHP 代码一直被触发时才有效。 例如，应该采取或不采取以某些动作响应 HTTP 用户代理的 PHP 函数（例如，将仅用于移动用户的脚本排入队列）。

如果您的客户端安装了一个缓存页面的插件（例如，W3 Total Cache 或 WP Rocket）而没有触发您的主题或插件中的条件，您的 PHP 代码将变得无用。 如果目的是让页面响应，那么这应该通过媒体查询和 JavaScript 在前端完成。 后者，仅在确实需要时。 理想情况下，您希望避免使用 JavaScript 来使您的网站具有响应性。

7. 不通过 Git 等版本控制系统以专业的方式跟踪所做的更改

自定义编码的文件，例如子主题或自定义插件，理想情况下应该受版本控制。 Git 创建更改的记录，并允许开发人员在同一个 WordPress 项目上一起工作，或者在网站出现问题时轻松恢复到以前的版本。 此外，客户可以使用 Git 来跟踪为该特定项目雇用的所有开发人员所做的所有工作历史，特别是如果它是一个大型的、长期的 WordPress 自定义网站。

虽然一开始可能会让人望而生畏，尤其是对于初级开发人员来说，理解 Git 是值得的，而且像 SourceTree（我的最爱之一）这样的 Git GUI 软件将只是您与 Git 存储库交互的方式，使整个学习曲线更愉快。 一旦您了解了它的工作原理，请考虑查看 Toptal 开发人员的 Git 最佳实践和技巧，其中更深入地解释了使用 Git 的几种方法。

8. 在不需要 CSS 和 JavaScript 文件时将它们排入队列

拥有许多 HTTP 请求会使网站加载速度变慢，因此在 Google PageSpeed 中的得分较低，这可能会影响搜索排名。 由于插件之间的冲突，它还可能导致 JavaScript 错误。 例如，可能有两个插件使用一个通用的 jQuery 库，这可能会被加载两次并可能导致问题。 真的，这是最好的例子，因为 jQuery 经常在实时网站上加载多次。 这可能是由于插件或主题编写不佳而发生的。

9. 使用.php文件输出 CSS 或 JavaScript 代码而不是静态.css和.js文件

我见过一些主题甚至 WordPress 插件，其中包含style.php类的文件，这些文件仅用于生成自定义 CSS 代码并打印它。 颜色、字体大小和元素周围的间距等内容在主题设置中设置，然后保存在数据库中。 然后读取 style.php（例如<link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ）并根据自定义设置生成 CSS 代码已在仪表板中更新。

就 WordPress 性能而言，这确实是一种不好的做法。 以下是它的主要缺点：

  1. 由于 CSS 文件在head标记中加载（这是正常的，并且大多数都是这样加载的），因此存在性能问题，因为浏览器必须在渲染页面之前完全下载文件。 如果 WordPress 环境因为某些插件而变慢，那么这将大大延迟加载时间。 即使使用缓存技术或仅加载 WordPress 环境的一部分以便从数据库中检索值。 最好改用静态 .css 文件。
  2. 在 PHP 文件中，当开发人员需要检查某些内容时，代码（CSS 规则与 PHP 变量和条件子句混合在一起）将更难阅读。 当然，该文件可以在浏览器中运行（尽管我确定它何时打印，它甚至不会缩进或看起来不错）但是如果您有项目的本地副本并浏览主题的代码并且您需要找到 CSS 或 JavaScript 语法（以防使用 script.php），那么它会使可读性更难。

解决方案：将任何自定义 CSS 保存在插件目录之外。 示例： /wp-content/uploads/theme-name-custom-css/style-5.css 。 这样，万一主题或插件更新，自定义文件就不会丢失。

10. 没有为 WordPress 插件和主题使用正确的架构（代码组织）

根据插件的大小和性质（例如，独立插件或仅在激活主插件（如 WooCommerce）时才起作用的插件扩展），必须设置正确的架构和代码组织。

如果您必须为客户端构建一个单一用途的 WordPress 插件，并且它与 WordPress 核心、主题和其他插件的交互有限，那么设计复杂的类是无效的，除非您确定该插件稍后会大幅扩展在。

如果该插件将具有丰富的代码，那么使用面向对象的编程（OOP）编码方法（有很多类）将是有意义的。 例如，如果您有很多简码，您可以将它们全部保存在一个单独的类文件中，例如class.shortcodes.php ，或者如果有打算在仪表板和前端视图中加载的 CSS 和 JavaScript 文件然后可以使用诸如class.scripts.php之类的一个类，并将前端文件排入诸如enqueue_public_scripts()之类的方法中，同时将要在enqueue_admin_scripts()方法中的管理区域中加载的文件排入队列。

与其将 HTML 与 PHP 代码混合，不如通过在插件和主题中实现 MVC 模式来将其分开。 一个很好的例子是 WooCommerce 插件。 它具有各种布局的模板，也可以通过主题或各种过滤器轻松覆盖，因为逻辑与设计分离。 包含 HTML 布局的模板主要用于打印已处理的信息。 在 PHP 方法中包含 HTML 代码通常是一种不好的做法（当然，少量 HTML 代码也有例外），尤其是对于随着规模增长而由多个开发人员维护的插件。

根据 WordPress 插件手册，虽然有许多可能的架构模式，但它们可以大致分为三种变体：

  • 单个插件文件，包含函数
  • 单个插件文件，包含一个类、实例化对象和可选的函数
  • 主插件文件，然后是一个或多个类文件

11. 编写代码时不认真对待 WordPress 安全性

由于许多新手开发人员更关注客户想要的结果，因此在 WordPress 开发中通常不会认真考虑安全性。 一切都很好，直到客户的网站被黑客入侵或您在 WordPress.org 上发布的插件存在漏洞，导致数千个网站受到影响。 这些事情有时会发生，甚至自 CMS 早期以来，甚至 WordPress 核心都处理了相当多的安全漏洞。 我们有责任使其尽可能安全，并在发生某些事情时迅速采取行动，并确保我们发布一个可靠的、经过良好测试的补丁。

一些最重要的安全提示是：

XSS 漏洞：为避免这种情况，必须做两件事：清理数据输入和清理输出数据。 根据使用的数据和上下文，WordPress 中有几种方法可以清理代码。 不应该相信任何输入数据，也不应该相信任何将要打印的数据。 清理数据输入的一个常用函数是sanitize_text_field() 。 它检查无效的 UTF-8 字符，将单个 < 字符转换为 HTML 实体，去除所有标签，去除换行符、制表符和额外的空白并去除八位字节。 至于打印数据，输出链接的一个很好的例子是esc_url()函数，它拒绝无效的 URL，消除无效字符，并删除危险字符。

防止直接访问您的文件：大多数主机都允许直接访问文件。 但是，如果发生这种情况并且代码没有正确编写来处理它，则可能会打印一些错误（例如，缺少未声明的函数或变量），其中包含对潜在攻击者有价值的信息。 您经常在插件和主题中看到的一个常见代码片段是：

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

如果没有定义常量ABSPATH （应该适用于任何 WordPress 安装），那么脚本将退出并且不打印任何内容。

使用 Nonce：如 WordPress 文档中所述，nonce 是“使用一次的数字”，以帮助保护 URL 和表单免受某些类型的滥用、恶意或其他方式的影响。

例如，仪表板中的以下 URL 将用于删除帖子： http://example.com/wp-admin/post.php?post=123&action=trash — 当访问此 URL 时，WordPress 将验证身份验证 cookie 信息如果您拥有正确的权限（例如，您是拥有所有权限的管理员），该帖子将被删除。

攻击者可以做的是通过在第三方页面上制作链接，使您的浏览器在您不知情的情况下访问该 URL，如下例所示： <img src="http://example.com/wp-admin/post.php?post=123&action=trash" />当向 WordPress 发出此请求时，浏览器会自动附加您的身份验证 cookie，并且 WordPress 会认为该请求是有效的。

那是一个随机数出现的时候，因为攻击者将无法轻松获得随机数值（为实际登录到 WordPress 的管理员生成）。 新的请求 URL 如下所示： http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204 ://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

如果没有有效的 nonce，WordPress 将向浏览器发送 403 Forbidden 响应，其中包含众所周知的错误消息：“Are you sure you want to do this?”

尽管大多数人并不认真对待 WordPress 的安全性，认为他们的网站永远不会被黑客入侵，相信托管（这可能会有所帮助，但仅在一定程度上）以及他们购买商业插件/主题的事实（这通常会导致假设它们非常安全），我们应该始终对我们的网站进行渗透测试，以便在任何黑客能够识别和利用它们之前识别可利用的漏洞。

请注意，那里的大量黑客攻击甚至不是由一个人进行的，目的是专门入侵您的网站。 通常，有机器人会自动扫描 WordPress 网站，一旦发现已知漏洞，就会被利用，服务器用于发送垃圾邮件，从数据库中获取私人信息，在网站的某些页面中放置隐藏链接会导致各种狡猾的网站（例如，色情、非法药物）。 有时，黑客被隐藏得如此之好，以至于您需要正确扫描您的网站并查看特定文件的更新日期以检测被黑客入侵的代码。 这就是为什么重新安装 WordPress（是的，如果您有最后一个版本，则使用相同的版本）是很好的原因，因此任何被黑客入侵的文件都将被真正的 WordPress 核心文件覆盖。

12. 在不理解的情况下使用 WordPress 函数和代码片段

通常，当开发人员陷入困境并在 StackOverflow 之类的地方找到解决方案时，他们只是对自己成功完成某些工作而无需费心理解该代码背后的逻辑或者是否可以更改该代码以更快加载或更少的事实感到满意代码行。

我已经多次看到这种做法，即在 PHP 脚本中复制代码片段时，实际上只使用了三分之一的代码。

这可能有一些缺点，包括：

  1. 该代码不使用与现有项目代码相同的样式。 是的，只是复制和粘贴开箱即用的片段很舒服，虽然它们适用于小型个人项目（它可能有一天会变成一个大项目，谁知道），但这种做法通常并不好用于必须保持风格一致性的商业作品。
  2. 尽管代码完成了它的工作，但它可能包含不推荐用于需要完成的任务的无效功能。 如果代码没有优化，这种“复制和粘贴”的做法可能会导致网站维护缓慢且难以维护，尤其是在项目中的不同位置使用多个片段时。
  3. 代码可能未获得重用许可，并且将代码包含在客户的项目中可能会给它们带来很多法律问题。

不断改进

每个人都会犯错，每一个错误都是提升自己的机会。 作为 WordPress 开发人员，我们的行业发展速度非常快，而且从来没有一套“正确的方法”来做事。 然而，你练习和学习的越多，你就会变得越好。

您是否不同意我指出的任何错误，或者认为我遗漏了一个？ 在评论中让我知道，我们将讨论。

相关：我的五个最糟糕的 WordPress 开发错误