WordPress是一种非常流行的快速建立和运行网站的方式. 然而，在匆忙中，许多开发者最终做出了糟糕的决定. 有些错误，比如离开 WP_DEBUG 设置为 true 可能很容易做. 其他的，比如将所有的JavaScript集中到一个文件中，就像懒惰的工程师一样常见. 不管你犯了什么错误, 继续往下读，找出新老开发者最常犯的12个WordPress错误. 如果你发现自己犯了这些错误，不要绝望. 每一次错误都是一次学习的机会.

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

Once, 同时为客户网站做页面速度优化, 我注意到他们正在使用一个高级主题，其中包含了他们正在使用的所有库, 包括自定义代码, 在一个叫做 main.js, 主题.js or 自定义.js. 这种做法是不好的，原因如下:

1. 该文件, 在时间, 能像主题一样大吗, 积极发展, 会增加功能，有时你会看到大小达1mb的文件. 即使在某些页面中只需要该文件的10%的代码，该文件也将在整个站点范围内加载. 这将使页面下载时间更长，渲染速度更慢，特别是如果它是 渲染阻塞 页面标题部分内的代码.
2. 这使得管理文件中的代码变得更加困难，因为您不能使用 wp_dequeue_script () 卸载某些页面中的一些代码，以提高页面速度或防止与可能由活动插件之一加载的其他JavaScript代码发生冲突. 确定, 该文件可以分成多个文件，并在WordPress中排队, 但如果在以后的某个时刻, 网站管理员执行主题的更新 main.js 文件，那么整个过程就得从头再来.

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

开发插件时, 最好使用一个命名约定，以防止代码冲突，以防其他插件使用相同的名称. 这就是为什么许多开发人员在变量和函数名前加上一些与插件本身相关的唯一前缀. 除了消除代码冲突, 当您启用了许多插件时，它也使内容更容易找到.

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

1. 命名它们创建的代码之间的冲突, 和内部PHP, 或第三方, 类, 功能, 或常量
2. 别名(或缩写)的能力 Extra_Long_Names 旨在解决第一个问题或提高源代码的可读性. 这是我最喜欢的，因为我经常开发有很多代码的主题或插件. 用这个, 我可以轻松地阅读和管理代码，而不必担心长唯一的名称.

我建议在使用名称空间之前对它们有一个很好的理解，因为它们经常被错误地使用.

这取决于你要接手的项目, 您很可能不得不坚持使用现有的编码风格, 除非你的工作基本上与现有的工作是分开的. 如果您必须扩展已经遵循的现有插件或主题 PHP编码标准 对于WordPress, 然后，为了保持一致的风格，最好坚持使用它们，这样代码就会变得干净、易于阅读. 请注意，为了提高性能，有些规则是通用的, 忽略编码风格. 例如, 如果不计算字符串中的任何内容，最好使用单引号(而不是双引号). 此外，代码必须缩进以便读取，特别是如果它有嵌套代码(例如.g., IF年代内 IF年代,嵌套 FOREACH年代和 FORs).

3. 没有充分利用现有WordPress核心功能的真正潜力

因为WordPress自带了一套定期更新的库，可以在我们的插件和主题中调用, 最好尽可能多地利用现有的核心功能. 我看到WordPress主题和插件的资产目录中有一些文件已经在WordPress核心文件中了.g.， jQuery或颜色选择器). 除此之外，包会变得更大，需要更长的时间通过网络加载, 您还必须确保定期更新所有第三方库, 这是另一件需要处理的事情吗.

利用WordPress已经提供的东西, 因为这些库已经被WordPress开发核心团队更新了，你可以拥有一个轻量级的、更容易维护的项目. 通过定期更新WordPress, 你可以访问更多的功能(无论是插件), 一个主题, 或者WordPress核心本身，因为它的仪表板一直在改进)，并使网站更安全，以防在旧代码版本中发现漏洞.

4. 没有使插件或主题容易改变通过动作和过滤器

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

这就是为什么使用操作和过滤器以及创建子主题(扩展父主题)是修改主题的最有效方法，因为您可以在不编辑父主题或插件本身的情况下更改现有功能. 此外，如果你在WordPress上提供免费下载的插件.Org，后来你想创建一个高级扩展，将依赖于父插件, 然后你应该开发免费的插件，以这样一种方式，它将很容易扩展和添加高级扩展.

5. 发展与 WP_DEBUG 设置为 假

默认情况下， WP_DEBUG constant设置为假以避免打印任何PHP错误、警告和通知. 在实时环境中, 这是一个推荐的选择，因为它将私有服务器路径和脚本隐藏在公共视图之外, 从安全的角度来看，这是很好的选择. 然而, 在开发阶段, 最好将它设置为“true”，因为它会通知我们代码中的任何错误. 即使错误不直接影响功能, 它通常会迫使您编写更好的代码并养成更好的编码习惯. 这发生在我身上. 这也将确保你开发的插件或主题不会在任何WordPress安装中产生PHP错误.

