(更新日: 2025年8月25日 )
目次
はじめに
このサイトのバックアップを検討した。
“Local by Flywheel”という(なんだか紛らわしい)名前のローカルテスト環境もあるが、自分の場合は手元にサーバーマシンもあるから、こちらを流用したい。
なお以下の記事では「ローカル」は自前サーバを意味する。
最初はデータベースやテーマなどを手動でダウンロードしてトライした。けれども、結局うまく動かずプラグイン(WPvivd)を使った。
ローカルマシンへのパッケージのインストール
ローカルマシンの環境はDebianである。Apache2が既に稼動しているので、その上でWordPressを動かす。
以下のようにして php関連をインストールする:
sudo apt-get install php8.2 php8.2-cli php8.2-common php8.2-imap php8.2-redis php8.2-snmp php8.2-xml php8.2-mysql php8.2-zip php8.2-mbstring php8.2-curl libapache2-mod-php
など。
phpを動かす設定
Apache2でphpを動かすには以下の二つのやり方がある:
- libapache2-mod-php で動かす(シンプル)
- php-fpm で動かす(推奨構成)
今回はlibapache2-mod-php (モジュール)で動かすことにした。
ユーザーのpublic_htmlで稼動させたいので、/etc/apache2/mods-available/php8.2.conf
の最後の部分をコメントアウトした:
# Using (?:pattern) instead of (pattern) is a small optimization that
# avoid capturing the matching pattern (as $1) which isn't used here
<FilesMatch ".+\.ph(?:ar|p|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps$">
SetHandler application/x-httpd-php-source
# Deny access to raw php sources by default
# To re-enable it's recommended to enable access to the files
# only in specific virtual host or directory
Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(?:ar|p|ps|tml)$">
Require all denied
</FilesMatch>
# Running PHP scripts in user directories is disabled by default
#
# To re-enable PHP in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
#<IfModule mod_userdir.c>
# <Directory /home/*/public_html>
# php_admin_flag engine Off
# </Directory>
#</IfModule>
userdir, rewriteを有効化
userdir, rewriteを有効化する:
sudo a2enmod userdir rewrite sudo systemctl restart apache2
userdir.conf
/etc/apache2/mods-available/userdir.conf など
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
# .htaccess から Options/Rewrite 等を使えるようにする
# (迷ったら All でOK/ローカルなので許容)
AllowOverride All
# ベースの動作はここで決めておく(WP向けに MultiViews は無効)
Options -MultiViews -Indexes +SymLinksIfOwnerMatch +IncludesNoExec
# アクセス制御はローカル開発なら緩めでOK
Require all granted
# もし制限したければ例:
# Require ip 127.0.0.1 192.168.10.0/24
</Directory>
“Options”は “-“か”+”で始めないとエラーになるので注意。
データベースの準備
mariadbのインストール
mariadbがインストールされていなければインストールする。
sudo apt update sudo apt install mariadb-server sudo systemctl enable --now mariadb sudo mysql_secure_installation
max_allowed_packet
を設定
デフォルトのmax_allowed_packet
は16MBなので、WPvivid は GLOBALのpacketサイズを 32MB に上げようとして失敗する。
これを引き上げておくとエラーを出さない。
/etc/mysql/mariadb.conf.d/50-server.cnf
の一行を編集する(推奨は128-256M):
max_allowed_packet = 256M
必要に応じてクライアント側も上げておく:
mysql --max_allowed_packet=128M -u wp_local -p
データベースの作成
データベース名: db_wp_local、ユーザ名: wp_local
データベースとユーザを作成する:
sudo mysql -u root
CREATE USER 'wp_local'@'localhost' IDENTIFIED BY '強いパスワード';
CREATE DATABASE db_wp_local CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL PRIVILEGES ON db_wp_local.* TO 'wp_local'@'localhost';
FLUSH PRIVILEGES;
Apache2の設定
WordPress本体のインストール
ダウンロード – WordPress.org 日本語からダウンロードする。
私の場合は~/public_html/WordPress/に展開した。
あとはhttp://localhost/~{USER}/WordPress/
にブラウザからアクセスするとインストーラーの画面になる。({USER}は自分のユーザー名に置き換える。)
「wp-config.phpに書き込みできませんでした」とのエラーが出た
wp-config-sample.php
をwp-config.php
にコピーして、内容をペースト。
基本的に上のデータベースの設定。
フォルダの所有者・パーミッションの変更
自分の場合は~/public_html/WordPress
のようにフォルダにインストールした。
この場合、apacheが書き込みできないとWordPressが正常に動作しない。
グループに自分を追加
({USER}は自分のユーザー名に置き換える。)
sudo usermod -aG www-data {USER}
として自分をwww-dataグループに追加する。
パーミッションの変更
# ディレクトリ: g+w を維持するため setgid、ファイル: 664
({USER}は自分のユーザー名に置き換える。)
sudo find /home/{USER}/public_html/WordPress -type d -exec chmod 2775 {} \; sudo find /home/{USER}/public_html/WordPress -type f -exec chmod 664 {} \;
それからWordPressのフォルダで以下を実行する:
chgrp -R www-data /home/{USER}/public_html/WordPress/wp-content chmod -R g+w /home/{USER}/public_html/WordPress/wp-content
バックアップとローカルサイトでの復旧
バックアップとローカルサイトでの復旧にはWPvividを使った。
(参考になるのは WordPressの引っ越しに「All in One WP migration」を使うのは止めようと思った話 | PCでお困りの方にぜひ読んでいただきたいブログです | 常滑市にてPC修理を手掛けるあいちパソコンクリニックや【無料で容量制限無し】WordPressサイトのバックアップ&移行(コピー)に便利なプラグイン「WPvivid」 | ワードプレステーマTCDなど。)
サイトが丸ごとローカルサイトにミラーされるため、ユーザーやパスワードまでミラーリングされる。ログインしなおしが必要。
以下はローカル環境で動かすための手順。
プラグインの無効化
私はAIOWPS(All In One WP Security)を使っている。これが悪さをするので、無効化する。mv wp-content/plugins/all-in-one-wp-security-and-firewall wp-content/plugins/aiowps.off 2>/dev/null
.htaccessの編集
以下のように整理する ({USER}は自分のユーザー名に置き換える。):
# --- Local dev: /~{USER}/WordPress/ ---
# 保護(Apache 2.4 想定)
<Files ".htaccess">
Require all denied
</Files>
<Files "wp-config.php">
Require all denied
</Files>
<Files "debug.log">
Require all denied
</Files>
# 便利オプション
Options -Indexes
Options -MultiViews
# WordPress(パーマリンク)
<IfModule mod_rewrite.c>
RewriteEngine On
# Basic認証/REST用:AuthorizationヘッダをPHPへ渡す
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /~{USER}/WordPress/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /~{USER}/WordPress/index.php [L]
</IfModule>
この.htaccessがやっていることをまとめると:
- 保護:機密ファイルは
<Files> Require all denied
でブロック。 - 安定化:
Options -Indexes -MultiViews
で露出防止&リライト競合回避。 - ルーティング:UserDir 環境では
RewriteBase
とRewriteRule … index.php
は絶対パスで正確に。 - 前提条件:
mod_rewrite
有効・AllowOverride
設定を適切に。 - トラブル時:エラーログとパーマリンク再保存、AIOWPS の介入に注意。
以下は詳細な説明:
何をしているファイルか(全体像)
- 最小限の防御(機密ファイルへの直アクセス遮断)
- 開発向けの便利オプション(ディレクトリ一覧非表示・MultiViews無効)
- WordPress パーマリンクの中枢(「きれいなURL」を
index.php
に集約するフロントコントローラ)
1) 保護(Apache 2.4)
<Files ".htaccess">
Require all denied
</Files>
<Files "wp-config.php">
Require all denied
</Files>
<Files "debug.log">
Require all denied
</Files>
.htaccess
自身・wp-config.php
・debug.log
へのHTTP直アクセスを完全拒否します。- これらは内容が漏れると致命的(構成やDBパスワード・デバッグ情報)なので、必ず塞ぐのが定石です。
Require all denied
は Apache 2.4 のアクセス制御ディレクティブ。
補足:Apache 2.2 互換ディレクティブ(
Deny from all
等)は不要。2.4 ならこれで十分。
2) 便利オプション
Options -Indexes
Options -MultiViews
-Indexes
:index.php
等が無いディレクトリでファイル一覧を出さない。露出防止。-MultiViews
:拡張子なしURLを似た名前のファイルへ“曖昧マッチ”しない。WordPress は「拡張子なしURL → すべて
index.php
へ渡す」設計なので、MultiViews が有効だと競合し、意図しない 404/ファイル誤マッチを招きやすい → 無効が推奨。
ここが「
.htaccess で Options が使えない」場合の詰まりどころ**その1**。 **AllowOverride** に
Options(または
All)が含まれていないと **“Options not allowed here”** になります。必要なら
userdir.confで
AllowOverride All` にしておこう。
3) WordPress(パーマリンクの心臓部)
<IfModule mod_rewrite.c>
RewriteEngine On
# Basic認証/REST用:AuthorizationヘッダをPHPへ渡す
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /~{USER}/WordPress/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /~{USER}/WordPress/index.php [L]
</IfModule>
役割ごとに
RewriteEngine On
URL書き換えエンジンを有効化。mod_rewrite
が必要。RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Authorization
ヘッダを PHP に渡すおまじない。Basic 認証や REST API で認証ヘッダが読めない環境向けの互換策。
libapache2-mod-php
でも安定化に役立ちます。RewriteBase /~{USER}/WordPress/
リライトの基準パス。UserDir のようにドキュメントルート直下でない場合は必須。 これが/
のままだと、/~{USER}/WordPress/
付きのURLが 404 になりがち。RewriteRule ^index\.php$ - [L]
既にindex.php
を指しているリクエストは触らず終了(無限ループ防止)。RewriteCond %{REQUEST_FILENAME} !-f
/!-d
実ファイル/実ディレクトリが存在しない場合のみ、次のルールを適用。 静的ファイルやwp-content/uploads/...
はそのまま配信し、存在しない“きれいなURL”だけを WordPress へ渡す。RewriteRule . /~{USER}/WordPress/index.php [L]
最終フォールバック。あらゆるきれいなURLをindex.php
へ集約し、WordPress(PHP側)に解決させる(カテゴリ・著者・投稿スラッグなど)。
ここが詰まりどころその2。
RewriteBase
や最後のRewriteRule
のパスが合っていないと、投稿リンクが Not Found になります。 UserDir では/~{USER}/サブディレクトリ/
を正確に書くのがポイント。
前提条件(この .htaccess が効くために)
mod_rewrite が有効:
apachectl -M | grep rewrite
で確認。対象ディレクトリの AllowOverride に
FileInfo
(Rewrite
を含む)とできればOptions
が許可されていること。UserDir なら
userdir.conf
例:<Directory /home/*/public_html> AllowOverride All Options -MultiViews -Indexes +SymLinksIfOwnerMatch +IncludesNoExec Require all granted </Directory>
WordPress の [設定]→[パーマリンク] を保存して、内部のリライトルールを最新化(
rewrite flush
)。
ありがちなトラブルと対処
“Options not allowed here” → サーバ側の
<Directory>
でAllowOverride All
またはAllowOverride Options
を付与。 → 面倒なら.htaccess
からOptions
行を一時的に削除して運用も可。“MultiViews でおかしなファイルが出る/404” →
Options -MultiViews
を維持(UserDir 側でも無効化しておくと安全)。/~{USER}/WordPress/<slug>
が 404 →RewriteBase
と最後のRewriteRule
のパス再確認。 →.htaccess
を直した後はApache再起動不要だが、パーマリンクの保存(flush)はおすすめ。AIOWPS 有効化で 403 に戻る → AIOWPS が
/
前提のルールを挿入することがある。UserDir では相対パスを含めて書き換えるか、ローカルでは AIOWPS を無効のままに。
使い分けのヒント
URL から
/WordPress
を消して出したい(アプリは下層のまま)home
を…/~USER
、siteurl
を…/~{USER}/WordPress
に分け、上位ディレクトリにindex.php
を1枚置いてrequire __DIR__.'/WordPress/wp-blog-header.php';
上位に
.htaccess
も配置。必要に応じてRewriteBase /~{USER}/
に調整。
ローカル環境に移行後の確認(トラブル時の確認ポイント)
トラブルはだいたい以下のポイント:
- パーマリンク再保存(リライトルール再生成) (.htaccessなど)
- siteurl / home の整合(/~{USER}/WordPress) (.htaccessなど)
- AIOWPS/Wordfence はローカル無効、.user.ini の auto_prepend_file 痕跡があればコメントアウト
- キャッシュ系ドロップイン(object-cache.php / advanced-cache.php)を一時退避
主なエラーログの場所は次の二箇所: /var/log/apache2/error.log
、wp-content/debug.log