ローカルのフォルダ名は `kyoto-tourism`、リポジトリ名は `qrset` です。一致していなくても問題ありません。

`main` に push すると ステージングにだけ自動反映されます。 本番へは Actions から手動で `target = production` を選んだときのみ反映されます。

ステージングは検索避け ON、本番は OFF。これが取り違わると事故になるため、次の対策を入れてあります。

* ローカル: `import-dump` が取り込みのたびに `blog_public=0`（検索避けON）を強制します * robots.txt は自動転送しません（`.rsyncignore` で除外）。環境ごとに手で置いてください。

物理ファイルの `robots.txt` は WordPress の検索避け設定より優先されるため、
ステージングに「クロール許可」の robots.txt を配ると検索避けが無効化されます

* デプロイ後の自動チェック:

• 本番が noindex のまま → ワークフローを 失敗させます
• ステージングが noindex でない → 警告を出します

ステージングのDBを本番へ流用する場合は、必ずこの確認を。

wp option get blog_public     # 0=検索避けON / 1=公開
wp option update blog_public 1   # 本番公開時

* 手動実行は 既定が dry-run。転送されるファイル一覧だけ出ます * `.htaccess` などトップ階層は 既定では転送しません（`deploy_root` を ON にしたときだけ） * `wp-config.php` / WordPress本体 / `uploads` / `robots.txt` は転送対象外 * 反映先ディレクトリの存在を事前確認、反映後に応答コードと noindex を確認 * `main` への push はステージングにしか行きません。本番は手動実行でしか反映されません

DBは先に `docker/dbdump/stg.sql`（または `prd.sql`）を置いてから実行します。

取り込んだテーマは `_remote/<環境>/themes/` に隔離して置かれます。 ローカルの作りかけを勝手に上書きしないためです。中身を見比べてから反映してください。

Mac の方は次章「セットアップ（Mac）」へ。両者は独立しているので、
自分のOSの章だけ読めば環境が立ち上がります。

SSH鍵は不要です。 理由は後述の「SSH鍵について（共通）」に書いています。

cd C:\Docker-work
git clone https://github.com/Colors-ryomorita/qrset.git kyoto-tourism
cd kyoto-tourism
copy .env.example .env
.\setup.bat

`setup.bat` はエクスプローラでダブルクリックしてもOKです。

コンテナ起動 → WordPressインストール → 日本語化 → テーマ有効化 → パーマリンク設定まで 一気に終わり、ブラウザが開きます。初回はイメージ取得で 5〜10 分ほど。 2回目以降に実行しても壊れません（済んでいる処理はスキップされます）。

`.env.example` のローカル用の値はそのまま使えます（ポート・DB・テーマ名）。 `STG_*` は `SERVERID` のままで構いません。

`lan-access.bat` を 管理者として実行すると、アクセス用URLの表示と Windows ファイアウォールの許可までまとめてやります。

.\lan-access.bat

表示された `http://192.168.x.x:8084/` のようなURLに、同じネットワークの 別PCやスマホからアクセスできます。

* ネットワークの種類が「パブリック」だとファイアウォールに弾かれます。

設定 > ネットワークとインターネット から「**プライベート**」に変更してください

* PC の IP は DHCP だと変わります。頻繁に見せるなら固定IPか `PC名.local` での運用が楽です

copy .env.example .env
docker compose up -d --build
# → http://localhost:8084 でインストール画面が出るので画面に従う
docker compose exec -u www-data wp wp theme activate kyoto-baggage

Windows の方は前章「セットアップ（Windows）」へ。
やることは Windows と全く同じで、スクリプトの拡張子が `.bat` → `.sh` に変わるだけです。

- Docker Desktop for Mac を公式サイトからインストール

 > ★ **Intel版(amd64) と Apple Silicon版(arm64) でインストーラが別です。**
 > `uname -m` の結果が `x86_64` なら Intel、`arm64` なら Apple Silicon。
 > 詳細は後述の「チップの種類について」を参照。

- Homebrew が未導入なら https://brew.sh/ の1行を実行 - ターミナルで:

brew install git gh

SSH鍵は不要です。 理由は後述の「SSH鍵について（共通）」に書いています。

