昨晚我幾乎睡不著。 進入藍色的月亮後，我有一個想嘗試的想法。 雖然我作為作家的日常工作意味著我花了更少的時間通過嚴格的試驗和構建插件和主題的錯誤來破壞網站，但WordPress困擾了我一些問題，而這種問題使我無法打rest於寧靜而和平的夢想。
上周，古騰堡8.9 放下實驗標記 從其基於塊的窗口小部件系統中。 總體而言，這是該功能的可靠首次發布，該功能將於今年12月在WordPress 5.6中發布。 但是，最大的問題集中在主題作者如何能夠以傳統方式設置小部件樣式。 由於實際的窗口小部件正在逐步淘汰並被替換為塊，因此主題作者將不再有權訪問標準窗口小部件和窗口小部件標題類。 這是有問題的，因為沒有可預測的方式來設置特定邊欄的所有小部件的樣式以使其看起來相同。
經典示例是盒裝小部件設計。 許多主題，例如流行 科利伯里，針對其側邊欄採用這種設計，如以下屏幕截圖所示。
Colibri主題右側欄中的盒裝小部件設計。
在當前狀態下，主題作者無法通過基於塊的窗口小部件系統創建這種側邊欄設計的可靠方法。 由於無法對用戶將要放到側邊欄中的任何內容的結構進行任何形式的控制，因此很容易觀察這種情況並認為主題設計者正在失去控制。
根據最近 GitHub票 和一個相關的 閑聊 從本周早些時候開始，至少就主題設計而言，古騰堡開發團隊似乎沒有打算在新舊控制項系統之間建立平價。
需要重複。 我是…的熱心支持者 交出這種最終控制權 給用戶。 但是，我們需要在幫助他們做出明智選擇之間取得平衡。
主題作者必須開始考慮這對他們的工作有何影響，並為側邊欄，小部件以及將來會受到全站點編輯影響的其他方面提出創造性的解決方案。
潛在的解決方案
昨晚讓我興奮的一件事是結合塊模式， 我最喜歡的功能之一，帶有小部件。 問題在於基於塊的窗口小部件系統當前不支持塊模式。 並且，直到與古騰堡的一位設計師馬克·烏蘭（Mark Uraine）進行了快速討論， GitHub票，這個想法似乎甚至沒有擺在桌面上。
對於主題作者而言，過去的傳統邊欄和窗口小部件系統僅是一種模式。 WordPress為主題開發人員提供了為整個窗口小部件和窗口小部件標題設置包裝HTML元素的功能。 這是一個僵化而僵化的系統，但它是一個可靠的標準。
基於塊的小部件則完全相反。 它們本質上是免費的，用戶可以在其中將任意內容放入「塊區域」。
當我們將模式的結構與側邊欄內部的塊的靈活性結合在一起時，會發生什麼？
這個想法使我在不安的夜晚後的今天清晨起床並躺在電腦屏幕後面。 這是一個簡單的概念。 主題作者可以向最終用戶提供「小部件」模式。 這將為用戶提供主題作者認為最佳的選擇和打造自己的道路（兩全其美）之間的選擇。
重新創建盒裝「窗口小部件」模式的簡單示例。
並且，這裡正是真正發揮區塊系統魅力的地方。主題作者可以創建任意數量的模式。 這為用戶提供了更多選擇。
無論Gutenberg插件當前是否支持基於塊的小部件系統的模式，該想法都易於測試。 在新窗口小部件屏幕的側欄中，我只需要使用窗口小部件類添加一個新的Group塊。 然後，我添加了帶有widget__title類的H3 Heading塊。 除非主題作者希望直接針對它們，否則在模式的上下文中這些類甚至可能是不必要的。 在自定義類之外，我向Group塊添加了簡單的背景，並更改了標題的文本顏色。 我還在用戶自定義內容所在的位置插入了一個空段。
之後，只需對各個模塊進行測試即可。
小部件塊編輯器中的偽塊模式。
我很想知道主題作者和古騰堡團隊對此想法的看法。 我認為它在緩解傳統小部件和基於塊的小部件之間的過渡痛苦的同時具有一定的優勢。
我看到的最大問題是可發現性方面。 如果主題作者走這條路，最終用戶是否會知道這些「小部件/阻止模式」存在？
像這樣：
喜歡載入中……