WordPress で問題解決へレイヤー層別、原因の発見方法

WordPressでの問題について、効率よく原因特定する手順について考えている。
レイヤーに分けて考えることができる。
図のように、下のレイヤーは上のレイヤーに影響を与えることができる。
問題は、どのレイヤー（層）の出来事なのか？

そう考えることで、原因特定が早くなる。さあ、順番になぞってみましょう。

OS層

問題の種類

サーバーがダウンしている
サーバーのリソースが不足している (CPU、メモリ、ディスクスペース)
ネットワークの問題

診断方法

サーバーの稼働状況を確認 (uptime、topコマンドなど)
ディスク使用量の確認 (df -hコマンド)
メモリ使用量の確認 (free -mコマンド)
ネットワーク接続の確認 (ping、tracerouteコマンド)

メモ

OSレベルのトラブルは、Xサーバー、さくら、などの有名どころのレンタルサーバーを使用している場合は心配することはありません、もし問題が起きてもサーバー業者が対応します、あなたに出来るのは祈ることのみ。
AWS、GCP、CONOHAなど、VPSというサービスを利用している場合、あなたの設定がOS層の問題の原因となる場合があります。

WEBサーバー層

問題の種類

サーバーが起動していない(VPS)
サーバーの設定ミス
ファイルがFTPでアップロードできない、ディレクトリが見えない
リダイレクトがおかしい
サイトがリダイレクトループに陥り、正しく表示されない
海外からアクセスできない　参考：WordPress (Xサーバー）海外アクセス403を直した

診断方法

サーバーのステータス確認 (Apache: systemctl status apache2、Nginx: systemctl status nginx)
サーバーログの確認 (Apache: /var/log/apache2/error.log、Nginx: /var/log/nginx/error.log)
サーバーの設定ファイルの確認 (Apache: /etc/apache2/apache2.conf、Nginx: /etc/nginx/nginx.conf)
FTPアカウントとパスワードは正しいか？
FTPアカウントがIPアドレス許可制の場合、許可されているか？
独自ドメインを取得している場合、コンテンツルートの指定は正しいか？
ディレクトリのパーミッションの設定が正しいか？
SSL対応する場合、設定が正しいか？
.htaccess の設定は正しいか？

メモ

.htaccess の設定もこの層に含めるとします。
レンタルサーバーではサーバーが起動していない、はほぼありえません。(VPSのみ)
独自ドメイン、SSL化、FTPクライアントでのアクセス　などで起きる問題がこの層の原因が多いです。

リダイレクト関連の問題は .htaccess ファイルの設定が原因であることが多いです。
PHP.ini への設定内容を .htaccess に記述することもあり、PHP層の問題の原因が.htaccess である場合もあります。

.htaccess ファイルの基本構成例

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# カスタムリダイレクト設定例
# 恒久的なリダイレクト
RewriteRule ^old-page$ /new-page [R=301,L]

# HTTPS 強制リダイレクト
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# トレーリングスラッシュを追加
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

PHP層

問題の種類

PHPの設定エラー
PHPバージョンの不一致
PHPモジュールの不足
PHPバージョンアップで、白紙になった、エラーメッセージが出た、一部の機能が使えなくなった。

診断方法

PHPのエラーログの確認 (/var/log/php_errors.log)
PHPの設定確認 (phpinfo()関数を使用)
必要なPHPモジュールがインストールされているか確認 (php -mコマンド)

※PHPのバージョンアップで「白紙になった、エラーメッセージが出た、一部の機能が使えなくなった」はPHP層の問題ではなく、Wordpress層、プレグイン層、テーマ層の問題です。

メモ

PHP層の問題の典型は、ファイルアップロードの上限、フォーム送信のデータサイズの上限、が多いです。
All-in-One WP Migration などのバックアップファイルから、サイトをレストアするときにファイルアップロードの上限で困るというものが有名です。

PHPのどのバージョンを実行するのか？の設定方法は、２種のWEBサーバー、Apache と Nginx で異なる。
しかし、これはVPS使用時のみで、一般のレンタルサーバーでは、コントロールパネルでPHPバージョンを設定可能。

一般的なレンタルサーバーの場合では

1. PHPバージョン
2. memory_limit、　post_max_size、　upload_max_filesize
3. キャッシュ設定

などを設定できます。

php.ini の確認

サーバーの php.ini ファイルを開き、設定を確認します。一般的な場所は

/etc/php/7.x/apache2/php.ini や /etc/php/7.x/cli/php.ini です。

設定項目の確認

memory_limit = 256M
post_max_size = 50M
upload_max_filesize = 50M

PHPバージョンの確認:

コマンドラインで php -v を実行して、インストールされているPHPのバージョンを確認
Webサーバー経由で動作するPHPのバージョンを確認するには、phpinfo() 関数を使用

<?php phpinfo(); ?>

PHPのバージョンを変更する

レンタルサーバーの場合は、サーバーコントロールパネルなどと呼ばれている管理画面から設定します。
まれに .htaccess で設定することができるサーバーもあります。

html拡張子のファイルをPHPで動かす

apache

<Directory "${SRVROOT}/htdocs">
  AddHandler php7-script .php .html
  AddType application/x-httpd-php .php .html
</Directory>

<Directory "${SRVROOT}/htdocs">
  AddHandler php-script .php .html
  AddType application/x-httpd-php .php .html
</Directory>

nginx /etc/php-fpm.d/www.conf

security.limit_extensions = .php .php3 .php4 .php5 .php7 .html

WordPress層

問題の種類

Error establishing a database connection エラーが表示される
サイトのURL設定ミスによるリダイレクトループや表示エラー
ファイルやディレクトリの権限が不適切で、WordPressが正常に動作しない
カスタムパーマリンク設定が正しく動作しない
WordPressからのメールが送信されない

診断方法

wp-config.php の確認

データベース接続エラーの診断と解決
データベースの接続情報（DB_NAME, DB_USER, DB_PASSWORD, DB_HOST）が正しいか確認します。

define('DB_NAME', 'database_name');
define('DB_USER', 'database_user');
define('DB_PASSWORD', 'database_password');
define('DB_HOST', 'localhost');

データベースサーバーの確認

MySQLサーバーが起動しているか確認します。(VPS)
MySQLコマンドラインやphpMyAdminでデータベースに接続できるか確認します。

URLの設定ミスの確認

管理画面の「設定」->「一般」で「WordPress アドレス (URL)」と「サイトアドレス (URL)」が正しいか確認します。

データベースのURL確認

wp_options テーブルの siteurl と home の値を確認し、修正します。

権限の問題の確認

ファイルとディレクトリの所有者がWebサーバーのユーザーと一致しているか確認します。
※絶対に一致している必要はありません、運用ケースにより異なります。

chown -R www-data:www-data /path/to/wordpress/

更新の失敗の確認

WordPressの自動更新機能が正しく動作しているか確認します。wp-config.phpに以下の行があるか確認し、なければ追加します。
※絶対にこの値というわけではありません、KUSANAGI環境などでは、異なります。

define('FS_METHOD', 'direct');

サーバー上の一時ファイルディレクトリの書き込み権限を確認します。（VPS）

パーマリンクの問題の確認

管理画面の「設定」->「パーマリンク設定」で、設定を再保存する。

.htaccessファイルの確認

.htaccess ファイルに以下の内容が含まれているか確認します。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

メール送信問題の確認

WordPressのメール設定が正しく設定されているか確認します。
SMTPプラグイン（例: WP Mail SMTP）を使用してSMTPサーバーを設定します。

2024年春ぐらいから、Gmailにメールが不達という問題が増加しています。原因はメール関連のDNSレコード設定です。Wordpress側で対応することはありません。

メモ

WordPress はPHPからMYSQLなどのデータベースにデータを保存します。
データベースへのアクセス情報が定義されている唯一のファイルが　wp-config.php　です。

プラグイン層

問題の種類

WordPressの問題といえばプラグインが原因！という先入観がありませんか？それ、正解です！

プラグインはたいていの場合、間違っていません。プラグインの開発者は一生懸命なのですから。
プラグインの問題は、相性・関係から生じます。

WordPress 本体のバージョンとの相性
PHPのバージョンとの相性
他プラグインとの相性
テーマとの相性
です。

プラグイン本体は何も悪くない、相性が悪いと問題が起きるという厄介です。

プラグイン問題の影響範囲、ほぼ全部

エラーが出たり、白紙になったり、管理画面にログインできなくなったり、考えらえるほぼすべての問題が生じる可能性があります。

サイトが白紙、ログインできない問題

PHPをバージョンアップしたら、サイトが白紙になった、fatal error が出て停止したなどの問題。
プラグイン内のコードがPHPの規約にあっていないからです。

Worpressの起動時のコード読み込み順序

1. WordPress コアの読み込み
2. mu-plugin の読み込み
3. 通常のプラグインの読み込み　※デフォルトではアルファベット順
4. プラグインのアクションフックとフィルターフックの登録
5. テーマの読み込み
   ※子テーマを使用している場合、子テーマのfunctions.phpが親テーマのfunctions.phpよりも先に読み込ま

２，3のところで問題が起きています。

解決方法

FTPクライアントでアクセスして、ディレクトリ・ファイルの名前を変更する

こうすることで、プラグインが起動しなくなります。
複数ある場合、全部を起動しないようにします。
その状態で Worpress が起動するか確かめます、起動したら、ひとつづつプラグインを起動するように戻します。
この手順で、どのプラグインが起動するとエラーを起こすのか確定させることができます。

調査に役立つ wp-configの例

<?php
// デバッグモードを有効にする
define('WP_DEBUG', true);

// デバッグログを有効にする
define('WP_DEBUG_LOG', true);
//すべてのエラーをディレクトリ wp-content 下のログファイル debug.log に保存
//WP_DEBUG_LOG が動作するには WP_DEBUG に true を設定して有効化が必要

// エラーメッセージをブラウザに表示しない
define('WP_DEBUG_DISPLAY', false);

// 圧縮されていないスクリプトを読み込む
define('SCRIPT_DEBUG', true);

// 実行されたデータベースクエリを保存する
define('SAVEQUERIES', true);
//配列はグローバル $wpdb->queries 内に保存、サイトのパフォーマンスに影響を与えます。
//デバッグ時以外は無効化

//このコードはファイル wp-config.php 内の /* That’s all, stop editing! Happy blogging. */ より 前 に挿入

全然終わらないので、途中ですが公開させていただきます。

この後は、テーマ問題編、そして、Asset　css、JS編へと続きます。