Shopifyのテーマ手動更新とコード編集:メモ

公式ヘルプに記載の情報しか明確なものが見つけられませんでしたがメモとして。

前提

Shopifyのオンラインストアで、テーマ内のファイルのコードを編集している状態
手動で更新するボタンを押してテーマをアップデートする

自動更新と手動更新

Shopifyヘルプセンター | テーマの更新

テーマを手動で更新する
更新されたバージョンのテーマを下書きテーマに追加するには、通知をクリックして詳細ダイアログを開き、下書きテーマに追加するをクリックします。

テーマの自動更新
Shopify によってテーマに自動更新が適用されると、Shopify 管理画面でテーマのバージョン番号の代わりに通知が表示されます。

自動更新は、テーマのバグやセキュリティの問題を修正するためのものです。この更新によって、テーマの見た目と雰囲気が変更されたり、コンテンツや設定が変更されたりすることはありません。テーマのステータスダイアログで [リリースノートを表示] をクリックすると、これらの更新のリリースノートを表示できます。

ヘルプには上記のような記述があり、当記事では手動更新に関する内容となります。

公式ヘルプに基づく結論

Shopifyヘルプセンター | テーマの更新

テーマエディタを使用してテーマに加えたカスタマイズは、コピーされて更新版のテーマに適用されます。これには、以下の変更が含まれます。

テーマ設定の変更。

セクションまたはブロックの追加、並べ替え、削除、非表示などのページレイアウトの変更。

画像、動画、テキスト、データソースの追加など、セクションまたはブロック設定の変更。

新しいテンプレートの作成。

埋め込みアプリまたはアプリ拡張機能の追加、削除、または設定の変更。

テーマコンテンツエディタを使用した、オンラインストアの文言の変更。

インストール済みのアプリや手動でテーマにコード変更を加えていて、そのコード編集が更新と競合しない場合、そのコード編集は更新に含まれます。

テーマの手動更新とコード編集に関しては、上記の末尾の以下が該当します。

インストール済みのアプリや手動でテーマにコード変更を加えていて、そのコード編集が更新と競合しない場合、そのコード編集は更新に含まれます。

ただしテーマの更新後の状態次第となるためか、競合か否かを判断するための具体例やルール等の記述は見当たりません。

アプリによるコード編集

Shopifyのヘルプは日本語訳の質が良くないことがあるため、英語版の方を引用します。

Shopify Help Center | Updating themes

Code changes can come from either of the following sources:

Manual code changes that have been made to your theme files in the code editor, except for files in the Templates folder and the settings_data.json file in the Config folder.

Automated code changes that an app which you installed on your store has made to your theme files on your behalf.

上記のように、コードの編集が指すのはアプリが自動で変更したコードも対象となります。
当然と言えば当然ですが、コードを編集した主体は関係ありません。

そのため、使用アプリによってはマーチャントが認識できないタイミングでコードの編集が行われている可能性があります。
ただし、この種の操作はアプリのヘルプ等で触れられている場合もあり、事前に確認できる可能性はあります。

調査

開発ストアにて、Horizonを3.3.0から4.1.3に手動更新を行なう

上記条件で、一部をコード編集してから更新するという方法を繰り返して実験調査を行いました。
しかしながら、結局のところ成否は「更新後の状態と競合したか否か」という点に集約されるため、状況的に実験の意味があまりなかったように思います。

調査結果を見る

調査結果

更新が成功すると、更新先にカスタマイズ内容が移植される(記述追加/記述変更/新規ファイル追加)
更新が失敗すると、失敗の直接的対象以外のカスタマイズも含めて全て移植されない
更新後に変化する範囲にカスタマイズ箇所が含まれる場合、更新は失敗する(=競合による失敗)

上記2項目に関しては例えば以下のような状態になるため、手動移植の対象作業はコード編集を行なった全箇所になると思います。

