WordPress开发要避免这5个常见的陷阱

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

几年前，我听马特·穆伦维格说过一句话:大多数人都会重复他们的错误，更聪明的人会从他们的错误中学习，而最聪明的人则会从别人的错误中学习。我很喜欢这个，我再加上一个推论:每个人都会犯错误，谦虚的人会私下分享这些错误，最大胆的人会把它们写下来并在博客上发表!

但是以后还有时间思考。你读这篇文章是因为你想知道火车相撞的事，而我是工程师。没有更多的序言，和我一起回顾一下我作为一个WordPress开发者所犯的五个最尴尬的错误。

那时我刚从CraigsList网站上一个非常不起眼的编码工作中毕业，在一个真正的广告公司工作。我已经到了!在沙发以外的地方工作，穿着睡衣以外的衣服，这让我很紧张。但即便如此，我还是知道WordPress做错了还是对的，而且我发现吹嘘WordPress的最佳实践是一件很愉快的事，就像从来没有“侵入核心”一样。

我在这个机构的第一项wordpress开发任务是恢复一个停滞的项目——对我当时的技能来说，这是一个相当复杂的项目。它涉及到WordPress注册和登录流程的大量定制。前一位开发人员通过简单地编辑corewp-loginfile就取得了显著的进展。

我知道这是不可持续的，所以我的第一件事就是安装一个备份/恢复插件，用一个新下载的版本替换WordPress核心。我很有信心，到目前为止，在这个项目中没有任何令人印象深刻的东西被执行，而且我可以通过过滤器来模仿现有的特性集。

在那个时候，无论我是否具备编程能力，很快就变得无关紧要了，因为我的新雇主非常生气。她不理解“hacking core”的意义，而我也不够成熟，无法用一种容易理解的方式来解释。我向她保证，我可以通过我安装的备份/恢复插件来恢复，这让她的额头暂时凉了下来。

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

那个插件，就像命运所希望的那样，只备份了wp-contentfolder。不管核心文件中的WordPress hack是什么，都永远消失了。我还记得我给她的电子邮件(那时她早已把我赶回了家里的办公室):

我真的准备好了通过过滤器和动作来完成她想要的功能设置，但是她不听。她当场就把我解雇了，还威胁说要告我，而且她连我两周辛苦工作的工钱都没有付。我感到很丢脸。

[阅读:这是每个开发人员应该知道的关于设计的东西]

从这次经历中，我可以学到很多东西(现在很明显了)。一个普遍的教训是，只有经过演练和确认，备份才算备份，这是一个很好的教训。但更让我印象深刻的是关于如何在WordPress中进行备份的具体教训——尤其是在WordPress核心中。

我已经学会了真正珍惜像WP-Engine这样具有健壮备份/恢复系统的托管环境。许多精品主机都有各种命令行工具和其他针对开发人员的用于执行备份的特性，但WP-Engine是我的最爱。它非常快，除非你有一个非常大的网络。UI很简单。所有知道如何使用WordPress的人都可以使用它。即。与一些可能更快的CLI方法或隐藏在Plesk中的一些晦涩的东西相比，我的客户可以使用它、理解它、监视它并验证我正在使用它。我是你的超级粉丝。

当时我还不太熟悉专业的工作环境，而且一直都是Windows操作系统的忠实用户。然而，我的新工作是在一家Mac商店，我很快就爱上了它的一切。嗯,几乎一切。我似乎在使用“魔法鼠标”时遇到了很多麻烦。“我有可能会失去蓝牙连接，导致在重新连接后出现意外的拖放操作。不仅如此，我只是对一项新的精细的运动技能笨手笨脚。

现在，我们的WordPress开发流程仍然包括通过FTP部署到产品中。对我来说，花上整个工作日来写代码、聊天、回复电子邮件、通过我的新魔法鼠标来来回回的情况并不少见，而Cyberduck则在我的桌面上开放生产。天哪，这听起来糟透了!但事情就是这样。

有一天我们的整个平台都不见了。我们的系统管理员很快就假设它是某种DDoS，或者通常在他的级别上的东西。至于我们开发人员，我们相信他的直觉，并认为他很快就会明白的。

几个小时过去了。这一天来了又去。仍然下降。

第二天早上，一切都恢复了，我们的首席技术官温柔地邀请我去会议室和她一起开会。我们的系统管理员已经发现了问题。他拉出FTP日志，发现我的用户将我们的整个平台移动到一个兄弟目录中。也就是说，wp-contenthad嵌套在wp-include之下。

我很沮丧，但我们的CTO很棒。她可以看出，我基本上是一个乐于助人、负责任的员工，但她要求我不仅仅是悔悟，还要想办法防止这种情况再次发生。我发现了两件非常有用的事情。

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

其次，我对通过Git进行部署非常感兴趣。最后，我编写了一个WordPress插件，将Bitbucket版本编入正常的wp-adminupdate流程中。从那时起，我们几乎没有任何理由不去接触生产。这个插件是我最喜欢的专业成就之一。当然，对Git的亲和力是当今开发人员的先决条件。

到目前为止，我真的认为我已经很聪明地使用了WordPress。该请求是在某一类别的文章上附加一个“徽章”。出于某种原因，我想到只有新手才会在模板文件中添加这样的条件，所以我很自豪地实现了以下过滤器:

这有什么不对吗?我在阶段测试中快速测试了它，以确认必要的帖子获得了他们的徽章。然后我部署了它，把工作留给了今天。你可能猜到了，宇宙爆炸了。

