Web制作会社のエムハンドでエンジニアをしてる@yadon_yadon_yadon_don_donです WordPressサイトの制作をする際、 いわゆるシステムチックな構築が必要になる場合、 システムの検証や、システムが動いていることの証拠を残すために、 エラーログを出力させています。 その実装方法、注意することをまとめます 実装方法 wp_config.php 下記を、 define( 'WP_DEBUG', false); 下記に書き換えます。 「保存したいパス」に関しては、ドキュメントルートより1つ以上上の階層にディレクトリを作成、そこを設定することを推奨します。（理由は後述） define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', '保存したいパス'.date('Ymd').'_debug.log' ); この書き換えが完了したら、エラーや警告がデバッグログに保存されるようになります。 「保存したいパス」に、日付__debug.logという名前で保存されます。 error_log()でデバッグログにコメントする。 wp_config.phpの設定を行ったら、error_log()でデバッグログにコメントを書き込めます。 例えば、 welcart等のECプラグインを使い、 wp_mail()で商品毎に独自のメールを送信した時に、 それをデバッグログに書き込むことでシステム上でメールが送信されましたというログを残すことができます。 下記のような感じです。 $post_ID = '記事IDを入力'; $user_ID = '顧客IDを入力'; wp_mail($email, $subject, $message, $headers); error_log('顧客ID：'.$user_ID.'にメールを送信しました。商品ID：'.$post_ID); error_log()で配列・オブジェクトを扱う場合は、print_r()を使用しましょう。 error_log(print_r($array,true)); 注意点 ①サーバー容量を圧迫させない 日付処理を行う wp_config.phpのWP_DEBUG_LOGのdate('Ymd')の部分は、 日付ごとにログファイルの出力名を変更しています。 1つのファイルにまとめることもできますが、デバッグが積みあがっていくとファイル容量が増えて、 サーバーのファイルごとのアップロード容量を超えてエラーが出る可能性があります。 ログデータをこまめに削除する サーバーの圧迫を防ぐために、ログはこまめに削除することを推奨します。 ②セキュリティホール URL直打ちでアクセスできないようにする 誰でもアクセスできる場所にデバッグログを保存すると、WordPressのサイトヘルスで警告が出ます。 そもそも、エラーが起きているファイルパスがデバッグログに記載されており、 それによって重要なファイルの名前/パスが漏れる・WPの構造が推測される等の危険があるので、 ログファイルが閲覧されること自体が問題です。 対策として、 デフォルトの保存先を使用しない。下記はデフォルトの設定になるので、使用しない。 define( 'WP_DEBUG_LOG',true); URL直打ちでアクセスできない個所に、ログを設置する（ドキュメントルートより、1つ以上上の階層でOKです） 下記、.htaccessをログ格納フォルダに設置する。それで、アクセスが不可になるかと思います。 他のファイルも見えなくなる可能性があるので、ログ格納用にディレクトリを新規作成してください。 Deny from all ログ格納フォルダのディレクトリ名を複雑にする。 検証のみで使用するのなら、ステージング環境でのみログを動かして、本番環境ではログをOFFにする。 ログに個人情報等を出力しない。 万が一デバッグログが流出した時のことを考えて、メールアドレス・顧客名の個人情報等はログに出力しないようにしましょう。 顧客等の識別をログに送る場合は、記事ID/顧客ID等を使い、万が一流出しても問題ないようにしましょう。 終わりに 「デバッグログがサーバーの1ファイルのアップロード制限を超えてエラーが出た」 「WordPressのサイトヘルスで警告が出た」 この2つの失敗が、この記事を作ろうと思ったきっかけです。 失敗しても、それを糧に改善をしようとする姿勢が大切ですね あと、WordPressのサイトヘルスの指摘が的を得ており、便利な機能だなと思いました

タイトルの通りです。 参照渡し（参照の代入）が推奨できるかはさておき、挙動の一例として参考にしてください。 テストデータの作成 配列$foodsを作成し、$ref_foodsへ参照を代入します。 $foods = [ 'fruits' => [ 'apple', 'orange' ], 'vegetables' => [ 'carrot', 'tomato' ] ]; $ref_foods = &$foods; 代入後、$ref_foodsと$foodsは同じ内容を指します。 var_dump($ref_foods); /* array(2) { ["fruits"]=> array(2) { [0]=> string(5) "apple" [1]=> string(6) "orange" } ["vegetables"]=> array(2) { [0]=> string(6) "carrot" [1]=> string(6) "tomato" } } */ var_dump($foods); /* array(2) { ["fruits"]=> array(2) { [0]=> string(5) "apple" [1]=> string(6) "orange" } ["vegetables"]=> array(2) { [0]=> string(6) "carrot" [1]=> string(6) "tomato" } } */ 配列を丸ごとunsetした場合 unsetされた配列$ref_foodsは未定義の状態になります。 代入元の配列$foodsは変更されません。 unsetのタイミングで参照が解除されることが分かります。 unset($ref_food); var_dump(isset($ref_food)); // bool(false) var_dump(isset($food)); // bool(true) var_dump($foods); /* array(2) { ["fruits"]=> array(2) { [0]=> string(5) "apple" [1]=> string(6) "orange" } ["vegetables"]=> array(2) { [0]=> string(6) "carrot" [1]=> string(6) "tomato" } } */ 配列の要素をunsetした場合 unsetされた配列の要素$ref_foods['fruits']だけでなく、代入元の配列の要素$foods['fruits']も未定義の状態になります。 unset($ref_foods['fruits']); var_dump(isset($ref_foods['fruits'])); // bool(false) var_dump(isset($foods['fruits'])); // bool(false) $ref_foodsへ要素を代入すると$foodsにも反映されます。 参照が解除されていないことが分かります。 $ref_foods['fruits'][] = 'grape'; var_dump($ref_foods); /* array(2) { ["vegetables"]=> array(2) { [0]=> string(6) "carrot" [1]=> string(6) "tomato" } ["fruits"]=> array(1) { [0]=> string(5) "grape" } } */ var_dump($foods); /* array(2) { ["vegetables"]=> array(2) { [0]=> string(6) "carrot" [1]=> string(6) "tomato" } ["fruits"]=> array(1) { [0]=> string(5) "grape" } } */ まとめ 公式マニュアルを確認しましたが、根拠になりそうな情報が見つかりませんでした(-_-;) PHP公式マニュアル: リファレンス渡し PHP公式マニュアル: リファレンスの解除 参照渡しはコードの見通しが悪くなるので使いたくありませんが、動作を知ることは役に立ちます。 注意点をまとめました。 どのように参照が代入されているか（変数をそのままか、一部の要素だけか） 処理の途中でunsetが実行されているか 処理の途中で参照が解除されていないか 2022/03/24追記 記事中のコードでは配列の要素に参照は無いためタイトルの挙動になります。 参照に不慣れだとハマりやすい箇所だと思うので、記事は公開当初のままにしておきます。 参照については、こちらも参考にしてみてください。 Xdebugによる検証方法も掲載されているので、手を動かしながら学べます。 PHP公式マニュアル: 参照カウント法の原理 採用PR 弊社で一緒に働く仲間を募集しています。 全てのオタクを幸せにしたい方、是非ご覧ください！