layout/theme.liquid内のheadタグ内にGTMのコード記載する編集作業のみであれば成功する
blocks/email-signup.liquid内のformタグ内にテキストを追加する編集作業のみであれば失敗する
前2項の作業を同時に行うと失敗し、headタグ内のGTMのコードも移植されない

更新が失敗したケース

更新前後で変化する範囲内にカスタマイズ箇所が存在した場合
更新が失敗する場所では、改行のみを追加しただけで
各ファイルの先頭に追加したカスタマイズも、更新が失敗する場合がある

ファイルの先頭に改行を追加しても競合するはずがないと思うのですが、それだけでも更新が失敗するのは想定外でした。
成功するファイルとの差異を確認したところ、おそらくですが以下のような仮説を建てられるかもしれません。

更新後のファイルの最上部のコードが変更されている場合、そのファイルは丸ごとが競合箇所と見なされる

ただし、layout/theme.liquidで試した際には、bodyタグ内のコンテンツ部分へのカスタマイズはエラー要因となりましたが、headやfooter以降付近ではエラーにならなかったので、ファイル丸ごとではない可能性も考えられます。

いずれにしましても未来のアップデートを完全に見通すことは不可能なので、「ファイルの先頭なら安全」とは言えない状況です。

ファイルの先頭に追加した際の実例を見る

成功例: ファイル先頭に改行等を追加してもエラーなし

blocks/email-signup.liquid




{% assign block_settings = block.settings %}
<div
  class="email-signup-block size-style spacing-style"
  style="{% render 'size-style', settings: block_settings %}{% render 'spacing-style', settings: block_settings %}"
  {{ block.shopify_attributes }}
>

↓ アップデート後の状態




{% assign block_settings = block.settings %}
{% liquid
  assign is_custom_input = false
  if block_settings.input_style == 'custom'
    assign is_custom_input = true
  endif
%}
{% render 'button-custom-styles', block_settings: block_settings, block_id: block.id %}
<div
  class="email-signup-block size-style spacing-style"
  style="
    {% render 'size-style', settings: block_settings %}
    {% render 'spacing-style', settings: block_settings %}
  "

失敗例: ファイル先頭に改行等を追加するとエラー

sections/carousel.liquid




<div class="section-background color-{{ section.settings.color_scheme }}"></div>
<div
  class="
    section
    section--{{ section.settings.section_width }}
    color-{{ section.settings.color_scheme }}
    section-carousel
    spacing-style
    gap-style
  "

↓ アップデート後




{% liquid
  if section.settings.background_color != blank
    render 'contrast-override', background_color: section.settings.background_color, section_id: section.id
  endif
%}

<div
  class="section-background{% if section.settings.background_color != blank %} color-custom-{{ section.id }}{% endif %}"
>

更新が成功したケース

更新前後で変化しない部分のカスタマイズは、移植される可能性が高い
layout/theme.liquidでは、headタグ内のカスタマイズは移植される可能性が高い
layout/theme.liquidでは、 {% sections 'footer-group' %}より下の部分に記述されたカスタマイズは移植される可能性が高い
renderタグのファイル名を書き換えるカスタマイズは、移植される可能性が高い

Shopify.devとAssistantによる調査

Updating your theme

Depending on the contents of the new theme version, a merchant’s theme can be updated in the following ways:

A manual update

An automated update

ヘルプと同様に2種類の記載があり。「更新する」ボタンを押すのはA manual update(=手動更新)になります。

テーマベンダーが自動更新を選択した場合は、テーマファイルの状態に応じて以下のいずれかになるようです。

一切テーマファイルを編集していない状態であれば、何もせずとも自動で更新される
少し変更でもテーマファイルが変更されている場合は、自動では実行されず手動での対応になる

上記に加え、shopify.dev内で利用できるAsk assistantへの質問によって以下であるという情報を得ました。

更新前のカスタマイズが更新後に移植されるという記述は存在しない
実際に移植されていたとしても、仕様とは判断できない

