技術資料

XAMPPのPHPを更新するとき、バイナリの入れ替えと同じくらい気になるのが、php.iniの設定です。古いファイルをコピーしてよいのか、配布物に付属する設定例から作り直すなら何を見直すのか、迷うところかと思います。

今回は、更新前のphp.iniを保存し、新しいPHPに付属する設定例と比べながら、必要な設定を引き継ぐ手順を整理します。特に注意したい項目と、移行後の確認方法を中心に扱います。

対象はWindowsのXAMPPでPHP 8系を利用する環境です。

更新前に、使用中のphp.iniと有効な設定を保存する

以前のXAMPPのPHP更新記事では、旧php.iniのコピーと、新しい設定例を基に再設定する方法に触れました。コピーしたファイルでも、その内容が新しいPHPやアプリケーションに合っているかは確認が必要です。

まずは更新前の環境で、実際に使っているphp.iniを特定します。PowerShellなら、次のコマンドでCLIの実行先・版・設定ファイル・拡張一覧を確認できます。

Get-Command php -CommandType Application | Select-Object -ExpandProperty Source
php -v
php --ini
php -m

php --iniでは、Loaded Configuration Fileが読み込まれたphp.iniです。Additional .ini files parsedにファイルが出ていれば、追加の設定も読み込まれています。

読み込まれているphp.iniと追加のINIファイルを、更新作業で上書きしない場所へコピーしておきます。あわせて、PHPの版・拡張一覧・設定ファイルのパスを記録します。後述の診断コードも更新前に実行しておけば、更新後と有効値を比べられます。

手元のCLIでは、PHPはC:\xampp\php\php.exe、php.iniはC:\xampp\php\php.iniでした。このパスは環境固有なので、そのまま設定例としてコピーしないでください。

ここまでで分かるのはCLIの環境です。Apacheが別のPHPやphp.iniを使っていることもあるため、Web側も後述の方法で更新前の情報を記録します。TS・NTSの選択と接続方式については、Windows版PHPのTS・NTSとApacheの設定を確認する記事も参照してください。

旧設定と新しい設定例を比較し、引き継ぐ内容を決める

PHPの配布物には、開発向けのphp.ini-developmentと、本番向けのphp.ini-productionという設定例があります。ローカル開発では前者、本番に近い確認では後者を出発点にできます。開発向けの設定例はエラーを画面に表示する設定なので、公開環境へそのまま持ち込まないようにしましょう。

選んだ設定例を作業用にコピーし、旧php.iniとエディターの差分表示などで比較します。いきなり使用中のファイルを置き換えず、次のように項目ごとの扱いを決めてから、新しい環境用のphp.iniへ反映します。

旧php.iniと新しい設定例の差分には、環境に合わせた変更だけでなく、PHPの版や開発用・本番用の方針の違い、コメントの変更も混ざります。差分をすべて旧設定へ戻すのではなく、その値を必要とする理由を確認します。旧版の設定例も手元にあれば、旧php.iniと比較すると、独自に変えていた箇所を絞る参考になります。

バージョンをまたぐときは、移行ガイドも照合します。例えば8.1から8.3へ移すなら、PHP 8.2への移行ガイドとPHP 8.3への移行ガイドの両方が対象です。設定名が残っていても、挙動や既定値が同じとは限りません。

更新時に確認したい設定項目

旧設定から引き継ぐ内容を判断するときは、まず拡張とパス、エラー出力を確認します。その後に利用する機能の制限値や保存先を見ていくと、移し忘れと、移すべきでない古い指定を整理しやすくなります。

拡張とパス：有効化しただけで読み込めるとは限らない

extension_dirは拡張DLLの場所、extensionは読み込む拡張の指定です。例えば;extension=mbstringの先頭のセミコロンはコメントなので、必要なら外して有効化します。既に有効な行がある場合は、同じ指定を追加しないようにします。

旧環境の絶対パスを残すと、古いディレクトリを参照してしまいます。一方、相対パスを指定している場合も、実行環境で意図した場所を参照するか確認が必要です。パスを明確にしたい場合は、新しい配置先に合わせた絶対パスを使います。

特にWindowsでは、ドライブ文字を省略すると、CドライブとDドライブのどちらを参照しているのか分かりにくく、トラブルの種になりがちです。複数のドライブに開発環境を置いている場合は、C:/xampp/php/extやD:/xampp/php/extのように、実際の配置先に合わせてドライブ文字から指定しておくと安心です。

DLLはファイル名が同じでも、PHPの版・TS/NTS・x86/x64などの条件を合わせる必要があります。旧ディレクトリのDLLを丸ごとコピーせず、対象PHPの配布物や互換性のある配布元でそろえます。詳しくはWindows版PHP拡張の公式説明を参照してください。

