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

或者，对于我之前遇到过的所有服务器：回顾我犯过的五个最糟糕的 WordPress 错误

作为开发人员，我们在职业生涯的不同阶段会犯不同类型的错误。 特别是在 WordPress 开发中，随着我们对 WordPress 代码库的熟悉程度的提高，我们会犯不同类型的错误。

几年前，我听到马特·穆伦韦格 (Matt Mullenweg) 宣称大多数人会重复他们的错误，更聪明的人会从错误中吸取教训，而我们当中最聪明的人会从别人的错误中吸取教训。 我更喜欢这样，而且我要添加一个推论：每个人都会犯错误，谦虚的人私下分享这些错误，我们当中最大胆的人将它们写下来并发布在博客上！

不过以后有时间再细想。 您阅读这篇文章是因为您想了解火车事故，而我是工程师。 没有进一步的前言，和我一起回顾一下我作为 WordPress 开发人员所犯的五个最令人尴尬的错误。

我更新 WordPress Core 的黑客版本的时间

我刚刚从做非常不起眼的 CraigsList 编码演出毕业，到真正在一家真实的机构工作。 我已经到了！ 我很紧张在沙发以外的地方工作，而不是穿着睡衣。 但即便如此，我通常从 WordPress Doing It Wrong 中了解 WordPress Right，我发现吹嘘 WordPress 最佳实践是一种令人愉快的自我夸大，就像从不“破解核心”一样。

我在该机构的第一个 WordPress 开发任务是恢复一个停滞不前的项目——对于我当时的技能而言，这是一个相当复杂的项目。 它涉及对 WordPress 注册和登录流程的大量自定义。 以前的开发人员被认为通过简单地编辑核心wp-login文件就取得了重大进展。

我知道这是不可持续的，所以我的首要任务是安装备份/恢复插件，并用新下载的版本替换 WordPress 核心。 我确信在该项目中到目前为止还没有执行任何令人印象深刻的事情，并且我能够通过过滤器模仿现有的功能集。

那时我可能拥有或不具备的任何编码能力很快就变得无关紧要，因为我的新雇主正在发疯。 她不明白“hacking core”的意义，我也不够成熟，无法用通俗易懂的方式解释。 唯一暂时冷却她的额头是当我向她保证我可以通过我安装的备份/恢复插件恢复时。

你能猜到这是怎么回事吗？

就像命运一样，那个插件只备份了wp-content文件夹。 这些核心文件中的任何 WordPress hack 都一去不复返了。 我仍然记得我给她的电子邮件（她早就把我赶回了我的家庭办公室）：

伙计们，我不能做备份。

我真的准备好通过过滤器和操作来完成她想要的功能集，但她不会听到。 她当场解雇了我，威胁要起诉我，并且从来没有因为我两周的辛勤工作而付钱给我。 我太丢脸了。

我可以从这次经历中学到很多（现在很明显）的东西。 一般的教训是，在排练和确认之前备份不是备份，这是一个很好的教训。 但更让我印象深刻的是关于如何在 WordPress 中进行备份的具体课程——尤其是 WordPress 核心。

我学会了真正珍惜像 WP-Engine 这样的托管环境，它具有强大的备份/恢复系统。 许多精品主机都有各种命令行工具和其他以开发人员为中心的功能来执行备份，但 WP-Engine 是我的最爱。 除非您有一个非常大的网络，否则它会非常快。 用户界面很简单。 它有一个 UI，句号：任何知道如何使用 WordPress 的人都可以使用它。 即，与一些可能更快的 CLI 方法或隐藏在 Plesk 中的一些晦涩的东西相比，我的客户可以使用它、理解它、监控它并验证我正在使用它。 我是个大粉丝。

我将整个平台拖入其兄弟目录的时间

我对专业工作场所还​​很陌生，并且一直是 Windows 人。 然而，我的新工作是在一家 Mac 商店，我很快就学会了爱上它的一切。 好吧，几乎所有东西。 我似乎在使用“魔术鼠标”时遇到了很多麻烦。 我有失去蓝牙连接的倾向，一旦重新连接，就会导致意外且经常令人恐惧的拖放操作。 不仅如此，我只是笨拙地掌握了一项新的精细运动技能。

回到过去，我们的 WordPress 开发流程仍然包括通过 FTP 部署到生产环境。 我花了整个工作日编写代码、聊天、回复电子邮件，通常是通过我的新魔术鼠标来回旋转，Cyber​​duck 在我的桌面上开放生产，这并不少见。 天哪，这听起来很糟糕！ 但事情就是这样。