テーマベンダー向けのドキュメントの模様なので記述対象自体が異なる可能性がありますが、ヘルプと矛盾する内容でした。

テーマカスタマイズにおける実務上の留意点

個人的には以下のように考えています。

マーチャント単独でテーマ更新を可能にするためには、テーマファイルの編集は極力避ける
(※特に既存ファイルの複数箇所を書き換える作業は避ける)
カスタムLiquidセクションやブロックにLiquidやJavaScriptを書く方法も視野に入れる
(※マーチャント自身による編集が困難になる点に注意)
常に翻訳対応が可能かどうかを考える
(※Translate&Adaptアプリで翻訳できることを基本とする)
テーマファイルの編集を行う場合、編集したことにより手動更新時に問題が発生する可能性を伝えた上で、手動移植が可能かつ容易な構成を心がける

上記を踏まえると以下の範囲に落とし込む方が安全だと思われます。

テーマ内蔵やアプリの機能の範囲内で対応

ただし、テーマの破壊的なアップデートやアプリ自体が撤退する可能性もあるため、確実に安全な方法というわけではありません。

ファイル自体を独自作成する場合

前述の「手動移植が可能かつ容易な構成」として検討できる方法として、コメントや命名規則による判別要素の作成のほか、以下のような独自ファイルの追加が考えられます。

独自にセクションファイルを作る
独自にブロックファイルを作る

テーマ内の既存セクションの中に以下要件を両方満たす汎用ラッパー的なセクションが存在している場合は、独自ブロック開発での対応が視野に入ります。

{% content_for 'blocks' %}でブロックの出力を行っている
"blocks": []内に"type": "@theme"の記述がある

参考

Liquid tags: content_for
{% content_for 'blocks' %}に関して
AI generated theme blocks
_blocks.liquidというAI生成用の特殊なラッパーセクションに関して。Horizonテーマではでは最初から追加されており、その中に"type": "@theme"が記述されている。
Section schema
"type": "@theme"に関して
Theme block targeting
blocksディレクトリ内のファイル名の先頭に_(アンダーバー)をつけると、ブロックの候補に表示されなくなる仕様に関して

アップデート実行の必要性判断

アップデートが提供される理由としては、重要度が高い順に概ね以下の種類が考えられるかと思います。

セキュリティ関連
問題箇所修正関連
機能追加関連

セキュリティ関連は重要度が高く必須とも言える理由です。

セキュリティを除く問題箇所修正関連(バグフィックス)は詳細次第で重要度が変わりますが、現状のテーマで問題と判断できる部分がなく、アップデートを実行してもメリットが小さいという場合は、アップデートしないという判断も可能ではあります。

機能追加関連は、アップデートを実行してもメリットが小さいという場合は、アップデートしないという判断が可能です。

つまりセキュリティ以外は状況次第ではあるので、常にアップデートが必須というわけではありません。

しかしながら、選択的にアップデートを行うならば当然アップデート内容を把握する必要があり、多くのマーチャントは判断が困難なように思います。
実際の状態を把握していませんが、明確にセキュリティアップデートだとわかるように表示される場合は、その表示の有無で判断できるかもしれません。

参考

HackerOne内で、以下のようにShopifyで絞り込むとセキュリティ関連の問題の詳細が複数確認できます。

Hacktivity | HackerOne

HackerOneに関しては以下など。

結び

前述の通り、コード編集箇所が競合するかしないかはアップデート実行後にしか判明しないため、事前の予測は不可能です。
Shopifyが用いるAIによるコード関連機能は今後も進化するとは思いますが、完全な対応は難しいように思いますので、今後もコード編集を行う際には必要性含めて検討が必要がなると思われます。

0人がこの記事を評価

役に立ったよという方は上の「記事を評価する」ボタンをクリックしてもらえると嬉しいです。

連投防止のためにCookie使用。SNSへの投稿など他サービスとの連動は一切ありません。