読み込み結果はphp -mや後述のextension_loaded()で確認します。起動時の警告も見ておきましょう。OPcacheやXdebugなどのZend拡張は、通常の拡張と同じつもりで指定せず、それぞれの導入手順とzend_extensionの指定を確認します。

HTTPS通信でCAファイルを指定している場合は、そのパスも見直します。curl.cainfoはPHP cURLのCURLOPT_CAINFOの既定値で、絶対パスを指定します。openssl.cafileはOpenSSLを使うストリーム等の証明書検証に関わる別の設定です。片方を設定すれば両方に反映される、というものではありません。

必要な設定はTLSバックエンドや通信処理にもよります。空欄だけで異常と判断せず、実際に使う通信を確認してください。証明書検証を無効にする対処は避け、PHP cURLの証明書エラーとCAバンドルの設定方法を参考にしてください。

日時と文字コード：アプリケーション側の指定も確認する

日本時間を既定にするアプリケーションなら、設定例は次のようになります。UTCで扱う設計なら、その方針に合わせます。

date.timezone = Asia/Tokyo
default_charset = "UTF-8"

date.timezoneの値に加えて、date_default_timezone_get()で実際に使われるタイムゾーンも確認します。アプリケーションがdate_default_timezone_set()で変更している場合は、php.iniの値だけでは判断できません。

default_charsetは、既定のHTTP Content-Typeや、一部の文字列処理関数などに使われる設定です。これをUTF-8にしても、既存ファイルやCSV、DBの文字コードが自動変換されるわけではありません。DB接続や入出力データの設定は別に確認します。詳しくはPHP公式のdefault_charsetの説明を参照してください。

古い例にあるmbstring.internal_encodingやmbstring.http_inputなどを、そのまま追加するのも避けたいところです。これらはmbstringの公式設定資料で非推奨とされているため、使用箇所と代替方法を確認します。

エラー出力：画面へ出すか、ログへ出すかを分ける

PHP更新後は警告や非推奨の通知が増えることもあります。まずログで確認できる状態にして、原因を調べます。画面へエラーを混ぜたくない検証では、例えば次のようにします。

error_reporting = E_ALL
display_errors = Off
log_errors = On

error_reportingは対象とするエラーレベル、display_errorsは画面出力、log_errorsはログ出力の指定です。画面への表示を止めても、ログまで止める必要はありません。

error_logでファイルを指定するなら、Web公開範囲の外に置き、PHPの実行ユーザーが書き込めるようにします。CLIで書けてもApacheから書けるとは限りません。未指定の場合はSAPI側のロガーへ送られるため、利用する環境で実際の出力先を確認してください。

設定の意味はPHP公式のエラー処理設定を参照してください。フレームワークが起動時に設定を変える場合は、アプリケーション起動後の値とログも確認します。

制限値とアップロード：大きくする前に、どの上限かを確認する

memory_limitはスクリプトが確保できるメモリ量、max_execution_timeは実行時間の制限です。メモリ不足をすべて無制限で回避するのではなく、通常のデータ量で必要な範囲を決めます。CLIではmax_execution_timeの既定値が0なので、CLIで完了しただけではWeb側の時間制限を確認できません。

ファイルアップロードには、少なくとも次の二つの上限が関係します。

• upload_max_filesize：ファイル1件の最大サイズ
• post_max_size：POSTデータ全体の最大サイズ

例えば単体10MBまでのファイルを受け付けるなら、POST全体にはほかの入力値やmultipart形式の付加情報も含まれるため、後者には余裕が必要です。複数ファイルを送る場合は合計も考慮します。

通常のフォームPOSTでpost_max_sizeを超えると、$_POSTと$_FILESが空になります。ファイル単体の上限超過と同じ形でエラーを受け取れるとは限らないので、受信側の処理でも区別します。

file_uploadsによる許可、upload_tmp_dirの一時保存先と書き込み権限、必要ならファイル数のmax_file_uploadsも確認します。PHPの設定が合っていても、Webサーバーやプロキシ、アプリケーション側に別の制限があれば送信できません。設定の詳細はPHP公式のPOST・アップロード関連設定にまとまっています。

セッション：保存先とCookieの条件を見る

ログイン状態などが維持されなくなったら、session.save_handlerで保存方式を確認します。files方式ならsession.save_pathのディレクトリと権限が確認対象です。古いパスや、Apacheの実行ユーザーが書き込めない場所になっていないか調べます。

