SWELLをアップデートする前後の確認｜更新できない・表示が崩れたときの切り分け

SWELLの更新通知は出ているものの、カスタマイズした部分がそのまま動くか分からず、更新に踏み切れない。更新したいのに通知が出てこない、あるいは更新したらレイアウトが崩れてしまった。同じアップデートの相談でも、状況によって見るべきところは変わります。

これから更新するなら、先に変更内容を読み、本番とは別の環境で一度試しておくと安心です。すでに不具合が出ているなら、設定をいじる前に、どの画面で何が起きているかを記録しておくほうが、あとで原因を調べやすくなります。日々の運用でいえば、ページの文章を直す作業と、テーマやプラグインを変える作業とでは、確認のしかたを分けておくと無理なく続けられます。

更新できないときは、ユーザー認証が済んでいるかを確認する

SWELLを管理画面から更新するには、ユーザー認証を済ませておく必要があります。更新の通知が出てこない、あるいは認証を求めるメッセージが表示されているなら、まずはここから確かめます。

公式手順を要約すると、SWELLの購入に使ったメールアドレスで会員登録し、対象のサイトで認証する、という流れです。詳しくはSWELL「ユーザー認証を行う手順」に書かれています。購入時のメールアドレスが分からなければ、購入した担当者や制作会社に聞いてみてください。

制作会社に作ってもらったサイトだと、購入や認証を自社で行っていないこともあります。WordPressには自社でログインできても、SWELLの会員アカウントは制作会社が持っている、というケースです。担当者が替わったからといって買い直しが必要になるとは限らないので、まずは誰が購入し、どのアカウントで認証したのかを確かめるところから始めます。

認証は済んでいるのに更新できない場合は、サーバーの通信やファイルの書き込み権限など、別の原因を調べることになります。表示されたエラーメッセージと使っているバージョンを控えたうえで、サイトの管理担当者に相談するのが近道です。

カスタマイズした箇所と、アップデートの変更点を照らし合わせる

更新する前に、SWELLの公式アップデート情報で変更内容と注意事項に目を通しておきます。追加CSSや子テーマでカスタマイズしているなら、その部分に関わる変更が入っていないかもあわせて見ておきます。記録として控えておきたいのは、次のバージョンです。

• 更新前後のSWELLのバージョンいま使っているバージョンと、これから上げるバージョン。
• WordPress・PHP・関係するプラグインSWELL以外に、WordPress本体、PHP、使っているプラグインのバージョンも残しておきます。

不具合が出たあとで「全部最新版にした」ことしか分からないと、原因はなかなか絞り込めません。何を、どのバージョンから上げたのか。変更前後の記録があれば、調べる範囲を狭められます。

子テーマを使っている場合は、変更したファイルも確かめる

子テーマを使っていれば、親テーマを更新しても不具合は出ない、とは言い切れません。とくに気をつけたいのは、親テーマのテンプレートを子テーマにコピーして書き換えている場合です。

親テーマの更新でテンプレートに必要な処理が追加されても、子テーマにコピーした古いテンプレートにはその処理が入りません。どのファイルを何のために変更したのかは、制作を担当した人に確認しておくと安心です。

ページの修正は下書きで、プログラムの変更は検証環境で

ページの文章や画像は、下書きで社内確認してから差し替える

ページの文章や画像を直すたびに、別の検証環境を使う必要はありません。修正版を下書きとして作り、社内で確認してから公開中のページと差し替える。この流れができれば、作業はそのサイトの中で進められます。検証環境を用意しにくい場合にも使いやすい方法です。

そのために使えるのが、Yoast Duplicate Postというプラグインの「書き換え＆再公開（Rewrite & Republish）」です。公開中の記事や固定ページを複製し、元のページは公開したままで、複製した側の編集と社内確認を進められます。

1. 公開中のページから修正用の下書きを作るYoast Duplicate Postの書き換え＆再公開を使い、修正は複製側で進めます。
2. プレビューで修正内容を確認してもらう社内の確認担当者がプレビューを開けるようにして、文章・画像・リンクを確認してもらいます。下書きを作ったあとに元のページが編集されていた場合は、その修正が抜けていないかも見てもらいます。
3. 元のページへ反映して再公開する社内確認が済んだら、元のページと差し替えます。すぐに再公開することも、日時を指定して予約することもできます。

公式機能の要約：Yoast「Using the Rewrite & Republish feature」。元のページと差し替えたいときは、通常の「複製」ではなく「書き換え＆再公開」を選びます。画面の表記は、言語設定やバージョンによって違うことがあります。

ただ、下書きで確かめられるのは、あくまでそのページの中の変更です。テーマやプラグインの更新、共通のCSSやテンプレートの変更は、公開中のほかのページにもそのまま影響します。下書きを作っても本番から切り離せないので、こうした変更は別の検証環境で試します。

プラグインの動作を変えるなら、まず検証環境で試す

プラグインの動作を変えたいときは、提供元が用意しているフィルターなどを使う方法があります。インストールしたプラグインのファイルを直接書き換えるのではなく、拡張のために用意された仕組みを使うやり方です。どんなフィルターがあり、どう使うかはプラグインごとに違うので、仕様を調べてから実装します。自作プラグインを改修する場合も、同じく検証環境で作業します。

