自已故的亞歷克斯·米爾斯在 WordPress Trac 上打開一張名為 插件依賴（又一個插件依賴票）. 它不是最古老的類似功能請求，但它仍然是開放的。 大多數前輩都被貼上了「wontfix」的標籤，這通常是好主意和壞主意棺材裡的最後一顆釘子。
票證的目標是創建一個系統，允許一個插件需要一個或多個其他插件才能運行。 依賴關係在編程世界中並不是什麼新鮮事。 Composer 是標準的 PHP 包管理器，距離 10 歲還有兩周。 在 JavaScript 端，npm 已經存在 12 年了，而 WordPress 已經在核心代碼中大量採用了它。
但是，這些是開發人員工具。 WordPress 是為用戶構建的，解決插件依賴關係需要在用戶界面中進行。
米爾斯在罰單中寫道：
自從我們查看插件依賴項以來已經有幾年了，這似乎仍然是人們真正非常想要的功能，尤其是對於本身不是插件的共享功能。 例如，一個 PHP 庫在核心中不夠流行，但足夠流行以捆綁在多個插件中。
該聲明在今天可能更加相關。 在過去的十年中，許多插件已經發展了自己的附加插件生態系統。 確保安裝依賴項的責任通常落在最終用戶的肩上。 開發人員已經提出了內部解決方案來減輕這種負擔，並且 TGM 插件激活 腳本已成為事實上的標準。
在任何插件項目中幾乎都需要依賴依賴項，至少在一般的構建工具設置中發揮了作用。 可以肯定地說，與 WordPress 形成時期相比，如今更多的 WordPress 插件開發人員更願意在需要第三方代碼的環境中進行編碼。
對於一個一直在努力實現自身現代化的平台來說，解決插件依賴就像乘坐火箭飛船前往狂野西部。
這個想法在 WordPress 世界中並非沒有先例。 雖然這是一個不太複雜的情況，但 WordPress 在從目錄安裝子主題時會自動下載並安裝父主題。
插件依賴系統的許多參數都屬於附加方案。 最明顯的用例是 WooCommerce 以及為它編寫的數十個擴展。
然而，另一個可以深入了解開發人員如何在 WordPress 之上構建的場景是包含框架和庫。 現在，插件作者必須在他們的項目中捆綁第三方代碼，並確保如果已經捆綁在一個完全獨立的插件中，它不會被載入。
代碼重用是編程的基石之一。 目前，沒有捆綁代碼庫或腳本的標準。 而且， WordPress 插件目錄不允許使用新框架 和類似的庫。
為了透明起見，我至少有十幾個項目屬於這個類別，其他人可以使用的軟體包。 所以，我至少在遊戲中有一些皮膚，我相信很多其他人都在同一條船上。
WordPress GitHub 存儲庫中有兩個針對插件依賴系統的拉取請求。 還有一個 Google Docs 文件 詳細概述了這兩個提案.
每個都要求開發人員通過插件頭定義依賴項。 以下是需要 WooCommerce 和 Gutenberg 的示例：
兩種方法都是相似的。 從用戶的角度來看，他們會：
- 向管理員顯示需要安裝依賴項的通知。
- 不允許刪除或停用插件而不刪除或停用其所需的插件。
- 在管理插件屏幕上的插件卡中輸出一條消息。
第一個實現 由 Ari Stathopoulos 撰寫。 它創建了一個「激活隊列」，只有在用戶激活了所需的插件後才會激活插件。 它還允許用戶取消激活請求。
激活依賴項的通知。
Andy Fragen 的解決方案 在插件管理屏幕上創建一個新的「依賴項」選項卡。 這種方法會自動停用任何具有未滿足依賴項的插件，並通過管理員通知通知用戶。
他還發布了 插件依賴項選項卡 在 GitHub 上單獨進行項目。
插件依賴項選項卡。
兩者仍然存在一些實際問題。 即，當支持的版本之間發生衝突時會發生什麼？ 當前的提議讓插件不破壞用戶端的任何東西。
這可能是所有這一切中最不鼓舞人心的部分。 但是，這可能是最實用的路線。 另外，WordPress 沒有解決其當前狂野西部系統中的版本衝突。
依賴解決方案也可能是更多代碼現代化的機會。 歡迎看到更多開發人員採用介面（合同）等功能。 考慮到依賴項進行編碼意味著以不同於任何給定項目是獨立插件時的方式思考架構問題。