テーマを直した履歴を残したいと思い、「どいやさんぽ。」の子テーマをGitHubの非公開リポジトリで管理することにしました。ただし、GitHubにあるコードだけではWordPressのサイト全体は復元できません。この記事では、修正から公開までの流れと、ConoHa WINGのバックアップの役割を分けて説明します。
まず結論：保存するものが違う
- 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を同じ時点のセットとして考えます。標準の自動バックアップを、その場で手動実行できる機能だとは考えないようにします。
記事、固定ページ、コメント、多くの設定はデータベースにあります。テーマ、プラグイン、アップロード画像などはファイル側です。どちらか一方だけでは、元の状態に完全には戻せません。大きな更新の前には、復元できる日付と対象サイトを確認します。
更新時の短いメモ
バックアップ日付を確認 → コード修正 → プレビュー → 差分確認 → Commit → Push → テーマZIP作成 → WordPressへ反映 → 公開サイトで動作確認。この順番を残しておくと、後で「どの変更から表示が変わったか」を追いやすくなります。
詳しい画面操作はGitHub Desktop公式、バックアップの対象はConoHa WING公式、復元に必要なものはWordPress公式でも確認できます。
コメント