虽然这是大多数有经验的开发人员都会做的事情，但它确实会发生，尤其是在匆忙之中. 不管工作有多紧急, 开发人员应该始终保持WordPress编码标准, 显然着眼于PHP最佳实践.

6. 编写PHP代码时没有考虑到页面有一天会被缓存

这是一个常见的PHP错误, 就像上一个一样, 如果您坚持PHP编码标准，则相对容易避免这种情况.

一些开发人员习惯于将PHP代码片段实现到主题和插件中，只有当PHP代码一直被触发时才有效. 例如, 一个PHP函数，它响应HTTP用户代理的某些操作应该采取或不采取(例如).g.(仅适用于移动用户的排队脚本).

如果你的客户端安装了一个插件来缓存页面(e.g., W3 Total Cache或WP Rocket)，而不会触发主题或插件中的条件, 您的PHP代码将变得无用. 如果目的是使页面响应, 那么这应该通过媒体查询和JavaScript在前端端完成. 后者，只有在确实需要时才会使用. 理想情况下，您希望避免使用JavaScript来使站点响应.

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

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

虽然一开始可能有点吓人, 特别是对于初级开发人员, 了解Git是值得的，像SourceTree(我最喜欢的软件之一)这样的Git GUI软件将是您与Git存储库交互的简单方式, 使整个学习曲线更愉快. 一旦你理解了它是如何工作的，就考虑检查一下 由total 开发人员提供的Git最佳实践和技巧 它更深入地解释了使用Git的几种方法.

8. 当CSS和JavaScript文件不需要时排队

有很多HTTP请求会使网站加载速度变慢, 因此，在谷歌页面速度得分较低，这可能会影响搜索排名. 它也可能导致JavaScript错误，由于插件之间的冲突. 例如, 可能有两个插件使用一个通用的jQuery库, 哪些可能被加载两次并可能导致问题. 和真正的, 这是最好的例子, 因为jQuery通常会在实时网站上多次加载. 这可能是由于编写糟糕的插件或主题.

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

我见过一些主题，甚至WordPress插件都有这样的文件 style.php 用来生成定制的CSS代码并打印出来. 比如颜色, 字体大小和元素周围的间距在主题的设置中设置，然后保存在数据库中. 然后风格.PHP是读(e)的.g., )，并根据仪表板中更新的自定义设置生成CSS代码.

就WordPress的性能而言，这确实是一种糟糕的做法. 以下是它的主要缺点:

1. 当CSS文件在 head 标签(这是正常的，大多数都是这样加载的), 这有一个性能问题，因为浏览器在呈现页面之前必须完全下载文件. 如果WordPress环境很慢，因为一些插件, 这将大大延迟加载时间. 即使使用了缓存技术，或者为了从数据库中检索值，只加载了部分WordPress环境. 最好使用静态 .CSS文件代替.
2. 在PHP文件中, 当开发人员需要检查某些内容时，代码(CSS规则与PHP变量和条件子句混合在一起)将更难阅读. 确定, 该文件可以在浏览器中运行(尽管我确定它是在打印时运行的), 它甚至不会缩进或好看)，但如果你有一个项目的本地副本，浏览主题的代码，你需要找到一个CSS或JavaScript语法(在情况下脚本.会使用PHP)，那么它会使可读性变得更加困难.

解决方案:将任何自定义CSS保存在插件目录之外. 例子: / wp-content /上传/ 主题-name-自定义-css / style-5.css. 这样，如果主题或插件得到更新，那么自定义文件将不会丢失.

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

根据插件的大小和性质(例如.g., 一个独立的插件或插件扩展，只有当一个主插件被激活，如WooCommerce), 必须建立正确的体系结构和代码组织.

如果你必须为客户端构建一个单一用途的WordPress插件，并且它与WordPress核心的交互有限, 主题, 和其他插件, 对复杂类进行工程设计是没有效果的，除非你确信插件将在以后进行相当大的扩展.

如果插件要被大量的代码所丰富, 那么使用面向对象编程(OOP)编码方法(有很多类)就有意义了. 例如, 如果你有很多短代码, 您可以将它们全部保存在单独的类文件中，例如 class.短码.php 或者如果有CSS和JavaScript文件要在仪表板和前端视图中加载，那么一个类，比如 class.脚本.php 可以在方法中使用前端文件并将其排队，例如 enqueue_public_脚本 () 的管理区域中要加载的文件排队时 enqueue_admin_脚本 () 方法.

而不是把HTML和PHP代码混在一起, 最好通过在插件和主题中实现MVC模式来将它们分开. 一个很好的例子是WooCommerce插件. 它有各种布局的模板，也可以通过主题或各种过滤器轻松覆盖，因为逻辑与设计分离. 包含HTML布局的模板主要用于打印已经处理过的信息. 在PHP方法中使用HTML代码通常是一种不好的做法(当然对于少量的HTML代码也有例外)。, 特别是对于一个由多个开发人员维护的插件，因为它的规模越来越大.