有一天，我们的整个平台都消失了。 我们的系统管理员很快就认为这是某种 DDoS 或通常在他的水平上的东西。 至于我们这些开发人员，我们相信他的直觉，并认为他很快就会明白这一点。

几个小时过去了。 日子来了又去。 还在下。

到了第二天早上，一切都恢复了，我们的 CTO 轻轻地让我和她一起去会议室。 我们的系统管理员发现了问题。 他提取了 FTP 日志并观察到我的用户已将我们的整个平台移动到同级目录中。 也就是说， wp-content已经嵌套在wp-includes下。

我很沮丧，但我们的首席技术官对此非常满意。 她可以看出我通常是一个乐于助人且负责任的员工，但她要求我超越单纯的忏悔，并想出防止这种情况再次发生的方法。 我发现了两件非常有用的事情。

第一个是找到一个 CLI 命令来阻止 Cyber​​duck 允许远程到远程的文件移动。 这是一项很好的安全措施，我们立即将其作为公司政策采用。

第二个是我对通过 Git 进行部署产生了浓厚的兴趣。 最终，我最终编写了一个 WordPress 插件，将我们的 Bitbucket 版本控制融入到正常的wp-admin更新流程中。 从那时起，我们几乎没有理由让FTP 访问生产环境。 这个插件是我最喜欢的专业成就之一。 当然，对 Git 的喜爱是当今开发人员的先决条件。

我通过add_filter()删除所有前端内容的时间

在这一点上，我真的认为我的 WordPress 实践已经变得非常聪明了。 要求是在某个类别的帖子上附加一个“徽章”。 出于某种原因，我想到只有菜鸟才会为这样的模板文件添加另一个条件，因此我非常自豪地实现了以下过滤器：

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

看看这有什么问题吗？ 我在分期中快速对其进行了测试，以确认必要的帖子获得了他们的徽章。 然后我部署了它并离开了一天的工作。 正如你可能猜到的那样，宇宙爆炸了。

具体来说，结果是没有徽章的帖子在前端渲染，根本没有内容！ 你能看出为什么吗？ 问题是我没有在我的警戒状态下返回$content ，而是返回false 。 但这里确实有很多层错误。

为什么我只满足于测试帖子收到徽章？ 为什么我没有同时测试其他帖子是否安然无恙？ 为什么我这么晚才部署到生产环境？ 为什么我们的质量控制完全由我点击一下然后刷新页面组成？

所有这些问题的答案都可以概括为成熟度。 在我们开始投资于视觉回归测试和单元测试之类的东西之前，只需要一段时间就可以厌倦犯这些错误。 这个特殊的错误是数百人中的一根稻草，最终压垮了骆驼，并导致我对 phpUnit 和 xDebug 非常投入。 反过来，这些工具教会了我编写可测试的代码，这可能比测试本身防止了更多的错误。

在无限循环中我除以零的时间

客户的请求是重新格式化 WordPress 博客文章署名，以便日期显示为“XYZ 前”而不是“2011 年 11 月 10 日”。 我不完全确定如何实现这一点，但我知道这是一种似乎越来越受欢迎的日期格式，事实上，Google 博士很快就为我提供了一个片段。 它适用于我的本地！ 它有很多数学，特别是很多除法。 我不确定它为什么会起作用——有很多嵌套循环、余数、舍入等等。 但它在 Google 上并且似乎可以工作，我很高兴将它部署到生产环境中。

大约 30 分钟后，我从我们的系统管理员那里得到了一个不友好的 Skype。 产量下降。 死在水里。 他问我最近是否一直在除以零，我不知道他可能指的是什么。 这就是发生的事情。

信不信由你，我发现的不可读的“在我的本地工作”片段，给定足够大的样本量，可能会出现一些异常行为。 提供了一些不幸的天、小时和分钟组合，Rube Goldberg 循环偶尔会尝试将一个数字除以零。 回忆一下高中数学：

在普通算术中，表达式没有任何意义，因为没有一个数乘以 0 会得到 a（假设 a ≠ 0），因此除以零是不确定的。 - 维基百科

那么这对计算机意味着什么呢？ 通常只是日志中的一条错误消息，但在我的情况下，情况更糟：数学错误干扰了我的循环逻辑，导致我的嵌套循环在没有完成的情况下运行——一个导致白屏死机的无限循环。 而且情况会变得更糟！ 因为循环的每次迭代都会写入一个除以零的错误，错误日志增长到惊人的比例并开始妨碍我们的文件系统。 这具有 DDoS 攻击的效果，尽管这是一种荒谬的自我造成的攻击。

