✎ dx:プロジェクト一覧:qr配荷wp:start [COLORS-wiki]

文書の過去の版を開いています。もしこのまま保存すると、この文書が最新となります。

====== 03. 京都 手ぶら観光 QR荷物配送（kyoto-tourism） ======

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

===== 3つの環境 =====

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

==== 検索避け（noindex）の扱い ★事故りやすい ====

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

* **ローカル**: `import-dump` が取り込みのたびに `blog_public=0`（検索避けON）を強制します
* **robots.txt は自動転送しません**（`.rsyncignore` で除外）。環境ごとに手で置いてください。
  物理ファイルの `robots.txt` は WordPress の検索避け設定より優先されるため、
  ステージングに「クロール許可」の robots.txt を配ると検索避けが無効化されます
* **デプロイ後の自動チェック**:
  * 本番が noindex のまま → ワークフローを **失敗**させます
  * ステージングが noindex でない → **警告**を出します

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

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

==== デプロイの安全装置 ====

* 手動実行は **既定が 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/` に**隔離して**置かれます。
ローカルの作りかけを勝手に上書きしないためです。中身を見比べてから反映してください。

----

====== セットアップ（Windows） ======

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

===== 用意するもの（Windows） =====

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

===== 初回セットアップ（Windows） =====

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

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

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

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

===== アクセス先（Windows） =====

===== 日々の操作（Windows） =====

===== 社内LANの別PC・スマホから見る（Windows） =====

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

<code powershell>
.\lan-access.bat
</code>

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

* ネットワークの種類が「**パブリック**」だとファイアウォールに弾かれます。
  設定 > ネットワークとインターネット から「**プライベート**」に変更してください
* PC の IP は DHCP だと変わります。頻繁に見せるなら固定IPか `PC名.local` での運用が楽です

===== 手動でやる場合（Windows） =====

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

----

====== セットアップ（Mac） ======

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

===== 用意するもの（Mac） =====

- **Docker Desktop for Mac** を公式サイトからインストール
   > ★ **Intel版(amd64) と Apple Silicon版(arm64) でインストーラが別です。**
   > `uname -m` の結果が `x86_64` なら Intel、`arm64` なら Apple Silicon。
   > 詳細は後述の「チップの種類について」を参照。
- **Homebrew** が未導入なら [[https://brew.sh/|https://brew.sh/]] の1行を実行
- ターミナルで:

<code bash>
brew install git gh
</code>

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

===== 初回セットアップ（Mac） =====

<code bash>
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
</code>

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

> ### ★ `bash` を付けて実行してください
> スクリプトは Windows からコミットされているため、**実行権限（+x）が付いていません。**
> `./setup.sh` と打つと `Permission denied` になります。
>
> 毎回 `bash` と打つのが面倒なら、最初に一度だけ:
> ```bash
> chmod +x *.sh
> ```
> これで以降は `./setup.sh` でも動きます。

===== アクセス先（Mac） =====

Windows と同じです。

===== 日々の操作（Mac） =====

===== 社内LANの別PC・スマホから見る（Mac） =====

<code bash>
bash lan-access.sh
</code>

表示された `[[http://192.168.x.x:8084/`|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>

使用しているイメージは**両方の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 でよくあるつまずき =====

----

===== Windows / Mac 対応表 =====

同じ処理の、名前が違うだけの一覧です。

中身のロジックは同一です。OS ごとに違うのは次の3点だけ:

----

==== 社内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から直接サーバーへ繋ぐことはありません。

`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つ入っています。

`hadsfree-kyoto` はリポジトリには残っていますが、デプロイ対象外です。
不要になったら削除して push すれば消えます（`--delete` の対象は `kyoto-baggage` のみなので、
サーバー側の他テーマには影響しません）。

==== `kyoto-baggage` の構成 ====

==== この環境で行った修正 ====

----

===== GitHub 連携と自動デプロイ =====

==== 費用：すべて無料の範囲内です ====

1日10回デプロイしても月300分程度なので、上限にはまず当たりません。

**Environments 機能は使っていません。**
プライベートリポジトリで Environments や Required reviewers を使うには
GitHub Pro 以上が必要になるため、代わりに **リポジトリ Secrets** で
ステージング/本番を出し分ける方式にしてあります。機能的な不足はありません。

> 万一 2,000分を超えそうな場合は、自分のPCを **セルフホストランナー**にすれば
> 実行時間は無制限・無料になります（設定は追加で対応可能）。

==== 準備するのは2つだけ ====

==== ★ 先に Xserver 側で必ず確認すること ====

サーバーパネル > **SSH設定** で:

- SSH が **ON** になっている
- **国外アクセス制限が OFF** になっている

> GitHub Actions の実行サーバーは海外にあります。国外アクセス制限が ON のままだと
> デプロイ時の SSH 接続がブロックされ、必ず失敗します。

==== ホスト名の形式（サービスで違います） ====

この案件は **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|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` が自動で入れるので手作業は不要ですが、中身は以下です。

> 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|https://github.com/Colors-ryomorita/qrset/actions]] で確認できます。

----

==== ★ 最重要：Git に乗るもの / 乗らないもの ====

ここを取り違えると「ローカルでは直ったのにサーバーで変わらない」となります。

つまり **Git が運ぶのは「コード」だけ**です。
**「コンテンツ」（DBとuploads）は運ばれません。**

----

==== ケース別の手順 ====

=== ① テーマのPHP・CSS・JSを直した ===

いちばん普通のケースです。VSCode などで直接編集します。

<code>
C:\Docker-work\kyoto-tourism\src\wp-content\themes\kyoto-baggage\
</code>

このフォルダはコンテナにそのままマウントされているので、**保存した瞬間に [[http://localhost:8084|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://github.com/Colors-ryomorita/qrset/actions]] で緑チェックになっているか
- [[https://qrset.colors-pro.co.jp/|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）に届きます。|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>

編集の概要

注意：本ページを編集した場合、あなたの編集した内容が次のライセンスに従うことに同意したものとみなします： CC0 1.0 Universal