予期せぬ出来事 | WordPressのカスタマイズ

2020/12/08 追記：
またまたまた予期せぬ出来事が！
たしか契約の更新があったよなぁ！と思いつつロリポップのユーザーページにログインして、なんとなくphp 設定のページへと入ってみると、あれっ！と。設定がなんとモジュール版となっている。いつのまに？
phpinfo() で確認してみると、Server API は確かに Apache 2.0 Handler となってる。ならば memory limit の価はと、300M となってました。
いつのまに？という感じだけれど、まぁね、またまた大満足のうれしいサプライズということでした。これはクリスマスプレゼントのようです。もう一度、ありがと～！

と、ちょっとまて、いやいやそれだけじゃなかった。 実はこの時は気が付かなかったのだけれども、随分と経ってから気がついたことが・・・。 この時のアップデートにより、「現在の共有SSLのアドレスは利用できなくなり、ロリポップ！ドメインがSSL化されました。」とのことがお知らせメールにこそっと書いてあるではないか！なんでドカ～ンと大きく書いてくれないんだ？気が付かなかったじゃないかっ！ と、いうことは url はこれまで通りで、プロトコルだけ https にすれば SSL化できるってこと。まぁ、とはいってもテンプレートの中身も直さなければならないところもあるし、ページの数がかなり多いのでやらなければならないことは相当にあることはあるのだけれど、でも、これも結構うれしかったりするのです。感謝！

2020/08/06 追記：
またまた予期せぬ出来事！
突然、ロリポップさんから全プランリニューアルのメールが届いた。
ストレージがSSDになったり、CPUの能力がアップしたり、ディスク容量もアップしたり、などなどするとのこと。色々あるんだろうけど、なんにしてもこういうサプライズはうれしいものです。速くなるかな～！と、楽しみにしつつアップデート。ありがとね～！

ここはロリポップのサーバーを使っています。
php がモジュール版7.3になったのとwordpress が5.3にアップデートされたのがほとんど同じころだったように思います。
wordpress 5.3においては、ローカルと自分専用のサイト（これもロリポップにある）で前もってベータテスターで使用して確認していたので、まったく不具合は出ないものと安心していました。
しかし、このサイトで正式版5.3にアップデートしてみたら、なんだかちょっとおかしなことがちらっと。
予約投稿の日付指定をした時に表示されている日付がその日付になっていないし、月の文字が2つ並んでいたり。でも、予約投稿するとちゃんとその予約した日付にはなっていたりするのですが。
それ以外は気になったこともなく、何度か予約投稿できていたのですが、ある日突然に新規追加画面が出なくなってしまいました。
「サイトに重大なエラーがありました。 詳細については、サイト管理者のメール受信ボックスを確認してください。」
なんて表示があって、debug モードなども紹介されています。でも、アドレスはあっているのにメールはきていなかったなぁ？どこへいっちゃったのか！
でも、何度かやっていると新規投稿画面が開くこともあって、だましだまし何度か投稿することもできたのではあります。まぁでも、やはりこういった状態はうっとうしいので、勧められたとおりwp-config をいじってdebug モードへと突入していったのです。
さぁ、いざいざ！

どれどれと、さっそくdebug.log を確認してみると、そこにあったのはこれ。
「Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/users/1/main.jp-strix/web/wp-includes/meta.php on line 958」
ちなみに、赤文字にしていますが実際は赤くありません。
958という行番号からすると、update_meta_cache という関数においてエラーが吐き出されてしまうようです。このサイトはローカルや別wpサイトとは違い、それなりにカスタムフィールドを多く使用しているので、ここでだけこのエラーが出てしまうのはそのあたりに理由があるのかもしれません。
ただこのエラーはphp のmemory_limit のサイズを134217728 bytes よりも大きくしてやりさえすれば解決するものだと認識していました。
が、まずはとりあえず他にいくつか出ていたエラーを手当り次第に処理していきます。