这个错误的坏处是它关闭了一个高流量的网站。 这个错误的好处是它极大地改变了我的工作方式。 最重要的是，我为自己在不理解的情况下实施的意愿感到羞耻。 我发誓在不尽一切可能理解每一行的情况下，不再粘贴片段，甚至在必要时与片段作者跟进。

更重要的是，我发誓不再发布对新手开发人员可读性不高的代码。 我开始沉迷于 WordPress 编码标准、文本编辑器扩展、内联注释和文档块，甚至是制表符与空格，这是经典的成人仪式！ 总之，我决定更关心阅读代码的难易程度，而不是编写代码的难易程度。 这种对不理解粘贴的反抗使我对管理第三方依赖项产生了浓厚的专业兴趣，这个话题在随后的十年中为我提供了各种写作和演讲机会。

哦，关于这个错误的真正有趣的事情是什么？ WordPress 核心有一个单线解决方案。

我让一个项目失控直到每个人都厌倦的时间

我得到了一个非常吸引人的项目。 我将成为技术主管和 WordPress 开发工程师，我将有一名 Amazon AWS Lambda 开发人员和一名深入的 JavaScript 专家向我汇报。 这是我第一次有多个人向我报告，这是迄今为止我从事过的最复杂的项目。 甚至将其称为 WordPress 项目都非常轻描淡写，但 WordPress 是将整个事物结合在一起的粘合剂，因此我担任技术负责人是有道理的。

因为我的主要角色通常是严格的技术人员，而且因为我对极简主义有着浓厚的兴趣，所以我从来没有想过要实现像 Jira 或 Basecamp 这样的东西或任何真正的任务管理平台。 项目的第一次迭代进展顺利。 我们能够处理我们自己的单个组件，将客户规范文档作为我们的产品路线图，当我们需要将事物耦合在一起时，只需通过 Slack 相互 ping 通即可。

当我们开始向客户展示进展并实施他的反馈时，麻烦就开始了。 最初的三人团队立即感觉它已被提升到一个新的数量级：不清楚谁负责哪一点反馈，执行该反馈的状态如何，甚至谁在与谁交谈. 我们多次超出了 Gmail 对每个线程 100 条回复的限制！

事情开始变得不舒服。 我认为客户觉得他失去了对项目方向的控制，同样重要的是，他觉得他失去了对项目状态的了解。 我的亚马逊开发人员有一天提到，“我想知道我们是否应该使用 Trello。”

呵呵，我想。 三人团队需要这样的平台吗？ 同样，我通常倾向于使用更少的工具、更少的开销、更少的复杂性。 但是这个项目已经把我们都拖入了泥潭，那么尝试它有什么害处呢？

我梳理了我们所有的电子邮件、我们所有的规范文档、我们所有不同的评论线程，并将它们全部映射到 Trello 板上。 立即，该项目从其数字坟墓中复活，因为我们可以用更少的精神开销进行交流。 我们没有在我的电子邮件收件箱或大部分过时的规范文档中搜索文本，而是拥有可爱的板、列表和卡片。 很容易查看任何功能的状态、合并反馈和分配新任务。 感觉就像我们逐渐失明，慢慢地我们没有注意到它，然后突然又能看到了。

诚然，代码不是自己编写的，它仍然是一个非常具有挑战性的项目，我们仍然必须充分利用我们的技术技能。 但这就是重点：因为我们终于有了理解项目的基础设施，我们现在可以自由地应用我们的技术技能。

我很高兴地说，该项目的完成令客户完全满意。 如今，我认为 Trello 或 Jira 是两个或更多团队的实际要求。

勇往直前，从别人的错误中吸取教训

这是我在军队期间听到的最聪明的教导之一：“中尉犯中尉错误是可以的，上尉犯上尉错误是可以的。 不能让上尉犯中尉的错误，或者让中尉犯私人错误。”

换句话说，对于你当前的责任水平来说，犯一些理所当然的常见错误是可以的。 更重要的是你如何从中成长。

我希望我们作为开发人员在犯错时学会同情他人，就像希望其他人一直与我们一样。 当我犯错时，我希望保持好奇心和责任感，以便我继续创新。 我希望始终被一个鼓舞人心的 WordPress 专家社区所包围——我可以从他们的错误中吸取教训并避免自己犯错。 最重要的是，我希望其他人可以从我的经验中学习，比如我在这里分享的 WordPress 错误。