保存できていても、ブラウザーからセッションCookieが返らなければ状態を引き継げません。session.cookie_path、session.cookie_domain、session.cookie_secureなども確認します。Secure付きCookieは原則HTTPSで送信するものなので、本番とローカルでHTTP/HTTPSの条件が違う点に注意してください。

フレームワーク独自のセッション管理やCookie設定を使う場合は、その設定も対象です。ログインできないからといって、本番のSecureやHttpOnlyなどの保護を一律に外す対処は避けます。各項目の役割はPHP公式のセッション設定を参照してください。

設定ファイルの内容と、実際の有効値を照合する

確認用に、次をini-check.phpとしてUTF-8のBOMなしで保存します。読み込み先と、代表的な設定・拡張を表示するだけのコードです。

<?php
if (PHP_SAPI !== 'cli') {
    header('Content-Type: text/plain; charset=UTF-8');
}

printf("PHP: %s\nSAPI: %s\n", PHP_VERSION, PHP_SAPI);
printf("INI: %s\n", php_ini_loaded_file() ?: '(none)');
printf("Additional INI: %s\n", php_ini_scanned_files() ?: '(none)');

$settings = [
    'extension_dir', 'curl.cainfo', 'openssl.cafile',
    'date.timezone', 'default_charset',
    'error_reporting', 'display_errors', 'log_errors', 'error_log',
    'memory_limit', 'max_execution_time',
    'file_uploads', 'upload_max_filesize', 'post_max_size', 'upload_tmp_dir',
    'session.save_handler', 'session.save_path',
    'session.cookie_secure', 'session.cookie_httponly',
];

foreach ($settings as $name) {
    $value = ini_get($name);
    printf("%s = %s\n", $name, $value === false ? '(unavailable)' : var_export($value, true));
}

foreach (['curl', 'openssl', 'mbstring', 'pdo_mysql'] as $extension) {
    printf("extension %s: %s\n", $extension, extension_loaded($extension) ? 'loaded' : 'not loaded');
}

printf("Effective timezone: %s\n", date_default_timezone_get());

CLIでは保存先のディレクトリで実行します。拡張の一覧はアプリケーションに必要なものへ置き換えてください。

php .\ini-check.php

ini_get()は値を文字列で返し、存在しない設定にはfalseを返します。この例では空文字も分かるように引用符付きで表示しています。Off相当の値は空文字や'0'で返る場合があり、空文字がすべて「設定漏れ」という意味ではありません。error_reportingもE_ALLという表記ではなく数値になります。

extensionやzend_extensionの指定をini_get()で一覧取得することはできません。拡張の読込結果はphp -mやextension_loaded()で確認します。関数の仕様はPHP公式のini_get()を参照してください。

CLIだけで一つの値を試すなら、次のように-dで指定できます。これはその実行にだけ適用され、php.iniは書き換えません。

php -d date.timezone=Asia/Tokyo .\ini-check.php

この例ではdate.timezoneとEffective timezoneがAsia/Tokyoになることを確認します。ただし、これでApache側の設定が反映されたことにはなりません。

Apache側は、Webリクエストで別に確認する

Apache側は、外部からアクセスできない検証用サイトで同じ診断ファイルを開き、PHPの版・SAPI・INI・有効値をCLIと照合します。パスなどの内部情報が出るので、一般公開するサイトへそのまま置かず、確認後は削除してください。

php.iniはPHP起動時に読み込まれます。Apacheモジュール方式で変更した場合はApacheを再起動して確認します。FastCGIなど別の方式なら、そのPHPプロセスを再起動する手順に従ってください。CLIは新しい実行で読み直します。

ファイルの値と実行時の値が違う場合は、追加のINIファイルや、Apacheモジュール方式のphp_value・php_flag、アプリケーションのini_set()等も調べます。変更できる場所は設定項目によって異なります。詳しくは設定ファイルの読み込みと設定の変更方法を参照してください。

診断ファイルはアプリケーション起動後の上書きまでは再現しません。最後は、実際のアプリケーションで必要な拡張を使う処理、日時、エラーログ、アップロード、セッションなど、利用する機能を確認します。セッションなら一度保存できるだけでなく、次のリクエストでも値が残るかまで見ておきます。

PHP更新時は、使用中のphp.iniと有効値を先に保存し、新しい設定例との違いを確認してから必要な項目を引き継ぎます。設定を移した後は、CLIとApacheそれぞれで読み込み先・有効値・動作を照合します。旧設定を参照しながら「そのまま引き継ぐもの」「新環境に合わせるもの」「引き継がないもの」を分けると、見直す理由も整理しやすくなるかと思います。