そして、いざphp のmemory_limit となるわけですが、ロリポップのモジュール版php ということなのでphp.ini は編集できません。なので .htaccess に以下の行を追加して試してみることにします。
php_value memory_limit 256M
memory_limit の値はphpinfo() にて確認しますが、何も変化はなし。モジュール版の場合、.htaccessに書いてもやはり無駄なようです。で、実際に稼働するコードの中に記述しても同様でした。
と、いうことでどうすれば出来るものかとサポートにメールして待ちの状況でした。

後日追記：
これは後になって気がついたことなのですが、このmemory_limitの値は、php のプログラム内において、ini_set( 'memory_limit', '256M' ) を使えばできたのかもしれません。少なくともローカル環境においてはできましたが、その場合は .htaccess からでも変更ができてはいましたからはたして・・・。レンタルサーバーにおいて、実際に試してみたわけではないので、確かなことではありませんが、もし、同じ問題に遭遇した場合、やってみる価値はあるかと思います。・・・と、いいつつも、後日実際にやってみましたが、.htaccess にしても php ini_set にしてもどちらもだめでした。

その間、はたしてCGI版でならば、と思いCGI版php7.3 に変更し、php.ini の編集をと思いきや、ロリポップのphp.ini 編集用ページにはmemory_limit の項目が見当たらず、.htaccess の設定が優先される「php_value, php_flagを利用可能にする」の設定をon にしたと。
そして確認してみると.htaccess の設定は反映されてmemory_limit は256M となり、以後、管理画面においてのエラーは消え失せ、何の障害もなく投稿できるようになったとさ。めでたし、めでたし。
サポートからのメールにも、モジュール版ではphp.ini の設定はできないので、CGI版をそのまま使ってくださいとの旨が書いてあっただけ。
まぁ、心情的にはより高速なモジュール版を使いたいのだけれど、どうにもならないようで・・・。
とはいうものの、そもそもmemory を134M も使っていることが問題なのかとも思いつつ、多分、その原因であろうカスタムフィールド辺りのコードを見直したほうがいいのかもと。

で、ちょっとネットをうろうろしていたら、wordpress 側にもmemoly_limit の設定があることを知りました。それは、 /wp-includes/default-constants.php にあって、マルチサイトで60M、そうでなければ40M、そして管理画面においては256M ということ。管理画面の256M というのはコードからは読み取れないのですが、WP_MAX_MEMORY_LIMIT の値はそうなってます。管理画面のコードにおいて設定するコードが出てくるのかな。
まぁ、ということであれば134M というのはそれほど極端な数字でもないように思えます。
wordpress 側の設定値の件をサポートにサーバー側で対応しないのですか？とメールしてみたものの、返ってきた答えは、モジュール版においては256M での運用はできかねます、とのこと。しょうがないですね、メモリー使用量を減らすべく考えてみることにして、ひとまず、この件はこれにて。

しかし、wordpress のdebug mode は、もっと早くに知るべきものでした。
なにか出ていないかと見てみると、おどろいたことにデータベースエラーなるものがどか～んと出てた。しかも2つも。
WordPress データベースエラー: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-42, 42' at line 10 for query
SELECT a.ID,a.post_parent,a.guid FROM wp_posts a, wp_posts p, wp_term_relationships r, wp_term_taxonomy x, wp_terms t
WHERE a.post_parent = p.ID
AND p.ID = r.object_id
AND r.term_taxonomy_id =x.term_taxonomy_id
AND x.term_id=t.term_id
AND a.post_type = 'attachment'
AND p.post_status <> 'draft'
AND t.slug='rosy_finch'
ORDER BY p.post_date DESC,a.post_title DESC
LIMIT -42, 42
これが、どのページのSQL なのかは、書いた私には一目瞭然でわかります。
《 taxonomyで絞り込んだ画像一覧ページ-改 》のSQL なのです。

