WordPress开发人员最容易犯的12个错误

本文概述

• 1.将WordPress主题JavaScript代码放入一个主文件
• 2.使用对于变量, 函数, 常量或类太常见的名称
• 3.不将现有的WordPress核心功能发挥到最大潜力
• 4.无法通过操作和过滤器使插件或主题易于更改
• 5.使用WP_DEBUG设置为false进行开发
• 6.编写PHP代码时不考虑页面可能被缓存一天
• 7.不跟踪通过版本控制系统(如Git)以专业方式进行的更改
• 8.在不需要CSS和JavaScript文件时排队
• 9.使用.php文件输出CSS或JavaScript代码, 而不是输出静态.css和.js文件
• 10.没有为WordPress插件和主题使用正确的架构(代码组织)
• 11.编写代码时没有认真考虑WordPress安全性
• 12.使用WordPress函数和代码片段而不了解它们
• 不断改进

WordPress是使网站快速启动和运行的一种非常流行的方法。但是, 匆匆忙忙地使许多开发人员最终做出了可怕的决定。可能容易犯一些错误, 例如将WP_DEBUG设置为true。其他的, 例如将所有JavaScript集中到一个文件中, 与懒惰的工程师一样普遍。无论你犯什么错误, 请继续阅读以找出新手和经验丰富的开发人员犯的12个最常见的WordPress错误。如果你发现自己犯了这些错误之一, 请不要绝望。每个错误都是学习的机会。

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

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

1. 随着时间的推移, 随着主题的不断发展, 该文件的大小可能会变得非常大, 并且功能会不断增长, 有时你会看到大小为1 MB的文件。即使在某些页面中只需要文件中10％的代码, 该文件也会在整个网站范围内加载。这将使页面下载时间更长, 渲染速度更慢, 尤其是如果页面顶部的渲染阻止代码。
2. 由于你无法使用wp_dequeue_script()之类的功能来卸载某些页面中的某些代码以提高页面速度或防止与其他JavaScript代码发生冲突, 因此这使文件内部代码的管理更加困难。由活动插件之一加载。当然, 可以将文件拆分为多个文件并放入WordPress中, 但是如果稍后, 网站管理员对主题的main.js文件进行了更新, 则整个过程必须重新开始。

2.使用对于变量, 函数, 常量或类太常见的名称

开发插件时, 最好使用命名约定, 以防止在其他插件使用相同名称的情况下发生代码冲突。这就是为什么许多开发人员在变量和函数名称前加上与插件本身相关的独特内容的原因。除了消除代码冲突之外, 当你启用了许多插件后, 它也使查找起来更容易。

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

1. 它们创建的代码与内部PHP或第三方, 类, 函数或常量之间的名称冲突
2. 别名(或缩短)Extra_Long_Names的能力旨在解决第一个问题或提高源代码的可读性。这是我的最爱, 因为我经常开发具有大量代码的主题或插件。这样, 我可以轻松阅读和管理代码, 而不必担心拥有长而唯一的名称。

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

根据你将要从事的项目, 除非你的工作大多与现有编码风格分开, 否则你可能必须坚持使用现有编码风格。如果你必须扩展已经遵循WordPress的PHP编码标准的现有插件或主题, 那么最好坚持使用它们, 以保持一致的样式, 从而使代码清晰易读。请注意, 为了提高性能, 普遍采用了一些规则, 而忽略了编码样式。例如, 如果你不评估字符串中的任何内容, 最好总是使用单引号(而不是双引号)。此外, 必须缩进代码才能读取, 特别是如果代码具有嵌套代码(例如, IF中的IF, 嵌套的FOREACH和FOR)时, 尤其如此。

3.不将现有的WordPress核心功能发挥到最大潜力

WordPress随附了一组定期更新的库, 可以在我们的插件和主题中调用它们, 因此最好尽可能多地利用现有的核心功能。我见过WordPress主题和插件, 它们的资产目录中的文件已经在WordPress核心文件中(例如jQuery或Color Picker)。除了软件包会变大并且需要更长的时间来通过网络加载外, 还必须确保所有第三方库都得到定期更新, 这是需要注意的另一件事。

