我是一位最近開始與古騰堡一起開發的開發人員。 有很多令人驚奇的優點和功能，但是也有很多缺點，不一致之處以及絕對糟糕和過時的文檔。
從開發人員的角度來看，古騰堡最糟糕的方面之一就是塊驗證。 請考慮以下情形。 我構建了一個基於JavaScript的自定義（非動態）塊，然後CMS編輯器將該塊添加到了數千個頁面中。 當我需要更新塊的標記時，會發生什麼情況？
默認情況下，所有塊都將進入無效狀態，並且不會反映在站點的前端。 CMS編輯器必須進入數千頁，然後手動單擊允許恢復該塊的按鈕。
有人建議使用塊棄用來解決此問題，但API記錄不充分，令人困惑，並且如果長期使用多次棄用，似乎將變得難以維護。
區塊開發者應該沒有選擇退出驗證過程的方式，還是全局的方式來恢復區塊？
PJ
PJ，您當然沒有保留任何東西。 儘管其中很多內容比我通常在酒館裡講的要講的技術性要高一些，但我還是決定與古騰堡的主要開發人員之一Riad Benguella接觸，以進一步了解情況。
在深入他的回答之前，我已經對您的問題的一個方面進行了一些思考。 有時，開發人員需要棄用舊的標記並轉移到新的標記上。 但是，這不應該經常發生。 通常，如果需要定期檢修HTML，則表明體系結構不佳。 這還會導致其他問題，例如第三方無法保持樣式更改。
在開發塊或任何類型的輸出前端代碼的應用程序時，您需要考慮一下今天和十年後的情況。 如果用戶添加了一些自定義CSS來為您的代碼塊添加樣式，並且代碼塊的HTML結構發生了變化，會發生什麼情況？ 從他們的角度來看，您的區塊更新破壞了他們的網站。 對於另一個以某種方式擴展您插件的插件也可以這樣說。
詢問任何主題作者，當Gutenberg / WordPress更改其塊輸出時，它有多令人沮喪。 儘管在最近幾年中有所改進，但編輯器和前端的樣式塊通常是維護的噩夢。
作為開發人員，我一直試圖從用戶的角度考慮所有這些實際變化的後果。 那應該從第一天開始，而不是在發布項目之後。
當您試圖將其發布並交到用戶手中時，這樣做會為早期項目增加時間。 這是在發布前退後一步會有所幫助的地方。 遠離計算機。 出去走走考慮一下您的項目的體系結構以及長期來看是否理想。
Benguella表示：「對於塊版本控制/更新，確實是Gutenberg API的領域之一，我們需要在架構方面進行權衡，我們決定偏向於用戶體驗，而不是開發人員。」
不管您採用哪種開發方法，遵循項目的用戶至上經驗方法都將長期有效。
Benguella說：「要正確理解問題，需要了解塊的工作原理和如何對其進行編輯。」 「塊實例是一個JSON對象，編輯器UI會操作該JSON，但是為了保持向後兼容，以確保以最可讀的格式保存用戶的內容，並儘可能採用Web標準，塊編輯器不存儲JSON對象，而是將其HTML序列化存儲在post_content中。」
當編輯器重新載入內容以再次進行編輯時，該序列化將被解析並轉換為JSON。 在解析的最後階段，由塊作者決定如何保存和解析對象。
Benguella說：「現在，想像一下用戶是否更改了保存的HTML（序列化），然後在其中放置任何隨機內容。」 「該塊可能無法正確解析HTML，因為它與預期不符（由塊作者定義了），這意味著此時無法重新創建JSON對象以便進行操作。」
發生這種情況時，塊編輯器為用戶提供一個界面，以做出明智的決定。 他們可以嘗試「強制解析」塊JSON或將其轉換為HTML或Classic塊。
更改標記後無效的塊。
插件開發人員更新其塊時，可能會發生相同類型的失效。 但是，開發人員沒有更改已保存的HTML，而是更改了該塊的「期望」 —更改了保存和解析它的方式。
Benguella說：「這就是為什麼我們要求區塊開發者提供代表相同區塊舊標記的區塊棄用。」 「棄用也可以被視為同一塊的有效替代來源。 這樣，編輯者可以在載入時解析舊標記，並在對塊進行更新時將新標記保存回去。」
WordPress有 塊棄用文檔。 但是，這並不徹底。 看到現實世界中折舊的最佳來源是通過古騰堡的 塊庫。 不推薦使用的塊具有deprecated.js文件。
Benguella表示，這個系統可能會讓大作作者感到沮喪。 這在進行更改的開發環境中尤其明顯。 這導致開發人員要求禁用驗證演算法的方法。
他說：「我們目前不希望提供該功能，因為如上所述，當標記由於其他原因（外部編輯，其他編輯器等）更改時，驗證也很重要。」 「因此，如果用戶不了解任何內容，可能會導致用戶丟失內容。 現在優先考慮用戶意識。」
隨著時間的推移，該團隊改進了驗證系統，允許進行小的更改不會破壞模塊狀態。 還有一個 公開改進票 將來。
像這樣：
喜歡載入中……