如果這是現代 WordPress 主題開發，請註冊

一段時間以來，我的腦海中一直縈繞著一個街區主題的想法。 幾個月來，我一直在考慮建立一個單頁的個人資料/卡片主題，我終於坐下來在周末投入工作。 在某種程度上，我只是想這樣做是為了好玩。 然而，我的另一部分想從開發人員的角度看看塊主題是如何發展的。

這個主題的靈感來自其他一些人和項目。 Kjell Reigstad 從 2020 年 10 月開始的兩欄著陸頁實驗首先觸發了它。 最近向調酒師詢問關於緊湊和舒適主題的問題讓我的創意再次湧現。 然而，看到主題團隊批准了Carolina Nymark 的類似塊主題Miniblock OOAK，這意味著規則現在已經足夠寬鬆，可能會將類似的東西推向世界。

問題之一是基於塊的主題曾經讓我很生氣。 去年，我在寶貴的空閒時間里花了幾個月的時間構建一個新項目，但幾週後 Gutenberg 插件更新就抹殺了我的進度。 我知道事情可能會隨著 alpha 級軟件的不穩定基礎而改變，但它仍然在萎縮。 不用說，我永遠找不到重新拾起它的動力。

就在幾天前，有了 WordPress 5.9 和更穩定的塊主題系統，是時候再試一次了。

我想深入學習塊主題。 我能做到這一點的唯一方法就是回到起點。 我需要讓自己重新熟悉那些普通的 HTML、CSS 和 PHP 的基礎元素。 忘記我認為我知道的建立在現代網絡之上的一切。 我需要再次成為菜鳥。

從技術上講，要忘記我所知道的一切而不引起某種健忘是不可能的。 然而，也許——只是也許——我可以回到網絡的組成部分。

我可以在我的/node_modules文件夾中沒有跨越 900 多個項目的複雜依賴網絡來啟動 WordPress 主題嗎？

我可以在不通過 Composer 盡職盡責地引入我的基本 PHP 腳本的情況下創建一些東西嗎？

我可以，你知道，只是建立一個 WordPress 主題嗎？

第一步是在門口檢查我的自我。 當我擱置多年的現代工具和圍繞它們構建的工作流程時，我發現這是一個非常簡單的主題系統，它向 WordPress 的根源致敬，但足夠靈活，可以擴展高級構建。

這並不是說一路上沒有打嗝，但我們聽到的足夠多。 另外，我認為編程/開發是解決問題的藝術。

我度過了一個不安的周末。 從周五到週六晚上，我睡了四個，也許五個小時。 也許我有太多的項目和事情要做，以至於我無法將它們排除在外。 無論如何，我在周日早上 3:30 醒來，雖然很累，但無法抓住那些急需的 Z。 所以，我破解了我的代碼編輯器並創建了一個新的主題項目。

不到一個小時，它就開始工作了。 它的形狀足夠好，可以在 Twitter 上與朋友一分為二分享。

以下是當前主頁的截圖。 從技術上講，它是唯一的頁面。 自從我推送我的第一個提交以來，我已經做了一些修改。

這是一個名為“反射”的塊模式。 湖面上倒影的山峰來自 WordPress Photos，由 Anne McCarthy 拍攝。 用於背景的漸變也是圖像顏色的反射，我認為這是一種很好的觸感。

該主題包括其他幾種模式。 目標是允許用戶為他們的個人資料卡選擇他們最喜歡的，自定義內容並保存。 十分簡單。 我遇到了這個問題，我在帖子的末尾深入探討了這個問題。 在大多數情況下，一切都很順利。

我從經驗中學到的

使用塊創建 WordPress 主題很容易。 大多數事情都是按照一套標準的規則來組織和運作的。 模板在這裡。 零件去那裡。 在那邊插入您的設置。 我們可能會在未來的 WordPress 版本中看到更多的結構。

我只使用我的代碼編輯器和本地 WordPress 安裝從頭開始構建主題。 沒有節點模塊。 沒有 PHP 庫。 沒有任何構建設置。

在這個項目完成之前，我可能會使用這些東西。 一些工具只是使開發更容易。 但是，不需要它們或深入研究更複雜的 PHP API 降低了進入門檻。

感覺就像我回到了 2000 年代中期，只是有了一個更好的系統來處理所有復雜的部分。 這一次，我幾乎可以完全專注於設計。

底層系統存在很多問題。 編輯器中仍然存在諸如圍繞寬對齊塊的額外包裝元素之類的怪事。 而且，有幾個塊需要更新——我在看你的 File 塊，因為它沒有重用現有的 Button 塊。

基本上，有怪癖。 作為一個主題，你學會與他們一起工作，等待上游修復，或者冒險嘗試尋找解決方法。

我對分享未完成的工作猶豫不決，但我也應該拿出證據。 有興趣的人可以在本文發表之日查看 GitHub 存儲庫，至少在我對它做任何太瘋狂的事情之前。

一些主題作者可能看了我的項目，並認為這是一個太簡單的例子。 但是，我可以輕鬆地將有關它的所有內容應用於成熟的主題。 無論大小，標準都是一樣的。

也許我們應該開始重新思考什麼是主題。 基於塊的主題如此年輕，我們都應該做一些實驗。

錯失的機會

在這一點上我會稍微有點技術性，因為它對於解釋錯失的機會以獲得全面的用戶體驗至關重要。 站點編輯器位於易於為更高級用戶構建的位置。 模式有助於彌合那些技術含量較低的人的差距，但它們還不夠。

想想網頁的主要部分。 頁眉、頁腳、側邊欄、內容，甚至是其中的子部分。 作為用戶，您如何用不同的內容模式替換已經在屏幕上的整個內容區域設計？

您可以刪除那裡的那個並插入一個新模式。 但是，刪除和插入頁面的部分是高風險的操作。

如果您要更改的區域是模板部件，您可以將一個替換為另一個。 那是假設主題作者已經為該區域註冊了任何內容。 這是一種低風險操作，也是站點編輯器的最佳功能之一。

例如，這裡是二十二十二註冊的標題模板，它們出現在“替換”工具欄菜單項下：

然而，這並不是主題的全部標題模式——它總共有 18 個。 我想大多數最終用戶永遠不會發現它們。

為特定模板零件創建模式的缺點之一是最終用戶無法用新模式替換或轉換零件批發。

主題作者可以通過將模式代碼複製到模板部分來重複他們的工作，假設它沒有混入 PHP。或者，他們可以創建這些部分並通過 Pattern 塊拉入相關的模式：

 <!-- wp:pattern { "slug":"namespace/slug" } -->

這種方法的問題是站點編輯器沒有在“替換”下拉列表中顯示模式內容（我剛剛發現了一個錯誤嗎？ ）：

解決方案應該很簡單。 為模板部件註冊的模式應該可以通過 UI 互換。 或者，使用 Pattern 塊的部件應該正確顯示在“替換”下拉列表中。