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

SWELLの更新通知が出たものの、カスタマイズした部分がそのまま動くか気になって、更新をためらう。あるいは、更新したいのに通知が出ない、更新後にレイアウトが崩れてしまった。同じアップデートの話でも、困っていることによって調べる箇所は違います。

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

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

SWELLを管理画面から更新するには、ユーザー認証が必要です。更新の通知が出ないときや、認証を求めるメッセージが出ているときは、まず認証が済んでいるかを確認してください。

公式手順の要約：SWELLの購入に使ったメールアドレスで会員登録し、対象サイトで認証を行います。詳しくはSWELL「ユーザー認証を行う手順」をご覧ください。購入時のメールアドレスが分からない場合は、購入した担当者や制作会社に確認しましょう。

制作会社に依頼したサイトでは、購入や認証を自社で行っていないこともあるでしょう。WordPressにはログインできても、SWELLの会員アカウントは制作会社が管理しているかもしれません。担当者が変わったからといって、すぐに買い直す必要があるとは限らないので、誰が購入し、どのアカウントで認証したのかを確認するところから始めます。

認証済みなのに更新できない場合は、サーバーの通信やファイルの書き込み権限なども調べる必要があります。表示されたエラーメッセージと使用中のバージョンを控え、管理担当者に相談しましょう。

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

まずはSWELLの公式アップデート情報で、更新内容と注意事項を確認します。追加CSSや子テーマでカスタマイズしている場合は、その部分に影響する変更がないかも見ておきましょう。

• 更新前後のSWELLのバージョン現在のバージョンと、これから更新するバージョンを控えておきます。
• WordPress・PHP・関係するプラグイン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、変更前後のバージョン、エラー文、最後に正常だった時刻をお知らせください。初回のお問い合わせにログイン情報を記載する必要はありません。お知らせいただいた内容をもとに、当社から確認事項や進め方をご案内します。