WordPress 4.9のCodeMirrorは本番でthemeを直す前に検証する範囲を決める

WordPress 4.9 Beta 1では、themeとpluginのeditor、CustomizerのCustom CSS、Custom HTML widgetへCodeMirrorが入ります。入力中のcodeを読みやすくし、保存前に問題を見つける助けになります。しかし、editorにerrorが出ないことと、公開siteを直してよいことは別です。本番でthemeやpluginを直接編集する前に、何を替え、どのpageを見て、問題があればどう戻すかを決めます。

WordPress.orgは10月5日にWordPress 4.9 Beta 1を公開し、themeとpluginのeditor、CustomizerのCustom CSS、Custom HTML widgetでCodeMirrorを使うこと、linterによって保存前のerror確認を助けることを案内しました。betaは開発中の版です。新しいeditorを試すために、公開中のsiteを検証場所にしません。まずtest siteで、現在使っているthemeと必要なpluginが開けるかを確認します。

CodeMirrorが助ける入力と公開判断を分ける

CodeMirrorは、codeを入力するときの表示や確認を助けます。CSSの括弧が閉じているか、HTMLの書き方に問題がないかを見つけやすくなる場面があります。けれども、画面にerrorが出ないからといって、その変更が読者に必要か、ほかのpageを壊さないか、themeの更新後も残るかまでは判断できません。

たとえば、headerの余白を少し変えたい場合を考えます。Custom CSSへ一行足し、editorが保存できる状態になっても、small screenでmenuが重なる、長いpage titleが切れる、buttonの位置がずれることがあります。CSSの文法と、siteの案内が読めることは別です。変更後には、top pageだけでなく、長いtitleの投稿、問い合わせpage、検索結果、small screenを確認します。

theme editorでPHP fileを替える場合は、さらに範囲を分けます。PHPの一文字の誤りでpageが開けなくなることがあります。editorに入れるcodeの見え方が改善しても、templateの条件、WordPress function、使っているpluginとの関係までは自動で確認されません。公開中のthemeを直接替える前に、変更するfile、変更前の内容、確認するURL、戻すfileを用意します。

plugin editorも同じです。問い合わせformや計測を扱うpluginのfileを直せば、表示だけでなく受付や記録が変わることがあります。pluginの設定画面へcodeを貼れることと、そのpluginの更新後も修正を保てることは別です。外部のpluginを直接直す必要があるなら、なぜ必要か、更新で上書きされたときにどうするか、誰が保守するかを決めます。短い修正でも、所有していないpluginへ残す変更として扱います。

theme editorとCustom CSSを同じ変更場所にしない

WordPressでは、見た目を替える場所が一つとは限りません。Custom CSSは、themeのfileを直接書き換えずに見た目を調整するための場所です。theme editorは、themeが持つfileそのものを扱います。Custom HTML widgetは、sidebarなどのwidget areaへHTMLを置く場所です。どこへ書いても画面が変わる場合がありますが、更新の影響と戻し方は違います。

会社名の色を一時的に調整するだけなら、theme全体のPHPやstyle sheetを替える必要がない場合があります。反対に、templateが出すHTMLの構造を替えなければ実現できない案内もあります。見た目を変えたい理由を書き、CSSで足りるのか、themeのtemplateを替える必要があるのか、widgetで案内を加えるのかを決めます。便利なeditorが増えたからといって、同じ目的で複数の場所を一度に触りません。

説明用の仮例として、sidebarへ休業日の案内を出す場合を考えます。案内文だけを更新するなら、widgetの内容を替える方法を検討します。全pageのheaderへ同じ案内を出すなら、themeの共通部分を確認する必要があるかもしれません。案内の期間だけ色を変えるなら、Custom CSSで足りる場合があります。見た目の作り方を選ぶ前に、誰がいつ案内を消すか、古い日付が残ったときにどのpageへ影響するかを決めます。

設定場所を分けておけば、戻すときにも迷いにくくなります。widgetの文を消すのか、Custom CSSを戻すのか、theme fileを前の版へ替えるのかで、確認する人と手順が変わります。「WordPressを直した」という記録だけでは、次の担当者がどこを見ればよいか分かりません。変更した場所、変更した理由、公開した時刻、戻す内容を残します。

betaを試すsiteと公開するsiteを分ける

WordPress 4.9 Beta 1は開発中の版です。公開siteを更新してから問題を探すのではなく、test siteで先に試します。test siteには、本番で使うWordPress、theme、主要plugin、必要な設定に近い状態を用意します。本番と全く同じでなければ意味がないわけではありませんが、何が違うかを把握せずに結果を持ち込みません。

test siteで確認するのは、CodeMirrorの画面だけではありません。theme editorを開けるか、plugin editorを開けるか、Custom CSSとCustom HTML widgetを保存できるか、公開画面が読めるかを確認します。codeを一行足す試験をするなら、変更前の内容を残し、保存後に対象pageを開き、変更を戻して表示も戻るかを見ます。betaで動いたからといって、本番へ入れる時期を急ぎません。

制作会社へbetaの検証を頼む場合は、「WordPress 4.9を試してください」だけでは足りません。使っているtheme、編集したい場所、重要なplugin、確認したいpage、受付や計測へ影響する箇所、問題が出たときの連絡先を渡します。制作側は、試した版、変更したfileや設定、確認した画面、未確認の範囲を返します。作業を委託しても、公開siteの内容と復旧の判断を誰が持つかは事業側で決めます。

保存前のerror表示を復旧手段の代わりにしない

CodeMirrorのlinterは、保存前に問題を見つける助けになります。しかし、siteを戻す手段ではありません。保存後に表示が崩れた、管理画面へ入れない、formが送れないといったとき、どの変更を戻すかが分からなければ復旧に時間がかかります。変更する前に、元のfileや設定を保管し、戻す方法を確かめます。

backupも、取ったという事実だけでは足りません。database、uploads、theme、plugin、設定のどこが戻せるbackupかを確認します。theme fileだけを戻しても、widgetやCustomizerの設定が残ることがあります。逆に設定だけを戻しても、fileの変更が残ることがあります。変更する場所に合わせて、何を戻す必要があるかを分けます。

権限も確認します。theme editorとplugin editorへ入れる人が、必ずしも公開の内容を決める人とは限りません。事業側は、休業日、料金、問い合わせ先、サービス説明が正しいかを承認します。制作側は、codeと表示を確認します。管理者accountを渡すことと、誰でも本番のcodeを替えてよいことを同じにしません。

最初の一手は、直したい内容を一つ選び、それがCustom CSS、widget、theme file、plugin fileのどこにあるかを調べることです。次に、test siteで同じ場所を一つだけ替え、戻す方法と公開画面を確認します。WordPress 4.9のCodeMirrorは、codeを書く人を助けます。けれども、公開siteを安全に運用する判断は、変更する範囲と確認する人を決めて初めて成り立ちます。