WordPress开发人员犯的12个最严重的错误
前言
原本之前还有篇ruby的，拖得时间有点久了，同时本身没想过去过多接触ruby，所以暂且就不再祸害那篇文章了，有兴趣的可自己去看Creating a Ruby DSL: A Guide to Advanced Metaprogramming，以下为本文的英文原文链接：
文章正文
WordPress是一种非常流行的站点快速搭建与运行的方式。 然而， 匆忙的时候，许多开发人员最终做出了可怕的决定。 一些错误，比如可能很容易犯的是将 WP_DEBUG 设置为true。其他的，如将你的JavaScript全写在一个单独的文件中， 是懒惰的工程师常见的做法。 无论你犯了什么错误，请继续阅读，找出新的和经验丰富的开发人员所犯的12个最常见的WordPress错误。 如果你发现自己犯了这些错误，不要绝望。每个错误都是学习的机会。 
1.将WordPress主题的JavaScript代码放入一个主文件中
有一次，在为客户的网站做页面速度优化时，我注意到他们使用了一个高级主题，这个主题包含了所有他们正在使用的库，包括定制代码，在一个名为 main.js, theme.js 或 custom.js的单文件中。这种做法不好，原因如下： 1.该文件可以随着主题的变化而变得非常大，正在积极开发中，将会增加功能，有时您将看到大小为1 MB的文件。该文件将在全站范围内加载，即使在某些页面中只需要文件中10%的代码。这将使页面需要更长的时间才能下载，并且渲染速度更慢，尤其是在页面的头部部分呈现阻塞（render blocking ）代码时。 2.它使得管理文件中的代码更加困难，因为您不能使用wp_dequeue_script()等功能来卸载某些页面中的某些代码，以提高页面速度或防止与其他活动插件中的JavaScript代码冲突。当然，这个文件可以被分成多个版本，并在WordPress中排队，但是如果在以后的某个时候，网站管理员会对主题的main.js 文件进行更新，然后整个过程又重新开始。
2.使用那些在变量、函数、常量或类中太常见的名称
在开发插件时，最好使用一种命名约定来防止代码冲突，以防有其他插件使用相同的名称。这就是为什么许多开发人员在他们的变量和函数名前面加上了一些与插件本身相关的独特的东西。除了消除代码冲突之外，在启用了大量插件时，还可以更容易地发现问题。 另一方面，开发人员更喜欢使用PHP名称空间来封装项目，并解决在创建可重用的代码元素时遇到的两个问题:类或函数： 1.它们创建的代码的命名与内部PHP或第三方、类、函数或常量之间的名称冲突。 2.能够为修复第一个问题或提高源代码的可读性的别名（或缩短）的Extra_Long_Names。这是我最喜欢的，因为我经常开发有很多代码的主题或插件。有了这个，我可以轻松地阅读和管理代码，而不必担心有很长的唯一名称。 在使用它们之前，我建议您很好地理解命名空间，因为它们常常以错误的方式使用。 根据您进行的项目，很可能您必须坚持现有的编码风格，除非您的工作大部分与现有的代码分离。如果您必须扩展已经遵循WordPress 的PHP编码标准的现有插件或主题，那么最好坚持使用它们以保持一致的样式，以便代码变得干净，易于阅读。注意，为了提高性能，一些规则被普遍应用，忽略了编码风格。例如，如果您不评估字符串中的任何内容，最好使用单引号（而不是双引号）。另外，为了更好的阅读代码，必须缩进代码，特别是如果它有嵌套代码(例如。如果在if内部，嵌套 FOREACHs 和 FORs)。
3.不利用现有的WordPress核心功能来实现其真正的潜力
由于WordPress附带了一套定期更新的库，可以在我们的插件和主题中调用，最好只是尽可能地利用现有的核心功能。我看到WordPress主题和插件，他们的资产目录中已经有WordPress核心文件（例如，jQuery或Color Picker)）中的文件。除了包装将会变得更大，并且需要更长的时间以加载到网络上，您还必须确保所有第三方库都经常更新，这只是另一件需要处理的事情。 利用WordPress已经提供的功能，因为libraries已经由WordPress开发核心团队更新，您可以轻松轻松地维护项目。通过定期进行WordPress更新，您可以访问更多的功能（无论是插件，主题还是WordPress核心本身，因为其信息中心的持续改进），并使网站更安全，以防在旧的代码版本中发现漏洞。
4.不要让插件或主题易于通过Actions和过滤器改变
直接编辑WordPress插件或主题是一个坏主意，除非您直接参与该包的开发并为其代码做出贡献。如果对插件或主题执行自动更新，那么对包的任何直接更改都将丢失，您将不得不重新编辑文件。 这就是为什么使用动作和过滤器以及创建Child主题（扩展父主题）是修改主题的最有效方法，因为您可以在不修改父主题或插件本身的情况下更改现有功能。此外，如果您在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将是值得的，Git GUI软件如SourceTree（我最喜欢的一个）将简单地与您的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，或者如果有要在Dashboard和前端视图中加载的CSS和JavaScript文件，那么一个类，如class.scripts.php可以使用，在enqueuepublicscript()等方法中对前端文件进行排队，并在enqueueadminscript()方法中排队等待装载的文件。 与其将HTML与PHP代码混合，不如通过在插件和主题中实现MVC模式来保持分离。一个很好的例子是WooCommerce插件。。它具有各种布局的模板，也可以通过主题或各种过滤器轻松覆盖，仅仅因为逻辑与设计分离。包含HTML布局的模板主要用于打印已处理的信息。在PHP方法中使用HTML代码通常是一种不好的做法(当然对于小的HTML代码也有例外)，特别是对于一个由多个开发人员维护的插件来说。 根据WordPress插件手册，虽然有许多可能的架构模式，它们可以大致分为三类：
11.写代码时不认真对待WordPress安全问题
在WordPress的开发中，安全性常常没有得到重视，因为许多新手开发人员更关注客户想要的结果。所有的一切都很好，直到客户的网站被黑客攻击，或者你的插件在WordPress.org 上发布了一个漏洞，使得成千上万的网站受到影响。这些事情有时会发生，甚至WordPress核心在CMS的早期就已经处理了相当多的安全漏洞。我们的责任是让它尽可能的安全，并且，万一发生了什么事情，立即行动，确保我们发布了一个可靠的、经过良好测试的补丁。 一些最重要的安全提示是： XSS漏洞：为避免这一点，必须做两件事情：清理数据输入并清理输出数据。根据使用的数据和上下文，WordPress中有几种方法来清理代码。不应该信任任何输入数据，也不应信任何打印的数据。消除数据输入的一个常见函数是sanitize_text_field()。它检查无效的UTF-8字符，将单个<字符转换为HTML实体，删除所有标签，删除换行符，制表符和额外的空格和条形字节。对于打印数据，输出链接的一个很好的例子是esc_url()函数，它拒绝无效的url，消除无效字符，并删除危险字符。 防止直接访问您的文件：大多数主机允许文件可以直接访问。但是，如果发生这种情况，并且代码没有正确地编写来处理它，那么可能会打印一些错误(例如:没有声明的函数或变量)将包含对潜在攻击者有用的信息。您经常在插件和主题中看到的一个常见代码片段是:
// Exit if accessed directly
if ( ! defined( 'ABSPATH' ) ) exit;
2
如果常量ABSPATH没有定义（应该是任何WordPress安装），那么脚本将退出并且不打印。 使用Nonces：如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会认为这个请求是有效的。 当这里存在nonce时，攻击者将无法轻松地获得该值(为实际登录到WordPress的管理员所生成的)。新的请求网址将如下所示： http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204 如果没有有效的nonce，将会有一个403的禁止响应被WordPress发送到浏览器，其中有一条众所周知的错误消息:“您确定您想要这样做吗?（Are you sure you want to do this?）” 虽然大多数人不重视WordPress安全，认为他们的网站永远不会被黑客入侵，信任托管(这可以可能是有帮助的，但只能在某一点上)和他们购买的商业插件/主题(通常导致假设它们很安全)，，我们应该始终对我们的网站进行渗透测试，以便在任何黑客能够识别和利用它们之前识别可利用的漏洞。 请注意，一些人甚至没有进行大量的黑客攻击，特意攻击你的网站。通常有一些机器人可以在一致的基础上自动扫描WordPress网站，,发现目前已知的漏洞并利用它，服务器被用于发送垃圾邮件，从数据库获取私人信息，，将隐藏的链接放在网站的某些页面中将导致各种诡异的网站（例如色情，非法药物）。有时，这些黑客隐藏得如此之好，以至于你需要对你的网站进行适当的扫描，并查看特定文件被更新的日期，以便发现被入侵的代码。这就是为什么重新安装WordPress的原因(是的，如果你有最后一个版本的话)，因为任何被入侵的文件都将被真正的WordPress核心文件所覆盖。
12.使用WordPress函数和代码片段但不理解它们
通常情况下，当开发人员陷入困境并在StackOverflow这样的地方找到解决方案时，他们很高兴他们设法使某些工作成功，而不去理解该代码背后的逻辑，或者该代码可以被更改为加载更快或更少代码行。 在PHP脚本中，只有三分之一的代码被实际使用时，我已经多次看到这种做法。 这可能有一些缺点，包括： 1.代码不使用与现有项目代码相同的样式。是的，只需复制和粘贴片即可实现的即时贴即可轻松完成，虽然它们适用于小型个人项目（有时候可能会变成一个大项目，谁知道），但这种做法对于必须保持风格一致性的商业工作往往不太好。 2.虽然代码执行其工作，但它可能包含不需要实现的任务的无效函数。如果代码没有进行优化，那么这种“复制粘贴”的实践可能会导致维护网站的速度变慢，尤其是在项目的不同位置使用了多个代码片段。 3.代码可能没有被许可用于重用，并且包含客户端项目中的代码可能会使他们面临许多法律问题。
不断改进
每个人都会犯错误，每个错误都是提升自己的机会。作为WordPress的开发者，我们的行业以非常快的速度发展，而且从来没有一种“正确的方式”来做事情。然而，你练习和学习的越多，你就会变得越好。 你不同意我指出的任何错误，还是认为我错过了一个？让我在评论中知道，我们将一起探讨。
除特别注明外，本站所有文章均为 竹风清语 原创，转载请注明出处来自： wordpresskaifarenyuanfande12gezuiyanzhongdecuowu
暂无数据