gutenberging

Gutenberg，WordPress的新編輯器，發布已逾一年。如今，圍繞它的爭議似乎已平息。充足的時間讓其用戶體驗和易用性得到提升，人們也更清晰地看到了它的潛力。我們無法回頭。

像Haris Zulfiqar這樣的作者表示看好它，而Nick Hamze則認為區塊是下一代編輯器的方向。

雖然我認為它仍然存在一些不足（例如，為什麼不能在塊引用中添加列表？為什麼不能為鏈接添加類？為什麼不能用方向鍵瀏覽塊選擇器？），但我總體上非常喜歡它。而且不僅僅是概念上的喜歡。我將CSS-Tricks遷移到Gutenberg列為2020年的目標之一，並在1月份立即著手實施。

已初嘗甜頭

由於我們已將新聞稿創作體驗轉換為新編輯器，因此我們已經積累了一些Gutenberg的使用經驗。我們的新聞稿是CSS-Tricks上的自定義文章類型，發佈在公共URL上，擁有自定義RSS feed，並由MailChimp抓取和讀取該RSS feed。

我們可以通過Gutenberg Ramp插件輕鬆為新聞稿啟用Gutenberg。這對於自定義文章類型和具有單個ID的文章非常有效，但我希望僅為新內容啟用Gutenberg。最終我修改了該插件。如果您認為這是一個好主意，可以查看我的pull request。

這對我來說很重要，因為我們有數万篇使用舊編輯器創建的舊文章，即使Gutenberg不會在打開它們進行編輯時損壞它們，但它為這些文章提供的編輯體驗也不如“經典”編輯器（例如，我們有用於特殊代碼塊等的特殊按鈕）。

處理舊內容

如果Gutenberg能夠在打開舊文章時將其轉換為合適的區塊，那就太好了，但這目前看來像是一個夢想。這意味著它必須解析HTML，識別哪些塊看起來像區塊，識別哪個區塊最合適，包括我們最重要的自定義區塊，並且以一種不會出錯的方式準確地做到這一點。

目前，舊內容仍然使用舊編輯器。甚至沒有一種簡單的方法可以從編輯器中為單個文章啟用Gutenberg。 （我可以將值硬編碼到Gutenberg Ramp的使用中，但這有點繁瑣。）

我有點擔心舊編輯器會嚴重惡化。例如，我開始著手這項工作的一個主要原因是，在這個網站上，舊編輯器會隨機滾動到頁面底部。我完全不明白為什麼，但這讓我覺得創作非常痛苦。只是一個微不足道的小bug，卻讓我想要使用正在積極開發的編輯器體驗。

但即使舊編輯器真的變得很糟糕，為所有內容啟用Gutenberg也不是那麼糟糕。所有舊內容都將位於一個大型“經典”塊中，一切都會正常。

總之——它運行良好！

為新文章啟用Gutenberg本身就是一個不小的挑戰，但我們已經啟用它了，並且我們正在使用它創建所有新內容。我在這裡只是代表我自己發言，但我太喜歡它了。它對內容創作來說是一個巨大的升級，我有點痴迷於它。團隊也很高興。

創建自定義塊

看看我們這個花哨的文本塊：

你可能會想，哦，酷，一個創建自定義塊的機會。事實上，我們甚至在一個大型系列中介紹了學習和製作Gutenberg塊的方法。但這提出了一個非常相關的問題：何時不構建塊。這個塊唯一獨特之處在於它有一個特殊的類名，我們的CSS使用它來為該塊設置樣式。僅此而已。添加類名是每個塊的內置功能，因此這裡不需要自定義塊。

事實上，我們可以更進一步，創建一個具有此確切類的文本塊作為“可重複使用的塊” ，這樣我們甚至不必記住或輸入該類名。在我創建了一個具有此類的文本塊後，我從kebab菜單中選擇“轉換為可重複使用的塊”，現在它將永久保存為可重複使用的塊。

我們現在已經將其用於其他一些事情，例如我們的“文章系列”塊（一個帶有特殊<div>-with-a-class包裝器的<code><ul></ul>和<ol></ol>）和腳註塊等等。但我們確實也需要一些自定義塊，為此我使用了create-guten-block來創建一個特殊的插件¹來創建它們。我認為對我們來說非常重要的一個塊是代碼塊。已經有一個用於代碼塊的原生塊。它基本上將代碼放在一個

<code>标签中，并且来自Gutenberg的内容默认情况下已经转义。</code>我們花哨的代碼塊允許我們選擇它的語言，突出顯示某些行，並提供自定義標籤。這在我們舊的編輯器中通過HTML屬性都是可能的，因此這個塊只是在所有這些之上提供了一個不錯的UI。



<p>該塊非常特定於CSS-Tricks，因此開源它並沒有多大意義。但我創建的另一個塊是開源的，那就是CodePen嵌入塊。我在CodePen博客上寫過關於它的事情。</p>



<p>它允許你粘貼一個CodePen URL，它會轉換成一個CodePen嵌入。 oEmbed默認情況下已經這樣做了，但是使用這個插件，你可以控制所有內容，例如高度、主題和默認選項卡。</p>



<p>在創作時實際看到嵌入的Pens非常棒！</p>



<h3 id="未解決的挑戰">未解決的挑戰</h3>



<p>目前最大的挑戰是處理圖像。在舊的編輯器中，我們集成了一個非常非常花哨的Cloudinary設置。圖像會自動上傳到Cloudinary，斷點會以編程方式確定，會創建多個尺寸，會創建響應式圖像語法，最終出現在HTML中的是具有Cloudinary託管圖像的完美的響應式圖像語法。這使我們能夠利用CDN並以最佳格式提供圖像。</p>



<p>使用Gutenberg創建的文章中沒有發生這種情況。 ?</p>



<p>我需要找到或開發一個新的系統，該系統可以在網站的任何地方很好地處理圖像，並且理想情況下使用更易於維護的非定制系統。我可能會使用Cloudinary來解決這個問題，我可能會嘗試其他服務，我可能會讓WordPress直接處理它，由Jetpack Site Accelerator支持。還不確定。總是有事情要做。</p>



<ol><li>我看到WordPress本身也參與了塊腳手架遊戲。他們的“create-wordpress-block”概念已經進入Gutenberg存儲庫本身，你可以用`npm init @wordpress/block [options] [slug]`啟動它。</li></ol>