---
title: 運用と保守
description: WordPress サイトの本番環境の設定、管理画面のアカウント、本体とプラグインのアップデート、バックアップ、データベースの移行
---

WordPress は公開後も本体・プラグインのアップデートが続くため、公開時の設定と、公開後の保守の手順を決めておきます。

テーマのデプロイは、GitHub Actions からテーマのディレクトリだけを配信します（[レンタルサーバーへのデプロイ](/deploy-release/deploy#レンタルサーバーへのデプロイ)）。
FTP でのテーマのアップロードや、管理画面のテーマエディターでの編集はしません。

## 本番環境の wp-config.php

本番環境の `wp-config.php` では、次の値を設定します。

```php wp-config.php
define("WP_ENVIRONMENT_TYPE", "production");
define("WP_DEBUG", false);
define("SCRIPT_DEBUG", false);

// 管理画面からテーマ・プラグインのファイルを編集できないようにする
define("DISALLOW_FILE_EDIT", true);
```

- **`WP_ENVIRONMENT_TYPE`**：wp-env-starter のテーマは、この値が `local` のときだけ Vite の開発サーバーを参照し、Mailpit へメールを送る。開発環境の値のまま本番に置くと、メールが届かないなどの原因になる
- **`WP_DEBUG`**：`true` のままだと、PHP のエラーやファイルのパスが画面に表示される
- **`DISALLOW_FILE_EDIT`**：テーマは Git で管理しているため、管理画面から編集すると Git の内容とずれる。次のデプロイで上書きされ、変更が消える

ステージング環境では `WP_ENVIRONMENT_TYPE` を `staging` にします。
ステージング環境のアクセス制限と noindex は、[デプロイ](/deploy-release/deploy#環境の分離)のルールに従います。

## 管理画面のアカウント

- **アカウントは 1 人 1 つ**：複数人で 1 つのアカウントを共有しない。誰がいつ何を変更したかを追えなくなり、退職や担当交代のときにパスワードを変更する範囲も広がる
- **ユーザー名に `admin` を使わない**：不正ログインの試行で最初に狙われる
- **権限は必要最小限**：記事を更新するだけのクライアントの担当者には「編集者」を割り当て、「管理者」は保守を担当する人に限る
- **2 段階認証**：管理者のアカウントには、セキュリティプラグインなどで 2 段階認証を設定する

## アップデート

WordPress 本体のマイナーアップデート（7.0.1 → 7.0.2 など、主にセキュリティ修正）は、WordPress の自動更新に任せます。

メジャーアップデートとプラグインのアップデートは、次の順で行います。

1. 本番環境のバックアップを取る
2. ステージング環境（または開発環境）でアップデートし、主要なページとフォームの送信を確認する
3. 問題がなければ、本番環境でアップデートする

プラグインの脆弱性が公表された場合は、この順を待たずに本番環境を更新します。
脆弱性情報は、[WPScan](https://wpscan.com/) や [Wordfence Intelligence](https://www.wordfence.com/threat-intel/) で確認できます。

開発環境の WordPress のバージョンは、`.wp-env.json` の `core` で指定します。
本番環境をメジャーアップデートしたら、`.wp-env.json` も同じバージョンに揃えてください。

## バックアップ

ファイル（`wp-content/uploads` など）とデータベースの両方を、定期的にバックアップします。
バックアップは、サーバーの外にも保存します。
サーバーの自動バックアップだけでは外に保存できない場合は、バックアップ用のプラグイン（[標準のプラグイン](/wordpress/plugins#標準で入れるプラグイン)）と組み合わせます。
同じサーバーの中にしかバックアップがないと、サーバーの障害やアカウントの乗っ取りでバックアップも一緒に失われるためです。

バックアップは、取得するだけでなく復元できることを確認します。
公開前に一度、ステージング環境などに復元して、サイトが表示されることを確かめてください。

## データベースの移行

開発環境・ステージング環境・本番環境のあいだでデータベースを移すときは、シリアライズされた値に対応したツールで URL を置換します。
wp-env では WP-CLI の `wp search-replace` を使います。
WP-CLI を使えないサーバーでは、[Better Search Replace](https://ja.wordpress.org/plugins/better-search-replace/) などのプラグインを使います。

```sh
# 開発環境（wp-env）で本番のデータベースを読み込む場合
pnpm import:db ./sql/backup-YYYYMMDD.sql
pnpm wp-env run cli wp search-replace "https://example.com" "http://localhost:8888" --all-tables
```

:::danger[SQL ファイルをテキストエディターで置換しない]
WordPress は、ウィジェットやプラグインの設定などを PHP のシリアライズ形式で保存しています。
シリアライズされた値には文字列の長さが含まれるため、SQL ファイルの URL をテキストとして置換すると長さが合わなくなり、設定が読み込めなくなります。
`wp search-replace` などのツールは、シリアライズされた値の長さも合わせて書き換えます。
:::

データベースのダンプ（`sql/`）には、ユーザーのメールアドレスやフォームの送信内容などの個人情報が含まれる場合があります。
wp-env-starter では `sql/` を Git の管理から外しています。
ダンプをコミットしたり、チャットツールに添付したりしないでください。