利用WordPress已经提供的功能, 因为库已经由WordPress开发核心团队进行了更新, 你可以拥有一个轻量级且易于维护的项目。通过定期进行WordPress更新, 你可以访问更多功能(无论是插件, 主题还是WordPress核心本身, 因为其Dashboard都得到了持续改进), 以确保网站更安全, 以防在旧版本代码中发现漏洞。

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存储库进行交互的方式, 学习曲线更愉快。一旦了解了它的工作原理, 请考虑查看srcmini Developers的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文件中, 开发人员在需要检出某些内容时, 将很难阅读代码(混合了PHP变量和条件子句的CSS规则)。当然, 该文件可以在浏览器中运行(尽管我确定它在打印时不会缩进或看上去很漂亮), 但是如果你有项目的本地副本并浏览了主题代码, 则需要找到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())中使前端文件入队, 同时将要加载到queue_admin_scripts()方法中的管理区域中的文件入队。

与其将HTML与PHP代码混合在一起, 不如通过在插件和主题中实施MVC模式来保持HTML的分离。 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安装), 则脚本将退出并且不打印任何内容。

使用随机数：如WordPress文档中所述, 随机数是一个”一次使用的数字”, 可帮助保护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

如果没有有效的随机数, WordPress将使用众所周知的错误消息将” 403禁止”响应发送到浏览器：”确定要执行此操作吗？”

尽管大多数人不认真对待WordPress安全性, 但他们认为自己的网站永远不会遭到黑客攻击, 相信托管服务(这可能会有所帮助, 但只能在特定程度上发挥作用), 并相信他们购买了商业插件/主题(通常会导致(假设它们非常安全)), 我们应该始终对我们的网站进行渗透测试, 以便在任何黑客能够识别和利用它们之前识别出可利用的漏洞。

请注意, 许多黑客甚至没有一个人专门针对你的网站进行黑客攻击。通常, 有一些僵尸程序会自动一致地自动扫描WordPress网站, 一旦发现已知漏洞, 就会被利用, 并且该服务器会用于垃圾邮件, 从数据库中获取私人信息, 在网站的某些页面中放置隐藏的链接, 会导致各种不道德的网站(例如色情, 非法毒品)。有时, 这些黑客隐藏得非常好, 以至于你需要对你的网站进行适当的扫描, 并查看特定文件的更新日期才能检测到被黑客入侵的代码。这就是为什么最好重新安装WordPress(是的, 如果你使用的是最后一个版本, 则是同一版本), 这样, 所有被黑客入侵的文件都会被真正的WordPress核心文件覆盖。

12.使用WordPress函数和代码片段而不了解它们

通常, 当开发人员陷入困境并在StackOverflow之类的地方找到解决方案时, 他们只是对自己设法使某些东西工作而又不费心去理解该代码背后的逻辑, 或者是否可以更改该代码以使其更快或更短地加载而感到满意。代码行。

我见过很多次这种做法, 而实际上只有三分之一的代码片段被复制到PHP脚本中。

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

1. 该代码与现有项目代码使用的样式不同。是的, 只复制和粘贴开箱即用的片段很舒服, 尽管它们对于小型个人项目(可能有一天会变成大型项目, 谁知道)很好, 但这种做法通常不好到必须保持样式一致性的商业工作。
2. 尽管代码可以完成工作, 但是它可能包含无效的功能, 对于需要完成的任务不推荐使用。如果未对代码进行优化, 则这种”复制粘贴”做法可能会导致网站运行缓慢且难以维护, 尤其是在项目中的各个位置使用多个代码段的情况下。
3. 该代码可能未经许可可重复使用, 并且将代码包含在客户的项目中可能会使它们面临很多法律麻烦。

不断改进

每个人都会犯错, 每个错误都是提高自己的机会。作为WordPress开发人员, 我们的行业发展步伐非常快, 从来没有一种”正确的方式”来做事。但是, 你练习和学习的次数越多, 你就会越好。

你是否不同意我指出的任何错误, 或者认为我错过了一个错误？在评论中让我知道, 我们将进行讨论。

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