自前サーバで作るWordPressローカル環境：WPvividで丸ごとミラー＆復元

(更新日: 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など。)

サイトが丸ごとローカルサイトにミラーされるため、ユーザーやパスワードまでミラーリングされる。ログインしなおしが必要。

以下はローカル環境で動かすための手順。

プラグインの無効化

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

参考リンク

• ユーザ毎のウェブディレクトリ – Apache HTTP サーバ バージョン 2.4
• mod_rewrite – Apache HTTP Server Version 2.4