具体来说，结果就是没有徽章的帖子会被渲染到没有任何内容的前端!你知道为什么吗?问题是，我没有返回$contentin我的保护条件，而是返回false。但这里确实有很多层次的错误。

为什么我只测试帖子是否收到了徽章?为什么我没有测试其他帖子是否完好无损?为什么我这么晚才部署到生产部门?为什么我们的质量控制完全是由我点击和刷新页面组成的呢?

所有这些问题的答案可以总结为成熟。在我们开始投资于诸如视觉回归测试和单元测试之类的东西之前，只是需要一段时间来厌倦犯这种类型的错误。这个特殊的错误是数百个错误中的一根稻草，最终压断了骆驼的脊背，使我对inphpUnit和xDebug投入了很多。反过来，这些工具教会了我如何编写可测试代码，这可能比测试本身防止了更多的bug。

客户请求重新格式化WordPress博客的文章，这样日期就会变成“XYZ前”，而不是“2011年11月10日”。我不太确定如何做到这一点，但我意识到这是一种越来越流行的日期格式，谷歌博士很快就给了我一个片段。它在我的本地成功了!里面有很多数学，特别是除法。我不太清楚它为什么能工作——有很多嵌套的循环、余数、四舍五入等等。但它是在谷歌上，它似乎工作，我很高兴部署到生产。

大约30分钟后，我收到了系统管理员发来的不友好的Skype。生产下降。死在水里。他问我最近是不是除以了0，我不知道他指的是什么。这是发生了什么事。

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

在普通算术中，该表达式没有意义，因为没有数乘以0得到a(假设a≠0)，因此除0没有定义。维基百科

那么这对计算机意味着什么呢?通常日志中只有一条错误消息，但在我的例子中，情况更糟:数学错误干扰了循环逻辑，导致嵌套循环未完成就运行——一个无限循环导致白屏死机。更糟的是!由于循环的每次迭代都编写一个除以0的错误，因此错误日志增长到不可思议的比例，并开始妨碍我们的文件系统。这产生了DDoS攻击的效果，尽管这是一种荒唐的自找的攻击。

这个错误的坏处是，它导致一个高流量的网站瘫痪。这个错误的好处是，它极大地改变了我的工作方式。最令我羞愧的是，我愿意在没有理解的情况下实施。我发誓再也不会在没有尽一切努力理解每一行的情况下粘贴代码片段，甚至在必要时还会跟踪代码片段的作者。

更重要的是，我发誓再也不会发布对新手开发人员可读性不高的代码。我开始着迷于WordPress的编码标准、文本编辑器扩展、内联评论和文档块，甚至制表符对空格，那经典的通过程序的方式!总之，我决定更关心读代码有多容易，而不是写代码有多容易。这种对没有理解的粘贴的反叛使我对管理第三方依赖产生了浓厚的专业兴趣，这个主题在接下来的十年里为我提供了各种写作和演讲机会。

我完成了一个非常吸引人的项目。我将是技术主管和WordPress开发工程师，我将有一个亚马逊AWS Lambda开发人员和一个在JavaScript方面的专家向我报告。这是我第一次有多人向我汇报工作，也是迄今为止我参与过的最复杂的项目。即使把它称为一个WordPress项目也大大低估了它的重要性，但是WordPress是将整个项目结合在一起的粘合剂，所以我作为技术领导者是很有意义的。

因为我的主要角色是严格意义上的技术人员，也因为我喜欢极简主义，我从来没有想过实现像Jira或Basecamp或任何真正的任务管理平台。项目的第一次迭代进展得相当顺利。我们能够开发自己的独立组件，将客户规范文档作为产品路线图，并且在需要将东西组合在一起时通过Slack相互联系。

当我们开始向客户展示进展并执行他的反馈时，问题就出现了。刚开始的这个三人团队立刻感觉自己被带到了一个新的数量级:不清楚谁负责哪一点反馈，不清楚执行反馈的状态，甚至不清楚谁在和谁交谈。我们多次超过了Gmail的限制，每个线程回复100个!

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

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

我梳理了我们所有的电子邮件，所有的规范文档，所有不同的评论线程，并把它们都映射到Trello板上。很快，这个项目就从它的数字坟墓中复活了，因为我们可以用更少的脑力开销进行交流。我们没有在我的电子邮件收件箱或过时的规范文档中搜索文本，而是使用了可爱的板、列表和卡片。可以很容易地看到任何特性的状态、包含反馈和分配新任务。感觉就像我们渐渐失明了，速度如此之慢以至于我们都没有注意到，然后突然又能看见了。

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

我很高兴地说，那个项目的完成让客户非常满意。现在，我认为Trello或Jira是两个或更多团队的实际需求。

这是我在军队里听到的最聪明的事情之一:“中尉犯中尉的错误没关系，上尉犯上尉的错误也没关系。”上尉犯中尉的错误，或者中尉犯私人的错误，都是不对的。”

换句话说，就你目前的责任水平而言，犯一些常见的错误是理所当然的。更重要的是你如何从中成长。

我希望我们作为开发人员，能够在别人犯错时学会同情他们，希望别人也能这样对待我们。我希望在我犯错误的时候保持好奇心和责任感，这样我就可以继续创新。我希望身边总是有一群鼓舞人心的wordpress专家，我可以从他们的错误中吸取教训，避免犯同样的错误。最重要的是，我希望其他人能从我的经验中学习，比如我在这里分享的WordPress错误。