WordPressのGutenberg betaは本番投稿を替えず検証用siteで編集と表示を分けて試す

Gutenberg betaを試すなら、本番siteの投稿を最初の実験場所にしません。新しいeditorを入れて文章を書けることと、公開中のpage、theme、plugin、編集手順が問題なく続くことは別です。検証用siteまたは復旧できる複製を用意し、編集画面の操作と公開画面の表示を分けて確かめます。betaを試すことと、本番へ採用する判断を同じ日にしません。

WordPressは、Gutenbergを既存のTinyMCE editorに代わる新しいtext editorとして開発しており、beta pluginとして公開試験できると案内しています。一方で、production siteで使うことは勧めていません。新しい編集方法を知りたい場合でも、公開中の会社案内や問い合わせpageを直接開いて保存し直す前に、どの内容が変わるかを確認します。

試すsiteと公開中のsiteを分ける

検証用siteは、本番のURLへ影響させずに編集と表示を試す場所です。新しいserverを必ず用意する意味ではありません。本番を複製した環境、外部から見えない確認用のinstall、復旧できるbackupから戻せる状態など、公開中の読者へ変更を出さずに試せる場所を選びます。どこで試したか、いつのdataを使ったかを残します。

説明用の仮例として、会社案内、サービスpage、過去の投稿、問い合わせpageを持つsiteを考えます。検証用siteへGutenberg betaを入れ、まず新しい短い下書きを作ります。次に、既存の投稿を一件だけ複製し、編集画面で見出し、link、画像、引用、listがどう扱われるかを確認します。本番の代表pageを直接開いて保存し直す必要はありません。

themeやpluginは、編集画面だけでなく公開pageにも関係します。editorで問題なく見えても、公開後に見出しの余白が崩れる、画像が大きくなる、shortcodeが期待どおりに出ないことがあります。検証では、編集できたかだけでなく、PCとmobileの公開画面、問い合わせへのlink、sidebar、footerを開きます。

本番と検証用siteのURLを取り違えない工夫も必要です。browserのbookmark、admin bar、site title、login accountを見分けられるようにします。検証用の変更を本番へ反映する作業と、本番の投稿を直す作業は別の手順として残します。コピーしただけで同じ状態になるとは決めません。

新しい投稿と既存の投稿を分けて確認する

新しいeditorでは、新規投稿を作る場合と、以前のeditorで書いた投稿を開く場合で確認する内容が違います。新しい投稿では、見出し、段落、画像、link、listをどの単位で編集するかを確かめます。既存投稿では、以前のHTML、shortcode、埋込み、独自のclassが読み込まれ、保存後も同じ意味で表示されるかを確認します。

最初から長い記事や重要な固定pageを使う必要はありません。見出し、本文、画像、link、list、引用を含む短い検証用文章を作り、保存、preview、公開画面の順に見ます。次に、siteでよく使う既存の記述を一つずつ足します。すべてを一度に貼ると、どの要素で表示が変わったかを分けられません。

たとえば、本文に短いcode、外部link、table、問い合わせへのbuttonがある場合、それぞれを分けて試します。buttonの見た目が変わったなら、editorの設定、themeのCSS、pluginの出力のどこを確認するかを記録します。新しいeditorに合わせて文章を全部書き直す前に、既存の表現とpageの役割を守れるかを確かめます。

編集する人の手順も変わります。書く人、確認する人、公開する人が別なら、新しいeditorで誰がどの段階を担当するかを試します。入力欄の位置が変わったことを覚えるだけでは、担当が替わったときに引き継げません。下書きを作る、previewを見る、公開を承認する、戻すという手順を一枚にします。

戻す条件を先に決める

betaを試す前に、何が起きたら中止して戻すかを決めます。投稿が保存できない、公開pageの本文が崩れる、問い合わせlinkが動かない、画像やshortcodeが意図どおりに出ない、といった条件です。問題を見つけてからbackupを探すのではなく、backupの場所、復旧する人、戻したあとに確認するpageを先に書きます。

pluginを無効にすれば、すべてが直前の状態へ戻るとは限りません。試す前のdatabaseとfileをどう扱うか、どの投稿を編集したか、どの設定を変えたかを残します。検証用siteなら、問題が出た状態を保ったまま、本番を変えずに調べられます。戻す作業と原因を調べる作業を急いで同時にしません。

外部の制作会社へ試験を頼む場合は、「Gutenbergを試してください」とだけ依頼しません。対象site、使うdata、本番へ触れない範囲、試す投稿の種類、確認する画面、戻す条件を渡します。制作側は、入れたplugin、変更した投稿、確認結果、戻す手順を返します。試験を委託しても、公開中の内容をどこまで変えてよいかはcompany側が決めます。

betaの機能が気になるからといって、公開予定の大きな改修を急ぐ必要はありません。新しいeditorを試す目的と、siteを更新する目的を分けます。試験で分かったことを、themeの改修、投稿ルール、担当者の教育へ反映するかは、別の判断です。

最初の一手は、本番と別に試せるsiteを一つ決め、短い検証用の投稿を作ることです。そこへ見出し、画像、linkを入れ、保存した画面と公開画面を見ます。Gutenberg betaを使う前に、問題が出たとき本番へ戻らず調べられる場所を用意します。