php の error_get_last と debug_backtrace | WordPressのカスタマイズ

error_get_last()

php において、エラーを知るのには簡単に使える error_get_last() を使ってる。
記録されているのは最後に起きたエラーについてだけなのだけれど、どのみち一つづつエラーを修正していくということを考えると、それでこと足りているのではないかと思ってる。
まぁ、ローカルにおいては WordPress の方も debug mode にしてあるので、二重に出力されてしまうわけだけれど。

先だっても、プラグインのアップデートなどを施していたら、ずっと同じエラーが吐き出されているのに気がついた。それは、
 WARNING : Array to string conversion : C:\Apache24 \htdocs\wp\wp-includes\formatting.php : 1098
と、いうもの。

/wp-includes/ にある formatting.php においての WARNING ということなので、何かしらの関数を呼び出して使用しているところでのものということが、だいたいのところで想像がつく。さて、1098 行目というと、wp_check_invalid_utf8 関数の一行目にあたり、
$string = (string) $string;
と、いうところでの WARNING ということらしい。

なるほど、この関数に引数として渡している $string の値が配列になってるぞ！ということなのである。
ということは、この wp_check_invalid_utf8 という関数がどこから呼ばれているのかを調べる必要がある。とりあえず、同じ formatting.php の内部で探してみると、いくつか見つかるが、そのほとんどが、esc_html とか esc_attr なんかのエスケイプをするための関数となる。

esc_html も esc_attr もよく知った関数であり、使用していることに心当たりがある。まぁ、当然といえばそうであるが。

ちなみに、この warning がどういう状況において吐き出されているかというと、こんな具合である。

管理画面に入り、各投稿の編集ページへと入る。
warning はこの時に吐き出される。しかし、すべての投稿においてではなく、出るものもあれば出ないものもあると言った具合。さぁ、それらの違いは何であろうか？

作業中のプラグインには、投稿に挿入できる Gutenberg 用の block を装備している。わかりやすいが、その block を使用している投稿では warning が出るということだ。
こうなると、問題はそのプラグインにあると考えるのが普通の脳みそだろう。

とにかく、使用している箇所の etc_html と etc_attr において、その引数に配列が入る可能性を探してみる。もしかしたらと思えるところに、配列であった場合に文字列に変える処理などを加えて様子を見てみる。しかし、状況は改善されない。

打つ手がなくなり、とりあえず、warning が出ている時の、その配列の値はなんなのだろうかと、wp_check_invalid_utf8 関数に処理を加えてログに書き出して確認してみることにした。
結果はというと、想定された文字列が出てきたが、この値は配列にはなっていないはずなんだが・・・？
と、迷路に入り込んでしまったようだった。

debug_backtrace()

と、いうところで debug_backtrace() 関数である。
この関数は、その関数がどこから呼ばれたのか、そのつながりを遡って知ることが出来る便利な関数である。

• その関数が呼ばれた先を辿って知ることができる関数
• 呼ばれた道筋の配列で返され、それぞれがまた以下の内容を示す連想配列となっている
• function : string : カレントの関数名
• line : int : カレントの行番号
• file : string : カレントのファイル名
• class : string : カレントのクラス名
• object : object : カレントのオブジェクト
• type : string : カレントのコール方式。メソッド呼び出しの場合は “->”、 静的なメソッド呼び出しの場合は “::” が返される。 関数呼び出しの場合は何も返されない

先の、wp_check_invalid_utf8() 関数において仕込んだ、ログを書き出す処理にこの debug_backtrace() を仕込んでみる。

<?php
    function wp_check_invalid_utf8( $string, $strip = false ) {

        // ↓勝手に加えた部分
        if ( is_array( $string ) ) {
        	$error_log = './phperror.log';
            if ( file_exists( $error_log ) ) {
        	    $erlist = file ( $error_log );
            } else {
                $erlist = array();
            }
        	$cdt = date( 'Y/m/d H:i:s' );

        	$dbg = debug_backtrace();
        	$dbgs = '';
        	foreach ( $dbg as $dbgrow ) {
        		$tmpdbg = $dbgrow['file'] . '>' . $dbgrow['function'] . '>' . $dbgrow['line'];
        		$dbgs .= '=>' . $tmpdbg;
        	}

        	$erlist[] = '[' . $cdt . ']' . $dbgs . ' : ' . implode( '-', $string ) . "\n";
        	file_put_contents ( $error_log, $erlist, LOCK_EX );
        }
        // ↑ここまで

        $string = (string) $string;

        if ( 0 === strlen( $string ) ) {
            return '';
        }
        // ↓処理はまだまだつづく
?>

で、結果はというとその出力はこうなる。見やすいように改行を入れてある。

[2021/08/12 09:04:48]
=>C:\Apache24\htdocs\wp\wp-includes\formatting.php>wp_check_invalid_utf8>4527
=>C:\Apache24\htdocs\wp\wp-content\plugins\simplistic_pagenavi\simplistic_pagenavi.php>esc_attr>217
=>C:\Apache24\htdocs\wp\wp-content\plugins\simplistic_pagenavi\simplistic_pagenavi.php>get_url_parameter>122
=>C:\Apache24\htdocs\wp\wp-content\plugins\simplistic_pagenavi\simplistic_pagenavi.php>load_option>51
=>C:\Apache24\htdocs\wp\wp-content\plugins\simplistic_pagenavi\simplistic_pagenavi.php>__construct>660
=>C:\Apache24\htdocs\wp\wp-settings.php>include_once>409
=>C:\Apache24\htdocs\wp\wp-config.php>require_once>107
=>C:\Apache24\htdocs\wp\wp-load.php>require_once>50
=>C:\Apache24\htdocs\wp\wp-blog-header.php>require_once>13
=>C:\Apache24\htdocs\wp\index.php>require>17
 : 300px-802,0823,0701

えっ！と、正直、これを見たときは驚いた！
まさに思いもしないことだったから。
実は、途中、何行にも渡って出てきているプラグインというのは、その時にいじっていたものとは別のプラグインだったから。しかも、テストで使っているテーマではその機能を全く使用していないものだったから。しかし、使用していないとはいっても、プラグインとしては有効化されていたのだけれど。当然か。

WordPress は ブロックエディターの場合、投稿の編集ページにおいて通常のページの表示と同じくするべく、各プラグインの読み込みもしているということのよう。まぁ、そうしないと同じにはならないから当然だわな。
問題となる自作のプラグインである simplistic_pagenavi の get_url_parameter という関数は、WordPress 同様に、要求されているページの詳細を url のパラメータにより取得している関数。ここで、投稿の編集ページでは、Gutenberg のブロックにおいて細かい設定などは attribute として配列のデータを GET で送信して持ち回ってるということのよう。まぁ、url において配列データが入ってくるということを考えていなかった、というのが原因だったと。

これは、この debug_backtrace() を使わないとわからない問題だったなぁ、と。
なんにしても、ということで出どころさえわかれば warning も解消することができて、一件落着と相成ったわけでした。ちゃんちゃん！