テーマを直した履歴を残したいと思い、「どいやさんぽ。」の子テーマをGitHubの非公開リポジトリで管理することにしました。ただし、GitHubにあるコードだけではWordPressのサイト全体は復元できません。この記事では、修正から公開までの流れと、ConoHa WINGのバックアップの役割を分けて説明します。
この作業の要点：コードの変更履歴を残すこと、WordPressへ正しいZIPを反映すること、サイト全体を復元できる備えを持つことは、それぞれ別の確認が必要です。
まず結論：保存するものが違う
- GitHub：テーマのコードをいつ、どう変えたかの履歴
- WordPress：公開中のテーマと、記事・固定ページなどの内容
- ConoHa WINGのバックアップ：サーバー側のWebファイルとデータベースを復元するための記録
このサイトのGitHubリポジトリには子テーマ doiyasanpo-gemini のソースを保存しています。親テーマ first_originaltheme、投稿、アップロード画像、プラグイン、データベース、APIキーは含みません。
テーマ修正から公開までの手順
- ConoHa WINGで復元可能なバックアップの日付を確認する
- GitHub DesktopでテーマのリポジトリをPCにコピーする
- 子テーマのファイルを修正し、プレビューで表示を確かめる
- 変更点を確認してコミットし、GitHubへPushする
- 子テーマのフォルダだけをZIPにしてWordPressへアップロードする
- 公開サイトのトップ、記事、記事一覧、AI質問ページを確認する
1. GitHub Desktopで変更を記録する
最初にテーマのリポジトリをGitHub Desktopでクローンします。修正後、「Changes」に表示される差分を見て、意図しないファイルや認証情報が含まれていないか確認します。
「ヘッダーのリンク先を修正」のように何を変えたか分かる説明でコミットし、Push originでGitHubに送ります。コミットは変更の記録、Pushはその記録をGitHubへ反映する操作です。GitHubへPushしただけでは、WordPressの公開サイトは変わりません。
2. WordPressへ反映するZIPを作る
このサイトの場合、アップロード用ZIPの中身は doiyasanpo-gemini/ フォルダです。GitHubの「Download ZIP」で得たリポジトリ全体のZIPは、WordPressのテーマZIPと階層が違うことがあります。ZIPを開き、最上位に子テーマのフォルダがあるか確認します。
管理画面の「外観 → テーマ → 新規追加 → テーマのアップロード」でZIPを選びます。既存テーマを置き換える場合は、どのテーマを置き換えるか画面で確認します。子テーマには親テーマも必要なので、親テーマを消さないようにします。
3. 更新後に必ず公開サイトで試す
トップだけでなく、記事、記事一覧、AI質問ページ、スマートフォンのメニューを確認します。ボタンが消えた、関連する記事が出ない、記事一覧へ進めないといった変更漏れは、アップロード後の操作で見つかります。
テーマの問題なら、前のテーマZIPに戻せるようにしておきます。記事や設定を含む問題なら、テーマだけ戻しても直らない場合があるため、サイト全体のバックアップが必要です。
ConoHa WINGの自動バックアップを確認する
ConoHa WINGの公式案内では、過去14日間分の自動バックアップを取得し、管理画面の「WING → サーバー管理 → 自動バックアップ」でWeb・Mail・DBの復元可能な日付を確認できます。このサイトを戻す場合は、少なくともWebとDBを同じ時点のセットとして考えます。標準の自動バックアップを、その場で手動実行できる機能だとは考えないようにします。
記事、固定ページ、コメント、多くの設定はデータベースにあります。テーマ、プラグイン、アップロード画像などはファイル側です。どちらか一方だけでは、元の状態に完全には戻せません。大きな更新の前には、復元できる日付と対象サイトを確認します。
変更の前後に残すと役立つ情報
テーマを編集する前に、直したいページのURLと画面、現在のテーマのバージョンや変更日を控えます。修正後は、GitHubの変更履歴に「何を直したか」「どのページで確かめたか」を短く残します。後で不具合が出たとき、どの変更が関係しそうか絞り込みやすくなります。
ZIPをアップロードした後は、管理画面での完了表示だけで終わらせません。トップ、記事、固定ページ、スマートフォン表示を開き、リンクやメニューを実際に押します。表示のキャッシュが残る場合もあるため、必要なら別のブラウザーでも見ます。見た目だけでなく、問い合わせなど使う機能も確認します。
戻す必要が出たときの考え方
テーマの表示変更だけが原因なら、直前のコードとZIPを確認します。一方、記事や設定、画像まで戻す必要がある場合は、GitHubの履歴だけでは足りません。サーバー側のバックアップの対象範囲と復元可能な日付を見て、作業前の状態を確認します。
バックアップからの復元は、その時点以降に追加した記事や変更を巻き戻す可能性があります。実行前に何が変わるかを確認するためにも、コードの履歴とサイト全体のバックアップを分けて管理しています。
更新時の短いメモ
バックアップ日付を確認 → コード修正 → プレビュー → 差分確認 → Commit → Push → テーマZIP作成 → WordPressへ反映 → 公開サイトで動作確認。この順番を残しておくと、後で「どの変更から表示が変わったか」を追いやすくなります。
詳しい画面操作はGitHub Desktop公式、バックアップの対象はConoHa WING公式、復元に必要なものはWordPress公式でも確認できます。
コメント