Shopifyのテーマを直接編集する前に決めること｜反映されない・他ページが崩れるを防ぐ作業手順
Shopifyのテーマを直接編集する前に決めること｜反映されない・他ページが崩れるを防ぐ作業手順
Shopifyのテーマファイルを直接編集していると、必ず2種類のトラブルに当たります。
ひとつは「直したのに反映されない」。もうひとつは「触っていないはずのページが崩れた」。
そして厄介なのは、どちらもエラーが出ないことです。コマンドは成功と表示され、管理画面も通常どおり動きます。気づくのは数日後、お客様や店舗スタッフからの指摘であることも珍しくありません。
この記事では、テーマを直接編集する前に決めておく項目と、崩さずに反映させる作業手順を、実際のEC運用から整理します。コードの書き方ではなく、「どのテーマに」「どの範囲で」送るかの話が中心です。原因の大半はそこにあるからです。
結論：触る前に4つ決める
先に結論から書きます。テーマファイルを開く前に、次の4つを決めておくことです。
| 決めること | 具体的に |
|---|---|
| ① どれが本番のテーマか | 名前や見た目ではなく、CLIの一覧やテーマIDの実値で確定させる |
| ② どこで作業するか | ライブテーマを新しい空フォルダに取得し直す。手元の作業フォルダを使い回さない |
| ③ 何を送るか | ファイル単位で指定する。フォルダごと送らない |
| ④ どう確かめるか | 送信後に取得し直し、実際のURLを開いて確認する |
この4つを先に決めておけば、冒頭の2つのトラブルはほぼ起きません。逆に、どれか1つでも曖昧なまま作業を始めると、編集の中身が正しくても事故になります。
すでに「直したのに反映されない」が起きている場合は、次の章の3層の切り分けから読んでください。上から順に見ていけば、たいてい数分で原因が確定します。
「反映されない」の正体は3層に分かれる
反映されない、と感じたとき、実際に起きていることは3つのどれかです。上から順に潰していくと早く切り分けられます。
第1層：見ているページが、そのテーマではない
いちばん多いのがこれです。Shopifyには、公開せずに別のテーマを表示して確認する「プレビュー」機能があります。このプレビューはブラウザ側に情報が保存されるため、通常のURLを開いているつもりでも、別のテーマが表示され続けていることがあります。
画面下にプレビュー中を示すバーは出ていますが、日常的に管理画面を開いている人ほど景色として慣れてしまい、気づきません。
この状態だと、「本番を直したのに変わらない」も「作りかけのページが公開されている」も、どちらも起こります。実際に、制作途中のテーマがプレビュー状態で残っていたために、すでに本番へ反映済みの改修を「まだ未完成だ」と認識し、作り直しかけたという状況は起こり得ます。
判定は簡単で、2つあります。
- ブラウザの開発者ツールで、表示中のテーマの名前・ID・役割（ライブかどうか）を直接読む
- コマンドラインでテーマ一覧を出し、
liveと表示されているものを確認する
もうひとつ、道具を使わない切り分けもあります。ブラウザと、コマンドラインでのページ取得の結果を見比べる方法です。コマンドラインからの取得はブラウザの保存情報を持たないため、素の公開状態が返ってきます。両者で違うページが返るなら、原因はブラウザ側にあると確定します。
第2層：送った先のテーマが、公開中のものではない
Shopifyのストアには、たいてい複数のテーマが眠っています。「〇〇改修版」「デザイン刷新」といった名前が並び、どれが最新かは名前からは判断できません。
ここで注意したいのが、未公開テーマの中身は「いつの時点のコピーか」がわからないという点です。名前が公開中のテーマと同じでも、中身は数か月前の状態、場合によっては当時使っていた外部アプリ前提の構造のまま、ということがあります。
見分け方は中身です。配色設定の名前づけ、使われているフォント、トップページのテンプレートに何のセクションが並んでいるか。この3つを見るだけで、世代がずれているテーマはすぐ判別できます。
未公開テーマを作業対象にするときは、必ず「公開中のテーマの今の状態」から新しく複製して作る。 これが安全な入り口です。既存の未公開テーマを拾って使うのは、地雷を踏む確率が高い選択です。
第3層：送れてはいるが、設定が落ちている
これがいちばん気づきにくい層です。
セクションのファイルと、そのセクションの設定を保存しているテンプレートのJSONファイルを、1回のコマンドでまとめて送ると、新しく追加した設定項目が捨てられることがあります。JSONが処理される時点で、セクション側の定義がまだ古いままのため、未知の項目として無視されるからです。
このとき、コマンドは成功と表示されます。ファイルも確かに送られています。しかし設定値だけが入っていない。管理画面のカスタマイズ画面を開いても、その項目は空のままです。
対処はシンプルです。2回に分けて送る。 先にセクションのファイル、次にテンプレートのJSON。そして送ったあとに取得し直して、設定が実際に入っているかを目で確認します。
「他ページが崩れる」はコードではなく送信範囲の問題
もうひとつのトラブル、触っていないページが崩れる方です。こちらは原因がはっきりしています。
テーマの送信は、常にファイルの丸ごと置き換えです。 手元とサーバーの差分を賢く判定して、変わったところだけ更新してくれるわけではありません。送った瞬間に、送信元のファイルの中身がそのまま本番になります。
ここから2つの事故が生まれます。
フォルダごと送ると、触っていないファイルまで巻き戻る
手元の作業フォルダを丸ごと送るのは、いちばん危険な操作です。
作業フォルダが数か月前に取得したものであれば、その間に本番へ入った修正はすべて手元にありません。フォルダごと送れば、編集した1〜2ファイル以外が、まとめて数か月前の状態に戻ります。 規模の目安として、4か月ほど放置した作業フォルダと公開中のテーマを比べると、30ファイル以上が食い違っている、というのは珍しくありません。設定ファイル、各テンプレートのJSON、共通パーツ。どれも普段は意識しないファイルです。
そして厄介なのは、編集対象のファイルだけを見比べると「手元と本番は同じ」に見えることがある点です。そのファイルは誰も触っていなかった、というだけの話なのに、「手元のフォルダは最新だ」と判断してしまう。結果として、設定ファイルやテンプレートJSONが古い世代に戻り、CSSとの噛み合わせが壊れて、ページ全体が表示されなくなる、といった事態が起こり得ます。
編集の中身は正しくても、送信の範囲が間違っていれば壊れます。 ここは分けて考える必要があります。
古い作業フォルダの使い回しは、他の人の修正を消す
同じ理由で、前日以前に作った作業フォルダを再利用するのも危険です。
複数人・複数日にまたがってテーマを触っている場合、自分が最後に取得したあとに、別の担当者が同じファイルを直しているかもしれません。その状態で自分の手元のファイルを送れば、相手の修正は消えます。ファイル単位の指定をしていても同じです。指定したファイルは丸ごと置き換わるからです。
これも成功と表示され、痕跡は残りません。数日後に「直したはずの箇所が元に戻っている」という形で発覚します。
送信の直前に、そのファイルだけでも取得し直して、自分の編集を載せ直す。 手間はかかりますが、これが唯一の防ぎ方です。
崩さないための作業手順
以上を踏まえた実務手順です。ファイルを1行直すだけでも、この順番を守る価値があります。
- 公開中のテーマを確定する（CLIの一覧で
liveを確認。名前で判断しない） - 新しい空フォルダに、公開中のテーマを取得する（既存の作業フォルダは使わない）
- そこに、編集したファイルだけを上書きで置く
- 取得したままの状態と、送る予定の状態を機械的に比較する（差分が意図したファイルだけであることを確認する。ここで初めて「何を変えるのか」が確定します）
- ファイルを指定して送る（フォルダごとは送らない。セクションとテンプレートJSONは2回に分ける）
- 送信後、取得し直して内容が入っているか確認する
- 実際の公開URLを開いて、表示を確認する
手順4は省略されがちですが、いちばん効きます。「自分は1ファイルしか変えていないつもり」を、思い込みではなく比較結果で裏付ける工程だからです。フォルダ丸ごと事故は、この1手で全部止まります。
なお、送信コマンドは必ず作業フォルダの中で実行してください。 別の場所から実行すると、意図しない中身が送られて、ページが白紙になる事故につながります。ファイル指定をしていれば被害は出ませんが、指定を忘れた1回で本番が飛びます。実行場所をルール化しておくのが安全です。
Liquidは「エラーを出さずに間違う」
送信まわりとは別に、Liquid（Shopifyのテンプレート言語）そのものにも、静かに間違う書き方があります。書いたとおりに動かないのに、エラーは出ません。
条件を複数つなげて書かない。 Liquidの and / or は一般的なプログラミング言語と評価の順序が異なり、後半の条件が丸ごと無視されることがあります。真偽をひとつずつ変数に置いてから、入れ子で判定する書き方に統一するのが安全です。
ブログ記事のハンドル（識別子）は、記事名だけではありません。 ブログ名を含んだ形になります。前方一致で判定したい場合、そのまま先頭数文字を切り出すと、ブログ名の側を見てしまいます。区切り文字で分割してから使ってください。
IDの余りで振り分けない。 商品IDを一定の数で割った余りを使って表示を分散させようとすると、IDの採番規則によっては全商品が同じ値になり、分岐が固定されます。実際に、全商品が同じ余りになって、複数用意した表示パターンのうち1つが永久に選ばれない、という状態は起こり得ます。分散させたい場合は一度割ってから余りを取り、実データで分散しているかを必ず確認します。
そして、出力が変わらないときは、キャッシュを疑う前にデバッグ出力を仕込む。 HTMLコメントとして変数の中身を書き出せば、公開ページのソースを見るだけで実際の値がわかります。推測で3回直すより速く原因にたどり着けます。
そもそもコードを触らずに済む変更は多い
最後に、判断の話です。テーマファイルの編集はリスクを伴う作業なので、触らずに済むならその方がいい。
実務でよくあるのが、コードを開く必要のない変更を、わざわざテーマファイルで直そうとするケースです。
| 変更したいもの | 実際の編集場所 |
|---|---|
| 商品一覧の上に出ている説明文 | 管理画面のコレクション設定 |
| 英語表示の文言 | 翻訳アプリ側（テーマではない） |
| 注文確認メールの文面 | 設定内の通知テンプレート |
| 明細表（納品書）の内容 | 発送と配達の仕様表テンプレート |
| 商品オプションの選択肢や表示 | オプション管理アプリ側 |
注意したいのは、注文確認メールと明細表は、見た目が似ていても使える変数の体系が違う点です。片方で動いた書き方をもう片方にコピーしても動きません。明細表の明細行のループは1種類ですが、通知メールは商品の持ち方によって複数の経路に分かれ、どれかひとつだけを書くと一部の商品が静かに表示されなくなります。
編集に入る前に「これはどこで直すのが正しいか」を確認するだけで、テーマを触る回数はかなり減らせます。触る回数が減れば、事故の確率もそのまま下がります。
まとめ
- 「反映されない」は3層で切り分ける。見ているページ・送った先のテーマ・送信範囲の順に潰す
- プレビュー状態はブラウザ側に残る。テーマの実値かコマンドラインでの取得で確かめる
- 未公開テーマは「いつのコピーか」が不明。公開中のテーマから複製して作る
- テーマの送信は常に丸ごと置き換え。フォルダごとは送らない。ファイル単位で指定する
- 作業フォルダは使い回さない。送信直前に取得し直して、自分の編集を載せ直す
- 送る前に差分を機械的に比較し、送ったあとに取得し直して確認、最後に実際のURLで確認する
- セクションとテンプレートJSONは2回に分けて送る
- Liquidはエラーを出さずに間違う。条件は分けて書き、デバッグ出力で実値を確認する
- コードを触らずに済む変更は多い。編集場所の確認を先に行う
テーマの直接編集は、慣れるほど手順を飛ばしたくなる作業です。しかし飛ばした工程は、必ず後日の手戻りとして返ってきます。「送る前に比べる、送ったあとに確かめる」の2つだけでも運用に組み込んでおけば、大きな事故はほとんど防げます。
ECサイトの改修や運用でお困りのことがあれば、graciautoまでお気軽にご相談ください。