コードに問題があると、ページが表示されなくなったり、問い合わせフォームが動かなくなったりするおそれがあります。AIエージェントと一緒に作業する場合も同じで、検証環境で試し、ほかの機能に影響が出ていないことまで確かめてから本番に反映します。フィルターの仕組みについては、WordPress公式「Filters」を参照してください。

保守や改修を続けていくなら、本番サイトを複製した検証環境を持っておくと、作業を進めやすくなります。作る場所は担当者のパソコンのほか、クラウドや、今のサーバーに追加したサブドメインでも構いません。

• 担当者のパソコン（ローカル環境）パソコン上にサイトを複製して試します。PHPやデータベースのバージョン、キャッシュなど、本番との違いは把握しておきます。
• クラウド上の検証環境クラウド上にサイトを複製すると、離れた場所にいる担当者とも一緒に確認しやすくなります。サーバーの設定が本番と違う場合は、その差も押さえておきます。
• 今のサーバーに追加したサブドメインサブドメインを追加し、そこにサイトを複製します。ファイルとデータベースは本番とは別に用意します。本番と同じサーバーを使うので、空き容量や負荷にも気を配る必要があります。

サブドメインに作った検証用サイトは、何も制限しなければ外部から閲覧できます。関係者だけが見られるようにパスワードをかけ、あわせて検索結果に出ない設定もしておきます。検索結果から外すだけでは、URLを知っている人には見えてしまうからです。

本番サイトを複製するときに、もうひとつ気をつけたいのがメールの送信先や外部サービスとの接続設定です。複製したままテストすると、お客様に通知が届いたり、連携先の本番データを書き換えてしまったりするおそれがあります。作業に入る前に、テスト用の送信先や接続先に切り替えておきます。

バックアップは、復元の手順まで確かめておく

バックアップでは、記事や設定が入っているデータベースと、テーマ・プラグイン・画像などのファイルの両方を保存します。どちらか片方だけでは、元のサイトに戻せないことがあります。参考：WordPress公式「Backups」。

ただ、バックアップは取れているだけでは足りません。いざというときに誰が、どうやって戻すのかまで決めておく必要があります。必要なファイルが漏れていたり、復元する権限がなかったりすると、復旧に時間がかかってしまいます。一度検証環境で復元してみれば、手順に抜けがないかも確かめられます。

検証用のサイトが古いままだと、今の本番環境でなら起きる不具合を見逃すことがあります。できるだけ本番に近い状態で試し、問題がなければ本番に反映して、そこでもう一度表示や動作を確かめます。

本番へ反映するときに避けたいのが、検証用のデータベースで本番を丸ごと上書きするやり方です。サイトを複製したあとに追加された記事や、データベースに保存している問い合わせが消えてしまうおそれがあります。どのファイルや設定を反映するのかは、作業の前に決めておきます。

更新後は、管理画面と公開画面の両方を確認する

ログインした状態では問題がなくても、訪問者には古いキャッシュが表示されていることがあります。ログアウトした状態でも同じページを開き、更新前と比べて崩れていないかを見ておきます。

表示が崩れたら、設定を変える前に状況を記録する

1. どの画面で何が起きたかを記録するURL、使った端末とブラウザー、変わった箇所を書き留めておきます。
2. 表示だけの問題か、操作にも支障があるかを調べる文字の装飾だけが変わったのか、メニューが動かないのか、画面全体が表示されないのかを見分けます。症状によって、先に手を付けるべきことが変わるためです。

変更したはずの装飾が反映されないなら、古いキャッシュが残っているのかもしれません。テーマ、プラグイン、サーバー、ブラウザーのどこでキャッシュを使っているかを調べ、一つずつ削除しながら表示を確かめます。どの操作で表示が変わったのかを控えておけば、その後の調査の手がかりになります。

独自CSSや子テーマを使っているなら、それが原因になっていないかを検証環境で調べます。プラグインも、一つずつ有効・無効を切り替えて確かめていきます。本番で複数のプラグインをまとめて止めてしまうと、問い合わせなど別の機能にまで影響が出て、原因もかえって追いにくくなります。

サイトが使えないときは、原因より復旧を先にする場合もある

主要なページが開かない、問い合わせが送れない。そうした状態なら、原因を調べるより先に、サイトを使える状態へ戻したほうがよいことがあります。いったん更新前の状態に戻して復旧させ、原因はそのあと検証環境で調べる、という順番です。

ただし、データベースまで古い状態に戻すと、更新後に追加されたデータが失われるおそれがあります。テーマのファイルを戻すだけで直るのか、設定まで戻す必要があるのかを調べ、戻す範囲を見極めます。

更新から不具合への対応まで、誰が担当するか

こうして並べてみると、アップデートは更新ボタンを押せば終わり、という作業ではありません。自社で対応するなら、バックアップから更新後の確認まで誰が担当し、不具合が出たら誰に連絡するのかを決めておくと、いざというときに迷わずに済みます。外部に頼む場合は、フォームの動作確認やカスタマイズ部分への対応、復旧までが依頼の範囲に入っているかを確認しておくと安心です。

grandworkにご相談いただく際は、サイトのURL、変更前後のバージョン、表示されたエラー文、最後に正常に動いていた時刻を教えてください。最初のお問い合わせにログイン情報を書いていただく必要はありません。いただいた内容をもとに、確認したいことと進め方を当社からご連絡します。