SWELLで制作したサイトを、更新・引き継ぎ・テーマ更新の後も保守できるようにする24のルールです。特定の書き方をすべての案件に当てはめるのではなく、編集者が扱う範囲と、コードを変更する範囲を決めるためのチェックリストとして使います。
実装前の設計、HTML・ブロック、CSS、PHP・JavaScriptと公開確認の4段階に分けています。個別の実装コードと見本はリンク先にまとめ、このページでは選び方と確認条件を整理します。
実装前に決める6つのルール
1．標準ブロックと設定から確認する
最初にテーマの設定とブロックで実現できるか確認します。スライダーだから必ず自作が必要、とは判断しません。ブロックの見本と目的別カスタマイズ一覧から、必要な機能を選びます。
2．編集する人と変更してよい範囲を決める
納品後に誰が文章・画像・並び順を変更するかを決めます。制作者しか修正できない箇所を増やす前に、ブロックや入力欄で運用できないか検討します。
3．動く見本と受け入れ条件を用意する
実装前に、表示件数、長文、画像なし、空データ、スマートフォンで期待する状態を決めます。見本と掲載コードを同じ版で管理し、完成条件を「見た目が似ている」だけにしません。
4．テーマ依存とサイト固有機能を分ける
SWELLの見た目やフックに依存する変更と、テーマを変えても必要な機能を分けます。後者は専用プラグインなどで管理すると、テーマ変更時に残す範囲を判断できます。
5．作業前に復元できる状態を残す
スニペットのエクスポートだけでは、画像・記事・設定などを含むサイト全体のバックアップになりません。変更ファイルと設定に加え、必要なデータベースも保全し、復元先と上書き範囲を確認します。
6．検証環境と本番の差分を管理する
検証中にも本番の記事や注文は更新されます。サイト全体を上書きする前に、変更対象がファイルかデータベースかを確認します。本番反映の手順に沿って、対象だけを反映します。
HTML・ブロックを保守する6つのルール
7．グループ化は移動と再利用の単位に合わせる
関連する見出し・文章・ボタンをグループにすると、まとめて移動できます。すべてをフルワイドで囲む必要はありません。意味のない入れ子を増やさず、編集者がブロック一覧から構造を把握できる単位にします。
8．見出しと操作要素の意味を保つ
文字の大きさだけで見出しレベルを選ばず、内容の階層に合わせます。別ページへ移動するものはリンク、開閉などの操作はボタンを基本にして、キーボードでも使えることを確認します。
9．専用クラスで変更範囲を限定する
テーマ共通のクラスへ広く上書きする前に、対象のグループやブロックへ専用クラスを付けます。たとえばFAQの2列表示では、専用クラスを付けたFAQだけに適用します。
10．繰り返し部品のIDを重複させない
同じページに部品を2つ置く場合、入力欄・説明・操作ボタンの対象を個別にします。JavaScriptもその部品内から要素を探し、別の部品のボタンで動かないか確認します。
11．ショートコードは入力仕様も説明する
記事ID・表示件数・カテゴリーなどの引数について、未指定時、無効値、公開範囲を決めます。編集者が変更する値と、制作者が管理する実装を分けます。
12．実際の文章量と画像で確認する
短い仮テキストだけで完成とせず、長い見出し、複数段落、縦長画像、画像なしでも確認します。FAQなら質問と回答の関係、一覧ならカードごとの高さの違いを見ます。
CSSを保守する6つのルール
13．コードの置き場所を一つに決める
同じCSSを追加CSS・記事のCSS欄・子テーマへ重複して貼りません。適用ページ、管理場所、削除する旧コードを記録します。基本的な貼り付け先はSWELLのCSSカスタマイズを参照してください。
14．ブレイクポイントは内容が読める幅で決める
既存テーマの切り替え幅を参考にしながら、実際の本文幅と文字量で判断します。端末名だけで決めず、切り替え幅の直前と直後も確認します。サイドバーの出現で本文が狭くなる場合にも注意します。
15．命名規則をチーム内でそろえる
BEMなどの規則を使う場合も、採用した規則と例を残します。独自のクラスを公式の命名規則として紹介しません。短い名前を使い回すより、何の部品か分かる接頭辞を付けます。
16．詳細度を増やす前に競合を調べる
変更が反映されないときは、開発者ツールで適用されているルールと読み込み順を確認します。クラスを長く連結したり!importantを重ねたりする前に、対象範囲と不要な旧ルールを見直します。
17．エディターと公開画面を別々に確認する
公開用CSSがそのままエディターにも反映されるとは限りません。対象ブロックの編集用スタイルを適切な方法で読み込み、文字や余白の見え方を確認します。カスタム書式向けの欄へ、サイト全体のCSSを無条件に集約しないでください。
18．ネストと余白の責任範囲を決める
CSSネストを使う場合は対象ブラウザーとビルド環境を確認し、深い入れ子を避けます。部品内部の余白は部品側、部品同士の間隔は親のレイアウト側で管理すると、再利用時の調整箇所を絞れます。
PHP・JavaScriptと公開前の6つのルール
19．Code Snippetsに何でも集約しない
小さな機能を個別に停止できる利点はありますが、wp-config.phpの設定やすべての資産を置き換える道具ではありません。用途に応じて子テーマ、専用プラグイン、設定ファイルを使い分けます。子テーマの構成は子テーマの手順で確認できます。
20．CSS・JavaScriptは依存関係を管理して読み込む
外部ファイルはWordPressの読み込みAPIを使い、必要なページと依存ライブラリを指定します。同じライブラリをテーマとCDNから二重に追加しないでください。空のscriptタグを全ページへ出すことを共通の実装方針にはしません。
21．フックやテンプレート変更の依存先を記録する
フックで解決できる変更はフックを候補にし、構造変更が必要ならテンプレートも検討します。親テーマのファイルを直接編集せず、利用したフック名やテーマの版、更新後に確認するページを記録します。
22．入力・権限・公開範囲を処理ごとに確認する
投稿保存やAjaxでは、入力値の型・許可範囲、操作権限、必要なnonce検証を確認します。出力先に合うエスケープも必要です。nonceがあるだけで権限確認を省略したり、一覧に非公開・パスワード付きの記事を混ぜたりしないようにします。
23．管理メニューを隠すことと権限制御を分ける
メニューを非表示にしても、URLへの直接アクセスや処理の実行権限まで制限できるとは限りません。編集者に不要な機能を整理するときは、役割・権限と操作時の権限確認を別に設計します。
24．公開確認と停止手順をセットで残す
PC・スマートフォン、キーボード操作、複数配置、空データを確認します。変更が反映されない場合はキャッシュも調べます。エラー時は公開画面に表示せずログを調べる手順を使い、追加したコードをどこから停止するか記録します。
仕様を確認した公式資料
WordPress公式：CSS・JavaScriptの読み込み、子テーマ、管理メニューの非表示を参照しています。テーマやプラグインの更新後には、利用している機能の仕様と実画面を再確認してください。