mkdir -p ~/Docker-work && cd ~/Docker-work
git clone https://github.com/Colors-ryomorita/qrset.git kyoto-tourism
cd kyoto-tourism
cp .env.example .env
bash setup.sh

やっていることは Windows の `setup.bat` と同じで、 コンテナ起動 → WordPressインストール → 日本語化 → テーマ有効化 → パーマリンク設定まで一括、 最後にブラウザが開きます。初回はイメージ取得で 5〜10 分ほど。

### ★ `bash` を付けて実行してください
スクリプトは Windows からコミットされているため、実行権限（+x）が付いていません。
`./setup.sh` と打つと `Permission denied` になります。

毎回 `bash` と打つのが面倒なら、最初に一度だけ:
```bash
chmod +x *.sh
```
これで以降は `./setup.sh` でも動きます。

Windows と同じです。

bash lan-access.sh

表示された `http://192.168.x.x:8084/` に、同じネットワークの別PCやスマホからアクセスできます。

Mac のファイアウォールはポート単位ではなくアプリ単位なので、Windows のような ポート開放の設定は要りません。もし繋がらない場合:

* システム設定 > ネットワーク > ファイアウォール > オプション で

• *Docker / com.docker.backend が「着信接続をブロック」になっていないか確認 * 会社のWi-Fiで「クライアント分離（AP isolation）」が有効だと、 同じWi-Fi内でも端末同士が通信できません。その場合は有線か別のSSIDで ===== チップの種類について（Intel / Apple Silicon） ===== どちらでもそのまま動きます。 `docker-compose.yml` やスクリプトを書き換える必要はありません。 ただし Docker Desktop のインストーラだけは別物なので、ここを間違えないでください。 <code bash> uname -m # x86_64 → Intel / arm64 → Apple Silicon </code> ^Mac^ダウンロードするもの^ | Intel チップ | Docker Desktop for Mac with Intel chip（amd64） | | Apple Silicon（M1〜M4） | Docker Desktop for Mac with Apple silicon（arm64） | 使用しているイメージは両方のCPUに対応しているので、`platform:` の指定は不要です。 ^イメージ^Intel (amd64)^Apple Silicon (arm64)^ | `wordpress:php8.2-apache` | ✅ | ✅ | | `mariadb:10.11` | ✅ | ✅ | | `phpmyadmin:5` | ✅ | ✅ | | `axllent/mailpit` | ✅ | ✅ | ==== Intel Mac で気をつけること ==== ^^内容^ | macOS のバージョン | Docker Desktop がサポートするのは最新＋その前2つのメジャーバージョンまで。古い Intel Mac で macOS を上げられない場合、最新版の Docker Desktop は入りません（旧バージョンを探すことになります） | | メモリ | 最低 4GB。Settings > Resources で 4GB 以上を割り当ててください（WP + MariaDB + phpMyAdmin + Mailpit の4コンテナが動きます） | | Homebrew の場所 | Intel は `/usr/local`、Apple Silicon は `/opt/homebrew`。`brew install gh` のあとに `gh: command not found` が出たら下のコマンドを `~/.zshrc` に追記 | | Rosetta 2 | 不要です（Intel ネイティブのため） | | 速度 | Apple Silicon より遅いので、後述の VirtioFS の設定は実質必須です | <code bash> # Intel Mac で gh / git が見つからない場合 echo 'eval “$(/usr/local/bin/brew shellenv)”' » ~/.zshrc source ~/.zshrc </code> ==== Apple Silicon で気をつけること ==== 特別な設定は要りません。Rosetta 2 は必須ではありませんが、一部のコマンドラインツールが必要とするため入れておくと無難です。 <code bash> softwareupdate –install-rosetta </code> ===== 動作が遅いと感じたら（Mac） ===== macOS はファイル共有がボトルネックになりがちです。 Docker Desktop > Settings > General > VirtioFS が選ばれているか確認してください （gRPC FUSE や osxfs より明確に速いです）。 それでも重い場合は Settings > Resources で CPU / メモリの割り当てを増やしてください （メモリ 4GB 以上を推奨）。 ===== SSH鍵を置いたとき（Mac） ===== `pull-remote.sh` / `import-dump.sh` / `github-setup.sh` を使うときだけ必要です。 Mac では権限を絞らないと ssh が鍵を読み込みません。 <code bash> chmod 600 docker/ssh/xserver.key </code> `github-setup.sh` は実行時に自動で直しますが、手で `ssh` を叩くときは自分で必要です。 （Windows の `icacls` に相当する処理です） ===== Mac でよくあるつまずき ===== ^症状^原因と対処^ | `Permission denied` | `./setup.sh` ではなく `bash setup.sh` で実行 | | `docker: command not found` | Docker Desktop が起動していない。アプリを起動してから再実行 | | `port is already allocated` | 8084 等を他のアプリが使用中。`.env` の `WEB_PORT` を変更 | | `Bad owner or permissions` (ssh) | `chmod 600 docker/ssh/xserver.key` | | ブラウザが自動で開かない | 表示された URL を手でコピーして開けば問題ありません | —- ===== Windows / Mac 対応表 ===== 同じ処理の、名前が違うだけの一覧です。 ^やること^Windows^Mac^ | ローカル環境の起動 | `setup.bat`（ダブルクリック可） | `bash setup.sh` | | GitHub連携＋Secrets登録（初回のみ） | `github-setup.bat` | `bash github-setup.sh` | | サーバーからファイルを取り込む | `pull-remote.bat` | `bash pull-remote.sh` | | サーバーからDBを取り込む | `import-dump.bat` | `bash import-dump.sh` | | 社内LANに公開 | `lan-access.bat`（管理者権限） | `bash lan-access.sh` | | 停止 / 作り直し | `docker compose down` / `down -v` | 同左 | | Git 操作 | `git add -A` → `commit` → `push` | 同左 | 中身のロジックは同一です。OS ごとに違うのは次の3点だけ: ^^Windows^Mac^ | 鍵の権限 | `icacls` | `chmod 600` | | GitHub CLI の導入 | `winget install GitHub.cli` | `brew install gh` | | LAN公開 | ファイアウォールにポート許可を追加 | アプリ単位なので設定不要 | —- ==== 社内LAN公開の仕組み（共通） ==== * `docker-compose.yml` のポート公開は `0.0.0.0` にバインドしてあるので、コンテナ側の設定変更は不要です * WordPress の `WP_HOME` / `WP_SITEURL` は アクセス元のホスト名に自動追従します。 以前は `localhost:8084` 固定だったため、LANのIPで開くと localhost に飛ばされて表示できませんでした * 社外からは見えません。クライアントに見せる場合は Cloudflare Tunnel か ngrok を使います（別途セットアップ可能） —- ===== SSH鍵について（共通） ===== ==== 参加するだけなら SSH鍵は要りません ==== デプロイは GitHub のサーバーが実行し、認証には GitHub Secrets に登録済みの鍵を使います。 参加者のPCから直接サーバーへ繋ぐことはありません。 ^やること^SSH鍵が必要？^ | ローカルでWP起動・テーマ編集 | ❌ 不要 | | `git push` でサーバーへ反映 | ❌ 不要（GitHub Secrets を使用） | | `pull-remote` / `import-dump` | ✅ 必要 | `github-setup` を実行する必要もありません（Secrets 登録済みのため）。 ==== サーバーからファイルを取り込みたくなったら ==== そのときだけ SSH鍵が必要です。既存の鍵を共有せず、参加者ごとに新しい鍵を発行してください。 - Xserver サーバーパネル > SSH設定 > 公開鍵を登録（パスフレーズは「設定しない」） - ダウンロードした `.key` を `docker/ssh/xserver.key` として保存 - `.env` の `STG_HOST` / `STG_USER` / `STG_PATH` を実際の値に書き換え - Mac のみ: `chmod 600 docker/ssh/xserver.key` Xserver は公開鍵を複数登録できます。人ごとに分けておくと、 離任時にその鍵だけ削除すれば済み、他の人に影響しません。 > 秘密鍵をリポジトリに置かないでください。 private でも一度コミットすると履歴に永久に残り、 > あとから参加した人も過去のコミットから取り出せてしまいます。 > どうしても渡す必要がある場合は 1Password / Bitwarden の共有機能などを使ってください。 —- ===== ディレクトリ ===== <code> kyoto-tourism\ ├── setup.bat / setup.sh ← 初回セットアップ一括実行 ├── github-setup.bat / .sh ← GitHub連携＋Secrets登録＋初回push ├── lan-access.bat / .sh ← 社内LAN公開の設定 ├── pull-remote.bat / .sh ← リモートのファイルを取り込む ├── import-dump.bat / .sh ← リモートのDBを取り込む │ ※ .bat = Windows / .sh = Mac・Linux（中身は同じ） ├── src\ ← ここだけが Git 管理＆サーバへ反映される │ ├── .htaccess / .user.ini / robots.txt ← robots.txt は自動転送しない │ └── wp-content\ │ ├── themes\kyoto-baggage\ ← ★デプロイ対象はこちら │ │ ├── functions.php │ │ ├── function\ (acf / api / booking / db / mail / slots …) │ │ ├── page-booking.php / page-status.php / page-contact.php │ │ ├── single-pickup_location.php / archive-pickup_location.php │ │ ├── css\ / js\ / img\ │ │ └── style.css │ ├── themes\hadsfree-kyoto\ ← 旧・作りかけ（未使用） │ └── plugins\ (ACF PRO / Classic Editor / Site Kit …) ├── docker\ ← ローカル専用（本番へは転送されない） │ ├── php\Dockerfile / php.ini / xdebug.ini │ ├── ssh\ ← SSH秘密鍵の置き場（Git管理外） │ ├── dbdump\ ← DBダンプ置き場（Git管理外） │ ├── wp\mu-plugins\00-local-dev.php ← Mailpit連携・LOCALバッジ │ └── initdb\ ← 初回起動時に流すSQL ├── storage\uploads\ ← ローカルのアップロード（Git管理外） ├── _remote\ ← リモートから取り込んだ確認用（Git管理外） ├── docker-compose.yml ├── .env / .env.example ├── .rsyncignore └── .github\workflows\deploy.yml </code> WordPress 本体（wp-admin / wp-includes / wp-*.php）は Git に入れません。 Docker では名前付きボリュームに公式イメージが展開され、サーバ側では既存の WP をそのまま使います。 —- ===== テーマについて（引き継ぎメモ） ===== `src\wp-content\themes\` にテーマが2つ入っています。 ^テーマ^状態^ | `kyoto-baggage` | 稼働中。デプロイ対象。 PHP 27ファイル、予約・QR・スポット管理・メール等が実装済み | | `hadsfree-kyoto` | 旧・作りかけ。`inc\` 配下の9ファイルが0バイトの空。未使用 | `hadsfree-kyoto` はリポジトリには残っていますが、デプロイ対象外です。 不要になったら削除して push すれば消えます（`–delete` の対象は `kyoto-baggage` のみなので、 サーバー側の他テーマには影響しません）。 ==== `kyoto-baggage` の構成 ==== ^ファイル^役割^ | `function\acf.php` | ACFフィールド定義（GUIではなくPHPで定義） | | `function\booking.php` | 予約処理 | | `function\api.php` | REST API | | `function\db.php` | テーブル作成・DB操作 | | `function\slots.php` | 予約枠 | | `function\mail.php` | メール送信 | | `function\roles.php` / `login.php` / `admin.php` | 権限・管理画面 | | `page-booking.php` / `page-status.php` / `page-contact.php` | 固定ページ用テンプレート | | `single-pickup_location.php` / `archive-pickup_location.php` | 受取スポット | ==== この環境で行った修正 ==== ^内容^対応^ | 日本語サイトに必須の `mbstring` 拡張がイメージに無かった | Dockerfile で導入 | | `hadsfree-kyoto` の `functions.php` が存在しないファイルを `require_once` していて致命的エラー | 空の受け皿を作成（現在は未使用テーマ） | | GitHub Actions で `ssh-rsa` 署名が拒否される可能性 | `deploy.yml` で明示的に許可 | —- ===== GitHub 連携と自動デプロイ ===== ==== 費用：すべて無料の範囲内です ==== ^項目^GitHub Free プラン^この案件での使用量^ | プライベートリポジトリ | 無制限・無料 | 1つ | | GitHub Actions（private） | 月 2,000分（Linux） | 1回あたり約1分 | | リポジトリ Secrets | 無料・無制限 | 7つ | 1日10回デプロイしても月300分程度なので、上限にはまず当たりません。 Environments 機能は使っていません。 プライベートリポジトリで Environments や Required reviewers を使うには GitHub Pro 以上が必要になるため、代わりに リポジトリ Secrets で ステージング/本番を出し分ける方式にしてあります。機能的な不足はありません。 > 万一 2,000分を超えそうな場合は、自分のPCを セルフホストランナーにすれば > 実行時間は無制限・無料になります（設定は追加で対応可能）。 ==== 準備するのは2つだけ ==== ==== ★ 先に Xserver 側で必ず確認すること ==== サーバーパネル > SSH設定 で: - SSH が ON になっている - 国外アクセス制限が OFF になっている > GitHub Actions の実行サーバーは海外にあります。国外アクセス制限が ON のままだと > デプロイ時の SSH 接続がブロックされ、必ず失敗します。 ==== ホスト名の形式（サービスで違います） ==== ^サービス^SSHホスト名^ | XServerビジネス | `<サーバーID>.xbiz.jp`（`sv*.xbiz.ne.jp` でも可） |