エラーはLIMIT の OFFSET にマイナスの数値を設定しているからですね。
それにしても、はて？なんでこんなことになるのかしら？と。
考えて悩んでいるよりも、実際のデータベースでSQL を発行していろいろと試して見る方が早いですね。
すぐに原因はわかったのです。

自分のサイトは鳥画像サイトで、このページは鳥種を絞り込んでその鳥種の画像だけを表示するためのものです。そして想定していたのは、親ページからのリンクによって呼び出され表示されるページであるということ。それゆえに、url のオプションで、このサイトに画像のある鳥種のパラメータが付加されているということ。
LIMIT の指定を外してSQL を発行してみたら返り値はありませんでした。そうなんですね、実は ’rosy_finch’ という鳥はいないのです。ちなみに ’Asian Rosy Finch’ という鳥は日本にいるのですが。和名をハギマシコという綺麗で可愛い鳥さんです。
ということは、いったいどういうことか？url にこのサイトのリストにはない鳥をわざわざ入力してアクセスしてきたということか？アクセスログを調べてみてもそれらしい時間にアクセスはないようだし・・・。と、よくよく考えてみると・・・。
鳥の名前というのは、研究が進んで新たな事実が判明したりすると分類が変わり、それに伴って名前も変えられたりします。そういえば、'Rosy Finch' というのは以前に使っていた名前なんですね。ということは、これはgoogle などのbot が以前に使っていた名前のデータが残っていて、それにてアクセスしてきたもの、ということだと思います。
その部分だけコードを拾い出すと、

<?php
	// 変数の初期化
	// 一ページの画像の数
	$per_page = 42;

	// 一列の画像の数
	$per_row = 3;

	// 小文字のアルファベットと数字、ハイフンとアンダーバー以外がマッチするパターン
	$pattern = '/[^a-z\d\-_]/';
 	$addpara = '';
 	$tagname = '';

	// urlパラメータをGETで取得、タクソノミーはパラメータで送信される
	if ( isset ( $_GET['tagname'] ) ) {
		$tagname = $_GET['tagname'];
	}

	// 小文字のアルファベットと数字、ハイフンとアンダーバー以外とマッチした場合、
	// 不正な文字列が入っているものとして処理を中止
	if ( preg_match( $pattern, $tagname ) ) {
		$tagname = '';
	}
	if ( ! $tagname ) {
		header( 'Location: ' .  home_url() );
		exit();
	}

	// 画像の数を得るSQL

$sql = <<< HERE
SELECT COUNT(a.ID) FROM $wpdb->posts a, $wpdb->term_relationships r, $wpdb->term_taxonomy x, $wpdb->terms t
WHERE a.ID = r.object_id
AND r.term_taxonomy_id = x.term_taxonomy_id
AND x.term_id = t.term_id
AND a.post_mime_type LIKE 'image/%%'
AND a.post_type = 'attachment'
AND x.taxonomy = 'media_tag'
AND t.slug = %s
HERE;

	$count = $wpdb->get_var( $wpdb->prepare( $sql, $tagname) );

	// 画像の数から全ページ数を求める
	$page_counts = ceil( $count / $per_page );

	// URLからページ番号を得る
	$page_no = intval( $wp_query->get( 'paged' ) );
	if ( $page_no < 1 ) {
		$page_no = 1;
	} else if ( $page_no > $page_counts ) {
		$page_no = $page_counts;
	}

	// オフセットを求める
	$offset = ( $page_no - 1 ) * $per_page;
?>

SQL の返り値が0 （その鳥の画像は一枚もない）だと$page_counts が0 になり、よって$offset は-42 になるという計算です。なるほどっ！
サイトに無い鳥でこのページにアクセスするなんてことは全く考えもしませんでした。が、十分にありえる事ですね。
もう、対処してありますよ。ついでに、なんでこんなことしてるの？という部分もありましたから、そういう部分も直しています。

