昨天，Alex Shiels 發布更新 到 建議的準則 用於WordPress阻止目錄。 該文檔添加了八個規則，供插件作者計劃將一次性塊添加到目錄中時遵循。 該準則是對現有插件目錄準則的附加要求。
相對於 原始建議，總體情緒沒有變化。 Shiels感謝社區開發人員對原始指南的反饋，但沒有詳細說明由此而發生的變化。
主要準則是對磚塊的常規要求。 開發人員需要一個block.json文件。 他們應該適當地命名東西。 插件應僅包含一個塊。 插件只能觸摸塊編輯器。 一旦激活，塊應無縫運行。
對於某些開發人員而言，其餘準則肯定會令人失望或爭論點。
仍不允許獲利
最大的 對準則的反饋 我們在小酒館（Tavern）收到了這封郵件，這實際上是對塊開發商的商業利益的全面禁止。 區塊仍然無法加入付費服務或在管理員內發布廣告。 這種限制顯然將使許多可能一直希望將阻止目錄作為潛在獲利途徑的企業拒之門外。 現在，那些有利他主義興趣的人將需要建立一次性的街區，僅僅出於他們內心的善良就回饋社區。
儘管這樣做並沒有天生的錯誤，但對於主要致力於將食物擺在桌面上的開發人員而言，它並沒有吸引力。 具有回饋資源的業餘愛好者和大型企業將非常適合在目錄中添加塊。 但是，這將使很多開發人員暫停，因為它不太可能獲得良好的投資回報。 相反，這些開發人員更有可能使用其常規追加銷售方法將其塊提交到常規插件目錄。 這隻會使最終用戶更難發現區塊。
這是一個錯失良機，無法構建一個全面的系統，對需要謀生的用戶和開發人員都是公平的。 無論是通過插件標籤系統還是關於獲利的特定準則，我們都可以構建使每個人都有些高興和瘋狂的東西，這種折衷融合了良好的用戶界面和體驗。
似乎沒有提案。 一月，盧克·卡比斯（Luke Carbis）寫了一篇詳細的 WordPress如何提供中間立場 即將發布的區塊目錄在可持續性（業務模型）和可訪問性（免費選項）之間進行選擇。 他擔心的是，由於完全免費的模型是不可持續的，因此在幾年之內，塊目錄中將充滿不更新的塊。 他的建議是一個基於徽章的系統，該系統可以讓用戶知道某個區塊是否包含廣告，是否使用了免費增值模式或是否需要登錄第三方服務。
當前的準則不是一成不變的。 這是塊目錄的第一個版本。 隨著目錄的不斷增長，團隊可以更改內容並非毫無疑問。
不愛伺服器端塊
塊目錄準則仍然非常適合靜態塊。 PHP必須保持最少，並且主要用於載入任何必要的腳本和樣式表。 目前伺服器端塊並沒有引起太多關注，這可能是軟體的局限性。
看到一些將伺服器端塊包含在塊目錄中的方法，將是很棒的。 例如，一個麵包屑塊將需要嚴重依賴PHP來呈現其輸出。 它是動態的而不是靜態的。 直到仍然需要幾個月的時間才能在WordPress中進行全站點編輯之前，此特定區域才有用。 但是，我很想將我的舊麵包屑插件變成一個塊。 看到它在塊目錄中列出會很整潔。
還有無數其他情況。 發布列表，產品網格以及從外部API提取的數據都是一次性模塊的良好用例。
不允許依賴
鑒於WordPress的工作方式，有必要禁止對其他插件的依賴以使任何特定功能塊起作用。 這是一個古老的局限性，再次引起了人們的注意。 每個其他現代框架都使用某種依賴管理來解決此問題。
阻止目錄可能進一步加劇該問題。 因為來自此目錄的插件將是單個塊，所以這通常意味著開發人員在多個項目中使用相同的代碼位。 例如，最終用戶可以激活依賴於同一JavaScript庫的多個塊插件。 因為沒有100％的確定方式來確保僅載入該庫的一個實例，所以用戶可能在其站點上運行該庫的多個實例。 這不是一個新問題，但是較小的塊狀插件意味著用戶更有可能安裝更多插件。 這增加了遇到此問題的可能性。
如果插件作者可以在WordPress中使用某種基本的依賴管理，那麼它將解決很多問題。 多年來，開發人員已經創建了一些方法來最大程度地減少由於缺少此類系統而引起的問題。 但是，如果沒有遵循的標準，沒有什麼是萬無一失的。
這也使開發人員無法構建可以使整個開發社區受益的庫，腳本和工具。 每個人都在內部構建自己的東西，而block目錄則承諾會實現更多相同的東西。
像這樣：
喜歡載入中……