優化 WordPress 時學到的主要經驗教訓（為了客戶成功）
已發表: 2022-09-15你最後一次有云九時刻是什麼時候？
順利通過學校.. 或者你的女朋友/男朋友接受了你的提議？
兩週前我有一個雲九時刻！ 我在 WordCamp Mumbai 2017 上發表演講——印度最大的 WordCamp。
這個話題很貼近我的心，也是我每天都在處理的事情——為客戶成功優化 WordPress 的經驗教訓。
這是關於我在處理大型 WordPress 數據庫時遇到的問題以及我如何解決它們。
是什麼鼓勵我在孟買 WordCamp 演講？
開發 WordPress 插件是一次很棒的學習體驗。 你可以擴展一個極好的框架，專注於編寫解決客戶問題的代碼，並與優秀的團隊成員一起工作。
在 StoreApps，開發人員不僅編寫代碼，還支持客戶。 解決客戶的疑問給了我一些最大的教訓。
所以這就是我的日常，而且非常令人興奮。
但是你知道什麼對我來說更令人興奮嗎？ 使用大型數據庫並解決複雜的數據庫問題！
我們的插件被超過 35000 名用戶使用。 我已經看到了與大型 WooCommerce 商店和流行的 WordPress 網站合作的許多挑戰。
值得慶幸的是，我能夠解決這些挑戰並學到了很多東西。
但是等等，就像我一樣，會有數百名其他開發人員在使用 WordPress 和 WooCommerce 時面臨類似的問題。
所以我決定與其他人分享我的課程。
還有什麼比在印度最大的 WordCamp 演講機會更好的平台！
讓我徹夜難眠的三個問題（有解決方案和從中吸取的教訓）
最後，這是我正在談論的三個問題。 因此，讓我們一個一個地開始。
將頁面加載時間從 3 分鐘減少到毫秒……
問題
我遇到了智能優惠券插件的情況，其中在商店的關鍵頁面（即購物車、結帳和我的帳戶頁面）上顯示優惠券的簡單功能使結帳過程停滯不前。
Smart Coupons是一個插件，用於為 WooCommerce 商店批量創建和處理優惠券和禮券。
解決方案
現在，使用 WP Query 會導致多個 JOIN ，因為要顯示特定用戶的可用優惠券需要評估多個元條件。
因此，我沒有使用理想的數據庫查詢方式，即 WP Query，而是編寫了自定義 SQL 查詢。
此外，在自定義查詢中，我所做的是：
- 我沒有在單個 MySQL 查詢中檢查所有元條件，而是簡單地評估了第一個元條件
- 之後，我將逗號分隔的 post_ids（優惠券 ID）列表存儲在選項表中
- 然後，我通過評估每個其他元條件來簡單地映射減少相同的 post_id 集
我一直這樣做，直到我得到一組需要為特定用戶顯示的最終 post_id。
增強解決方案
這確實解決了頁面加載問題。 但是，按照我們朋友的建議，為了在毫秒內加載頁面，我不得不重新定義問題。
而不是顯示用戶有資格獲得的所有優惠券，
我對在購物車和結帳頁面上向用戶顯示的優惠券數量設置了限制。
超時錯誤如何成為我們插件最暢銷的功能？
問題
為了處理非常龐大的數據庫更新，我編寫了自定義查詢，因為使用核心 WordPress 功能可能會成為巨大的開銷。
示例：如果一個人必須將他/她商店中所有產品的價格降低 40%，那麼他們只需選擇“價格”、“降低 40%”並點擊更新按鈕。 使用我們的插件 Smart Manager 可以輕鬆實現這一點，該插件旨在使您的 WooCommerce 商店的批量更新更容易。
但是，每當有人嘗試一次更新 1k 個產品或整個商店時，批量更新過程就會開始停滯並給出超時錯誤。
最初我開始考慮優化查詢，但這並沒有幫助。
我的情況類似於武城的參賽者。 不管我怎麼努力，我總是掉進水里。
解決方案
據說有時您必須擺脫問題並鳥瞰問題才能找到確切的原因。
我做了同樣的事情並發現實際問題是
不是在查詢級別，而是在請求級別。
因此，我所做的不是單個請求進行所有更新，而是將相同的請求分解為多個連續的 AJAX 調用，進行小批量更新，從而完全消除了超時錯誤。
增強解決方案
現在，這種將單個請求分解為多個較小的 AJAX 請求的方法不僅解決了超時錯誤，而且改進了批量更新的 UX 。
現在，商店經理正在了解更新的進度，這只會增加他們對產品的信心。
此外，同樣的方法使 Smart Manager 能夠處理任何形狀和大小的 WooCommerce 商店的批量更新，並使 Smart Manager 成為 StoreApps 最暢銷的插件之一。
共享主機環境如何迫使我們重寫插件？
問題
對於任何報告插件來說，不僅準確而且快速地報告統計數據非常重要。 現在，獲取報告統計數據需要多個查詢，涉及加入 2 個主要 WordPress 表，即帖子和 postmeta。
正如上面已經看到的， JOIN 非常昂貴。
在 Smart Reporter（我們的 WooCommerce 報告解決方案）中，我們在單個頁面視圖中顯示了 20 個不同的報告統計信息，並且在頁面加載時也是如此。
解決方案
因此，我採用了與大多數報告解決方案相同的方法，即創建匯總表，即平面結構自定義表。
該表將包含插件所需的所有數據的摘要，從而消除連接的使用並縮短頁面加載時間。
此外，為了更新這些匯總表，我們使用了 WordPress 操作和過濾器。
課程總結
- 盡可能遵循最佳實踐
- 循環中沒有查詢
- 避免大型複雜連接
- 在 MySQL 級別做的比在 PHP 級別做的更多
- 深入代碼
- 摘要/自定義/臨時表
- 注意用戶體驗——響應能力、通知……
- 你在解決正確的問題嗎？
你的選擇是什麼？
我相信您已經處理了一些巨大的問題並找到了解決方案。 在下面的評論部分讓我們知道。 這對讀者來說真的很有價值。