ちなみに、「URLからページ番号を得る」部分は、$wp_query->get( 'paged' )と、$wp_query からurl のパラメータを取得しているのですが、例えばマイナスの数値などが設定されていると、その絶対値を返してきます。-5 なら5 ですね。それでも別に問題はなさそうではあるのですが、ありえない数値を指定された場合には、というはっきりした分別の処理をしやすいので、普通に$_GET の数値を取得して処理したほうが良いように思い、そのように変更しています。

《　WordPress Filter Hook 'request'　》

しかし、何年か前にかなり多くの鳥の分類が変更になって、それだけではなく、IOC という世界的な鳥分類の機関においては、毎年のようにちょっとづつ変更になってます。ここのサイトもそのIOC の分類に基づいているので、ちょくちょく名前を変更せざるを得ない、ということになってます。数的には結構、あるのですね。で、どれくらいgoogle のbot が空振りのアクセスをしてくれているのかということが気になってきます。
SQL エラーのあった前述の《 taxonomyで絞り込んだ画像一覧ページ-改 》のページは、WP のクエリを使用せず、自作のSQL にてデータを収得しているので、その点の対策はやりやすいのです。旧名称と現名称での連想配列を作り、その配列で得た現名称でSQL を実行させ、その場合にメールにて知らせるようにしました。
思ったとおり、やはり結構な数でアクセスがあります。まぁ、変更している数はかなりありますからね。
ここのサイトにおいて他に鳥の分類で表示させるページというと、tag ページがそうなります。鳥分類はtag を使っているということです。
tag に無い鳥でアクセスがあった場合、エラーとはならず、ページが無いと表示されるだけです。まぁ、でも、これもあまり気持ちの良いものではない。
すでに変更されてしまってtag に無い旧名称でのアクセスの場合は、現名称にリダイレクトさせればよいのですが・・・。
すでに無いページからのリダイレクトというと、.htaccess がすぐに思い浮かびますが、かなりの数があるので、なんとなく気が引けます。
wordpress 側で、SQL を実行する前に、tag の指定があった場合に、そのslug を変更できれば可能なことに思います。
で、探してみるとどうやら、フィルターフックの'request' か'query_vars' が使えそうです。'request'のCode Reference を見てもよくわからないので、 wp-includes/class-wp.php にあるコード本体へ。
フィルターフック'request'は378行目ほど、function parse_request の中にあります。'query_vars'はもう少し前の287行目ほどのところ。'request'で引数として得られる値は$this->query_vars なので、この中の'tag' の値があれば、その値を現名称に入れ替えてやれば良いのでは、ということになります。

function change_name( $target ) {
	$retname = null;
	$oldname = array(
		'bean_goose' => 'taiga_bean_goose',
		'brent_goose' => 'brant_goose',
		'shelduck' => 'common_shelduck',
		'rosy_finch' => 'asian_rosy_finch',
		'brown_hawk-owl' => 'northern_boobook',
		'japanese_white-eye' => 'warbling_white-eye',
	);

	if ( $target ) {
		if ( isset( $oldname[ $target ] ) ) {
			$retname = $oldname[ $target ];
		}
	}
	return $retname;
}

function get_request( $qeryvars ) {
	if ( isset ( $qeryvars['tag'] ) ) {
		$tagstr = $qeryvars['tag'];
		if ( change_name( $tagstr ) ) {
			$qeryvars['tag'] = change_name( $tagstr );
		}
	}
	return $qeryvars;
}
add_filter( 'request', 'get_request', 10,1 );

これでやってみると、そのページのリダイレクトという件においては想定通りの結果となり、現名称でのページが表示されました。
ただ、ちょっと気になるのが、そのページからのページリンクにおいてはurl にある旧名称を使用したものとなっています。それは何の値でかわるのだろうか？というところがもうちょっとの課題となります。とりあえずは、これにて当面の問題はクリアできたというところで。
などなど、身近にも想定外のことはちょくちょくあるもので、ちょっと予期せぬ出来事のいくつかでした。