自從十多年前外掛和主題升級機制已包含在核心中以來，第三方開發人員就一直在尋求一種繞過系統的簡便方法。WordPress 5.8最終將根據此功能要求提供服務。
儘管長期以來就有可能對更新系統進行過濾，但是這樣做的方法比所需的更為複雜。他們還要求外掛本身在網站上處於啟用狀態。早就應該有一個簡單的標誌來啟用/禁用每個外掛的功能。
“實用程式是這是一個抽象的API，它允許兩件事，” Dion Hulse<在GitHub pull請求中寫道，該請求對程式碼進行了修補：
- 一個用於宣告URI /字串的外掛，如果設定了該字串，則WordPress.org更新API會忽略該外掛。
- 在站點上執行的程式碼可以使用標頭主機名/資料為外掛提供更新，以將其儲存在更新瞬態中，而不必跳過諸如覆蓋瞬態/經常檢查等麻煩。
WordPress 5.8將提供一個新的Update URI 外掛頭欄位。如果其值與https://wordpress.org/plugins/{$slug}/或之外的其他值匹配w.org/plugin/{$slug}，則WordPress不會嘗試對其進行更新。
除此之外，如果開發人員想要處理非WordPress.org外掛的更新，則可以推出自己的解決方案。這就是新update_plugins_{$hostname}過濾器起作用的地方。WordPress將解析包含在外掛Update URI頭中的URL，並使用主機名作為值。然後，開發人員可以參與其中，並做他們需要的任何事情。
具有由WordPress.org託管的副檔名的外掛作者將不必擔心新增此新標頭。外掛指南的規則＃8已經禁止通過第三方系統傳送可執行程式碼。以下小節將更具體地介紹這種情況：
從WordPress.org以外的伺服器提供更新或以其他方式安裝外掛，主題或附加元件
13個月前，6年前的一張ticket引發了一些討論。“當計劃的外掛自動更新執行時，我現在已經毫不客氣地從客戶端的網站上刪除了一個外掛，”使用使用者名稱apedog的投稿人寫道。“實際上，這是我第二次遇到我的外掛的命名衝突問題。在這兩種情況下，我都選擇了沒有先驗命名衝突的外掛名稱。但是，在稍後的某個時間，其他人也用相同的通用名稱編寫了一個外掛，並將其提交給wp.org儲存庫。從那時起，我的外掛無法正常工作。”
儘管刪除問題並不是WordPress的問題，但也許是保持對話進行所需的火花。
進行積極的討論並不總是表明某個功能獲得了綠燈。這也不意味著有人會編寫程式碼。許多這樣的工單已經進行了數月或數年的交談，直到最終失去生命和死亡。這張工單于2015年開放。但是，新功能有時更多地是關於時間安排，僅僅是純粹的隨機性，或者具有核心提交訪問許可權的開發人員僅能完成工作。
外掛主題工單已被接受並提交給WordPress。但是，仍然存在這樣一個問題它是否會成為主題。已有11年曆史的主題工單出現的表明，這種情況有可能發生。
評論留言