根据WordPress插件手册, 虽然有许多可能的体系结构模式, 它们大致可以分为三种变体:

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

11. 在编写代码时没有认真考虑WordPress的安全性

在WordPress开发中，安全性通常不被重视，因为许多新手开发人员更关注客户想要的结果. 一切都很好，直到客户的网站被黑客攻击或你的插件在WordPress上发布.Org有一个漏洞，导致数千个网站受到影响. 这些事情有时会发生，甚至WordPress核心也处理了相当多的安全漏洞，因为早期的CMS. 我们有责任让它尽可能的安全, 以防万一发生什么事, 迅速行动，确保我们释放出固体, 经过良好测试的补丁.

以下是一些最重要的安全提示:

XSS漏洞:为了避免这种情况, 必须做两件事:清理数据输入和清理输出数据. 取决于使用它的数据和上下文, WordPress中有几种方法可以对代码进行消毒. 人们不应该相信任何输入数据，也不应该相信任何将要打印出来的数据. 清理数据输入的一个常用函数是 sanitize_text_field (). 它检查无效的UTF-8字符, converts single < characters to HTML entities, 剥去所有标签, 删除换行符, 制表符和额外的空白和条形八位. 至于打印数据，输出链接的一个很好的例子是 esc_url () 函数, 拒绝无效的url, 消除无效字符, 去掉危险字符.

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

//如果直接访问，退出
if ( ! define ('ABSPATH')) exit;

如果常数 ABSPATH 没有定义(这应该是任何WordPress安装), 然后脚本将退出并不打印任何内容.

使用Nonces:如WordPress中所述 文档, nonce是“一次使用的数字”，用于帮助保护url和表单免受某些类型的误用, 恶意或其他.

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

攻击者可以做的是让你的浏览器在你不知情的情况下访问该URL，通过在第三方页面上制作链接，如下面的例子所示: 当向WordPress发出此请求时, 浏览器会自动附加你的身份验证cookie, WordPress会认为这个请求是有效的.

这时nonce就到位了，因为攻击者将无法轻易获得nonce值(为实际登录到WordPress的管理员生成). 新的请求URL看起来像这样: http://example.com/wp-admin/post.php?帖子= 123&action =垃圾&_wpnonce = b192fc4204

没有有效的nonce, WordPress会向浏览器发送一个403 Forbidden响应，并给出一个众所周知的错误信息:“你确定要这样做吗??”

尽管大多数人并不把WordPress的安全当回事, 以为他们的网站永远不会被黑, 信任主机(这很有帮助), 但只是在一定程度上)以及他们购买商业插件/主题的事实(这通常导致他们认为他们是非常安全的), 我们应该经常对我们的网站进行渗透测试，以便在任何黑客能够识别和利用它们之前识别可利用的漏洞.

请注意，大量的黑客攻击甚至不是由一个人专门攻击你的网站. 经常, 有一些机器人会在发现已知漏洞的那一刻自动扫描WordPress网站, 它被利用，服务器被用来发送垃圾邮件, 从数据库获取私有信息, 在网站的某些页面中放置隐藏链接，这将导致各种各样的可疑网站.g.、色情、非法药物). 有时, 黑客隐藏得很好，你需要对你的网站进行适当的扫描，看看特定文件更新的日期，以便检测被黑客攻击的代码. 这就是为什么重新安装WordPress是件好事(是的, 相同的版本，如果你有最后一个)，所以任何黑客文件将被真正的WordPress核心文件覆盖.

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

经常, 当开发人员陷入困境并在StackOverflow等地方找到解决方案时, 他们只是很高兴他们能够让某些东西工作，而无需费心去理解代码背后的逻辑，或者代码是否可以修改以加载更快或代码行数更少.

这种做法我见过很多次，在PHP脚本中复制代码片段，而实际上只使用了其中的三分之一.

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

1. 代码不使用与现有项目代码相同的样式. Yes, 只需复制和粘贴开箱即用的代码片段就可以了, 虽然它们对于一个小的个人项目来说很好(有一天它可能会变成一个大项目), 谁知道), 当涉及到必须保持风格一致性的商业作品时，这种做法通常不是很好.
2. 尽管代码完成了它的工作, 它可能包含无效的功能，不建议用于需要完成的任务. 如果代码没有优化, 这种“复制粘贴”的做法会导致网站运行缓慢且难以维护, 特别是如果在项目中的不同位置上使用多个代码片段.
3. 代码可能没有被许可重用, 将代码包含在客户的项目中会给他们带来很多法律上的麻烦.

不断改进

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

你是否不同意我指出的错误，或者认为我遗漏了一个? 请在评论中告诉我，我们将讨论.