| 通常のエックスサーバー | `<サーバーID>.xsrv.jp`（`sv*.xserver.jp` でも可） | この案件は XServerビジネス なので `colorspro.xbiz.jp` です。 ポートはどちらも 10022。 ① `.env` のサーバ情報を埋める <code> STG_HOST=colorspro.xbiz.jp STG_USER=colorspro STG_PATH=/home/colorspro/colors-pro.co.jp/public_html/qrset </code> `STG_PATH` が分からなければ、SSHして確認します。 <code bash> ssh -p 10022 colorspro@colorspro.xbiz.jp ls -d ~/colors-pro.co.jp/public_html/* </code> ② SSH秘密鍵を置く Xserver サーバーパネル > SSH設定 で - 「ONにする」で SSH を有効化 - 「公開鍵認証用鍵ペアの生成」→ 鍵をダウンロード ダウンロードした `<サーバーID>.key` を `docker\ssh\xserver.key` という名前で保存。 ==== あとはダブルクリックするだけ ==== <code powershell> .\github-setup.bat # Windows </code> <code bash> bash github-setup.sh # Mac / Linux </code> このスクリプトが自動でやること: - `git` / `gh`（GitHub CLI）の確認 - GitHub へのログイン（未ログインならブラウザが開く） - リポジトリ `Colors-ryomorita/qrset` の作成 or 接続 - `ssh-keyscan` でサーバのホスト鍵を取得 - Secrets を7つ自動登録（手作業でのコピペ不要） - コミット対象を表示して確認 → 初回 push - Actions のページをブラウザで開く `.env` や SSH秘密鍵がコミット対象に入っていたら、その場で中止する安全弁も入れてあります。 > GitHub CLI が未インストールなら、 > Windows: 管理者権限のPowerShellで `winget install –id GitHub.cli` > Mac: `brew install gh` > を実行してから再度どうぞ。 ==== 初回デプロイ ==== - https://github.com/Colors-ryomorita/qrset/actions を開く - 左の Deploy > 右上の Run workflow - `target` = `staging`、`dry_run` にチェックを入れたまま実行 → 転送されるファイル一覧だけが出ます - 意図しないファイルが無ければ、`dry_run` のチェックを外して再実行 - 以降は `git push` するだけで自動反映されます ==== 登録される Secrets ==== `github-setup.bat` / `github-setup.sh` が自動で入れるので手作業は不要ですが、中身は以下です。 ^Secret 名^内容^ | `SSH_HOST` | `.env` の `STG_HOST` | | `SSH_PORT` | `.env` の `STG_PORT`（既定 10022） | | `SSH_USER` | `.env` の `STG_USER` | | `SSH_KEY` | `docker\ssh\xserver.key` の中身 | | `SSH_KNOWN_HOSTS` | `ssh-keyscan` の出力 | | `DEPLOY_PATH` | `.env` の `STG_PATH` | | `SITE_URL` | `.env` の `STG_URL` | > GitHub Environments は使っていません。プライベートリポジトリで > Environments を使うには GitHub Pro 以上が必要なためです。 ==== 本番ドメインが決まったら ==== 同じ7つを `PRD_` を付けて追加登録するだけです。ワークフローの書き換えは不要。 <code powershell> gh secret set PRD_SSH_HOST –body “colorspro.xbiz.jp” –repo Colors-ryomorita/qrset gh secret set PRD_DEPLOY_PATH –body “/home/…/public_html” –repo Colors-ryomorita/qrset gh secret set PRD_SITE_URL –body “https:本番ドメイン” –repo Colors-ryomorita/qrset gh secret set PRD_SSH_KEY –repo Colors-ryomorita/qrset < docker\ssh\xserver.key # PRD_SSH_PORT / PRD_SSH_USER / PRD_SSH_KNOWN_HOSTS も同様 </code> 登録後は Run workflow で `target` = `production` を選べば本番へ反映されます。 `main` への push はステージングにしか行かないので、誤爆しません。 —- ===== 日々の作業フロー（ローカルで編集 → push → 反映） ===== ==== いちばん短い形 ==== <code powershell> cd C:\Docker-work\kyoto-tourism git add -A git commit -m “予約フォームの調整” git push </code> これだけで GitHub Actions が動き、数十秒で qrset に反映されます。 進行状況は https://github.com/Colors-ryomorita/qrset/actions で確認できます。 —- ==== ★ 最重要：Git に乗るもの / 乗らないもの ==== ここを取り違えると「ローカルでは直ったのにサーバーで変わらない」となります。 ^編集した場所^Git に乗る？^サーバーへ反映される？^ | `src\wp-content\themes\kyoto-baggage\` の中のファイル | ✅ | ✅ push で自動 | | `src\wp-content\plugins\` の中のファイル | ✅ | ✅ push で自動 | | `src\.htaccess` / `.user.ini` | ✅ | ⚠️ 手動実行で `deploy_root` を ON にしたときだけ | | WordPress管理画面で作った投稿・固定ページ・メニュー | ❌ | ❌ DBの中身なので運ばれません | | ACFのフィールドグループ設定 | ❌ | ❌ 同上（対処法は下に記載） | | 管理画面 > 設定 の各種オプション | ❌ | ❌ 同上 | | メディアライブラリにアップした画像 | ❌ | ❌ `storage\uploads\` は Git 管理外 | | WordPress 本体（wp-admin など） | ❌ | ❌ サーバー側のものをそのまま使用 | つまり Git が運ぶのは「コード」だけです。 「コンテンツ」（DBとuploads）は運ばれません。 —- ==== ケース別の手順 ==== === ① テーマのPHP・CSS・JSを直した === いちばん普通のケースです。VSCode などで直接編集します。 <code> C:\Docker-work\kyoto-tourism\src\wp-content\themes\kyoto-baggage\ </code> このフォルダはコンテナにそのままマウントされているので、保存した瞬間に http://localhost:8084 に反映されます。ビルドも再起動も不要です。 <code powershell> # 動作確認できたら git add -A git status # 何が変わったか確認 git commit -m “予約フォームのバリデーションを追加” git push </code> > WordPress管理画面の「テーマファイルエディター」は無効化してあります（`DISALLOW_FILE_EDIT`）。 > コンテナ内で直接編集すると Git に乗らないため、必ずホストPC側（Windows / Mac）のファイルを編集してください。 === ② 管理画面からプラグインを入れた／更新した === 管理画面 > プラグイン > 新規追加 でインストールすると、 実体は `src\wp-content\plugins\` に落ちてくるので そのまま Git 管理対象になります。 <code powershell> git status # 新しいプラグインのフォルダが出るはず git add -A git commit -m “Contact Form 7 を追加” git push </code> 反映後、サーバー側の管理画面で有効化してください。有効/無効の状態はDBなので運ばれません。 === ③ ACF のフィールドを追加・変更したい === このテーマは ACFのフィールドを PHP で定義しています。 <code> src\wp-content\themes\kyoto-baggage\function\acf.php </code> そのため 管理画面のGUIではなく、このファイルを編集します。編集すればただのコードなので、 普通に `git push` すればサーバーにも反映されます。DBを介さないので取りこぼしがありません。 > `function\acf.php` の冒頭コメントに、PHP定義にしている理由が3点書かれています > （Git配布できる / 環境間でフィールドキーがずれない / テーマ入れ替えで定義も入れ替わる）。 注意: 管理画面 > ACF > フィールドグループ からGUIで作ったものはDBに入り、 `git push` では運ばれません。GUIで試作した場合は、管理画面 > ACF > ツール > エクスポート で「PHPを生成」し、その内容を `function\acf.php` に貼り付けてください。 === ④ 投稿・固定ページ・設定を変えた === これは push では運べません。 サーバー側の管理画面で同じ操作をしてください。 大量にある場合は、ローカルのDBを書き出してサーバーに取り込む形になります（サイト全体の入れ替えになるので、慎重に）。 <code powershell> # ローカルDBを書き出す docker compose exec -u www-data wp wp db export /opt/project/docker/dbdump/local.sql </code> 逆に サーバーの内容をローカルに持ってくるのは用意してあります。 <code powershell> .\pull-remote.bat # テーマ・プラグイン・uploads （Mac: bash pull-remote.sh） .\import-dump.bat # DB（docker\dbdump\stg.sql を置いてから）（Mac: bash import-dump.sh） </code> —- ==== push する前のチェック ==== <code powershell> git status # 意図しないファイルが入っていないか git diff # 変更内容そのもの </code> `.env` と `docker\ssh\xserver.key` は `.gitignore` で除外済みですが、 新しく秘密情報を扱うファイルを作ったときは、先に `.gitignore` へ追加してください。 ==== 反映されたか確認する ==== - https://github.com/Colors-ryomorita/qrset/actions で緑チェックになっているか - https://qrset.colors-pro.co.jp/ を Ctrl + F5（キャッシュを無視して再読み込み） CSSやJSが古いままのときは、テーマ側で `wp_enqueue_style` にバージョン番号を付けると確実です。 ==== やり直したいとき ==== <code powershell> git log –oneline -10 # 履歴を見る git revert <コミットID> # 特定の変更を打ち消す（履歴は残る） git push # → 打ち消した状態がサーバーにも反映 </code> `git reset –hard` は履歴を壊すので、共有リポジトリでは `revert` を使ってください。 —- ===== 想定される依存プラグイン ===== `inc/spot/spot-acf.php` があるため ACF（Advanced Custom Fields） が必要になるはずです。 <code powershell> docker compose exec -u www-data wp wp plugin install advanced-custom-fields –activate </code> インストールしたプラグインは `src/wp-content/plugins/` に入り、そのまま Git 管理対象になります。 —- ===== メール確認 ===== `wp_mail()` は実送信されず、すべて Mailpit（http://localhost:8027）に届きます。 この仕組みは `docker/wp/mu-plugins/00-local-dev.php` によるもので、本番には配置されません。 ===== DeepL などの API キー ===== コードに直書きせず `wp-config.php` の `define()` か環境変数で持ってください （`wp-config.php` は Git にもデプロイにも含まれない設定にしてあります）。 ローカルで試すだけなら `docker/wp/mu-plugins/10-local-secrets.php` を作って `define()` すれば OK です。 このフォルダは本番へ転送されません。 ===== よく使う WP-CLI ===== <code powershell> docker compose exec -u www-data wp wp theme list docker compose exec -u www-data wp wp plugin list docker compose exec -u www-data wp wp option update blogname “HandsFree Kyoto” docker compose exec -u www-data wp wp search-replace 'http://localhost:8084' 'https:本番ドメイン' –dry-run </code> ===== ログの見かた ===== <code powershell> docker compose logs -f wp docker compose exec wp tail -f /var/www/html/wp-content/debug.log </code>