我的五個最糟糕的 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 錯誤。