カテゴリー別アーカイブ: Webプログラム

PHPの「Fatal error: Can’t use function return value in write context」に要注意 (WordPressで管理画面に入れないことも)

ということで先ほどプラグインを更新したときにいきなり発生した事態について書いてみます。「いったい何事?」と考えてしまいましたが理由がわかればプログラムの修正でなんとかなるのですが、知識がない人にもわかるようにいろいろと書いてみます。

 

PHPのとある処理に起因する問題

エラーメッセージで検索すれば詳しく出てくるので詳しくは書きませんが、もしPHPやHTTPサービスのログを直接見られる場合はこんなログが書いてあることがあります。

PHP Fatal error:  Can't use function return value in write context

このエラーですが、調べてみると関数に見えるPHPの演算子(に近いのかな?)に対して関数の戻り値を直接渡した場合エラーとなる、というものです。よくあるのがisset()やempty()に関数の戻り値を直接渡す場合、例としては

function hoge()
{
	return array(...);
}

if(empty(hoge())){

}
else{

}

というものです。この場合、エラーを避けるためには一時的に変数に関数の戻り値を受け取ってからempty()やisset()に判定させる必要がある、つまり

function hoge()
{
	return array(...);
}

$ret = hoge()
if(empty($ret)){

}
else{

}

としなければならない、ということだそうです。で、もう一つ重要なポイントとしてはPHP5.5以降であればempty()については関数の戻り値を直接渡してもエラーとならない、ということになったようです。今回引っかかったのがこれです。

 

EWWW Image Optimizerを3.2.0に更新したら管理画面に入れなくなった…

つまり見事に上の現象に引っかかってしまったわけです。私の場合はエラーログを直接確認できる立場だったので何が起こったのか即座に判定してなんとかしたわけですが知らない人だと検索しても出てこないのでたぶん大変ですね…。まあ、レンタルサーバーなんかだとPHP5.5系以上のはずなので問題ないはずですが…。

 

PHPのバージョンを上げるか回避処理を追加しよう

通常はバージョンを5.5以上にあげる処理を行えばOKです。もしそれができないのであれば一時的に変数に受け取ってempty関数に渡すようにスクリプトを変更することで回避しましょう、とだけ書いておきます。どんなスクリプトになるのか知りたい方はコメント欄にでも要望を書いておいてください。あとで追記するかもしれません。

 

12:00 追記

EWWW Image Optimizerですが、3.2.1で修正されていることを確認しました。なので手動修正としては3.2.1のコードを手元にダウンロードしてbulk.phpをFTP経由などで書き換えることで対応することが可能です。この手の問題って確認漏れなのでいろいろな環境で試さないとだめなのとバグ報告の早さおよび対応の早さが評価の鍵となってしまいますかね。

 

blogの高速化およびデザインを修正してみた(WordPress含む)

Twitterにも書いていましたがこちらのblogに関してプラグインやらを入れ替えることでデザインを修正していたのですが、どうもそれのためにいつの間にかページを表示するまでの速度がかなり遅くなってしまったことに気がついてしばらくの間速度を上げるために四苦八苦していた、という話です。基本的にはWordPressの設定が多いのですが、Apacheの設定やnginxの設定もいろいろと変更していました。

 

変更前の成績と変更後の成績は?

まずはPageSpeed Insightsで測定をしてみた結果です。変更前はこちら。

両方ともかなり悪い成績です。特にパソコンのブラウザでの閲覧では66/100となっていて、赤で修正が必要な項目が出ています。変更後はこちら。

モバイルの成績はほとんど変わっていませんが、パソコンのブラウザでの閲覧だと81/100と大幅に改善しました。特にパソコン側で見たときの修正が必要な項目について赤修正項目がなくなり最低ラインをクリアすることに成功しました。

 

WordPressの高速化のためには?

こちらについてはいろいろなサイトで紹介されていますので端的に言いますと

  • キャッシュプラグインなどを導入してスクリプトやデータベースの動作が必要なタイミングを少なくする
  • 不要なプラグインを無効もしくは削除することでWordPressそのものを軽量化する
  • デザインの中にある不必要なブログパーツを削除する(プラグイン含む)

というものがあります。ちなみにここ数日間のデザインがおかしくなった理由はキャッシュプラグインなどを導入する段階で現在のデザインやブログパーツと相性が悪いものがかなりあり、それを引き当ててしまうことにありました。しかもちょっと私用で日中操作ができなくなったときなんかはデザインは直っていたのですがキャッシュの設定ミスでアクセスログが一切とられない期間があったようで…。苦労しました。

今回新規に導入したプラグインは

というと、以下の二つになります。

そのほかにもW3 Total CacheやらHead Cleanerやら試したのですがこのblogの場合特にCSSに関する最適化やインライン化の設定を行うとデザインが壊れてしまうらしくそのあたりの設定がうまくできないプラグインは対象外となりました。またページキャッシュについてはパーマリンク設定がデフォルトになっていたためキャッシュできない、という状態だったので設定変更およびこのblogにある記事すべてに対してリンクをDB上から直接置換することで対応しました。ついでに絶対URLでリンクしていた部分も修正したり。そのためSearchConsoleに強制的にサイトマップを読み直しさせるなど苦労しました。はじめからキャッシュ設定はちゃんとしておけばよかった…、と思っています。

不必要なプラグインも削除しよう

これも重要なことです。機能をいろいろと試しているうちに不必要なプラグインが有効化されたまま放置される、ということが多々あるのではないでしょうか。プラグインのリストの中で使っていないプラグインは削除しましょう。今回はとあるブログパーツを削除したことでそれに関連するプラグインを使わなくなったため削除対象にしてあります。

外部のブログパーツもPageSpeed Insightsの成績を下げる要因なので注意

ブログパーツはblogに人を呼び込むには「初期には」有効であることは多いのですが検索での流入が大多数を占める場合はページ閲覧に時間がかかるなど成績が悪くなる原因となりますので削除した方がよいことが多いです。下手をするとただの賑やかしにしかならない、ということにもなりかねません。このblogの場合は今回だとZenbackが削除対象としました。もしかするとサイドバーにあるブログパーツも削除するかもしれません。リンク元を見ていますがブログパーツによる流入の増加が一切ないようなので…。

モバイル側の得点が上がらない理由は?

これについてはモバイル側を担当しているプラグインであるWPtouchの影響が大きいと思われます。本来ならレスポンシブデザインにすれば問題はないのかもしれませんがちょっとカスタムが大変になりそう、ということでWPtouchを使っています。これが速度を落とす要因で、おそらくこれの場合キャッシュが効かない、という状態になっているのだと思います。WP Fastest Cacheにはモバイル側のページを別にキャッシュする、という機能があるようですがこの機能はプレミアムの機能、つまり有料部分なので今のところは使っていません。これを使うことで改善する、かつそれなりの収益が生まれるのであればしたいところです。

 

ブラウザのキャッシュを使うための設定をしよう

WordPressだけでは解決しづらいのがこれです。各種ファイルについて有効期間を設定することで通信量を下げる、というのがPageSpeed Insightsの得点を向上させる方法なのですが…。WordPressからだと.htaccessから各MIMEタイプに対して設定を行う、という方法があるようですがどうせVPSなのでそのあたりはすべて制御可能ということでApacheに直接書き加えてみました。今回書き加えたのはこちら。

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 minutes"
    ExpiresByType text/html "access plus 1 days"
    ExpiresByType text/css "access plus 1 weeks"
    ExpiresByType text/js "access plus 1 weeks"
    ExpiresByType text/javascript "access plus 1 weeks"
    ExpiresByType image/gif "access plus 1 weeks"
    ExpiresByType image/jpeg "access plus 1 weeks"
    ExpiresByType image/png "access plus 1 weeks"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 weeks"
    ExpiresByType application/x-javascript "access plus 1 weeks"
    ExpiresByType application/pdf "access plus 1 weeks"
    ExpiresByType application/x-font-ttf "access plus 1 year"
    ExpiresByType application/x-font-woff "access plus 1 year"
    ExpiresByType application/x-font-opentype "access plus 1 year"
    ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
</IfModule>

レンタルサーバーによっては.htaccessに書き加えれば通るものもあるとは思いますがうまくいかない方が多いと思いますのでこちらはVPSなど自前で設定できる場合、としておきましょう。こちらが成功すればブラウザのキャッシュ利用の大半がうまくいくはずです。

そしてこのblog特有の問題がTex表記に関するものです。数式表示で使っているTex表示で、引数が同じであれば表示されるべき数式は同じですのでキャッシュをかなり長くしても問題はないですが、元々がCGIスクリプトであるためキャッシュ期間がApache上では2時間と設定されているらしく、変更するのがかなり面倒、というのがあります。そのためTexの表示に限りリバースプロキシであるnginx側でキャッシュの時間を延長することで対応しました。nginx側から見ればCGIの引数まで含めた場合は静的コンテンツ扱いでも問題ないからですね。なお、nginx側だけでJPEGやPNGといった画像データおよびJavaScriptやCSSといったデザイン要素のキャッシュ期間を延ばそうとするとキャッシュの状態が誤ってしまうらしくデザインが盛大に壊れてしまったためその部分をApacheで対応している、という事情もあったりします。

 

PageSpeed Insightsの得点向上はユーザーの体感向上と同時にSEO対策にもなる

当たり前ですがページの表示速度が遅くなるとユーザーは離れていってしまいますのでその部分を改良するのは当然のことです。今回の場合パソコンでのアクセスだとblogのトップページの記事を読み込むだけで2.8秒かかっていたところを0.4秒まで下げることに成功しています。nginx側のキャッシュ効果も含めればかなりよくなっているといえると思います。それに加えてこれによってページのランキングを向上させることができればまさに一石二鳥ですね。あとはモバイル側がよくなれば完璧、なのですが…。

 

はてなダイアリー側を削除しようか検討中…

こちらに移転したときに一度考えたことですがまたもやこれを考えることになってしまいました。特に記事が重複している期間があるためその部分のランクが悪くなることや、それ以上に全体に響いてしまうと今だとかなり問題だな~と感じていることにあります。また、両者のアクセスログを見る限り基本的に記事を見てくれる人は検索によって来ている人がほとんどでブログパーツ経由の人もほぼいないですし、片方のblogの記事を見た後で検索にあったためにもう片方も見に来てしまう、という現象が発生していることも影響しています。はてさて、どうしましょうかね…。ちなみにはてなダイアリー側のデザインも少し変更してZenbackを削除したりカレンダーのウィジェットを削除したりしていますよ

blogの設定(特に広告類)をいろいろと修正

常時SSL化はとりあえず成功しましたがそれに関連する設定で問題が出ていたことやGoogleが検索時の優先度をまた変えるということでモバイル関係のページについていろいろと再設定をしているとそちらでも問題が出てきたのでここしばらくは再設定をしていました。

 

WordPressのプラグインを使ってアクセスを調べるように

AWStatsでちゃんとログをとれるようにしたのですが、AWStatsの場合は前回も書きましたが日付単位で調べたり数十回前までのアクセスは何があったか?を調べるには非常に不都合な状態で「今日よく読まれている記事から何か書こうか」と考えると難しい物があったのでWordPress側にプラグインを導入することにしました。全体のアクセスのチェックなど粒度が大きい物はAWStatsやGoogleAnalyticsですむので。

今回導入したのはSlim Stat Analyticsというプラグインです。どうもSlimStatという名前をもつ類似したプラグインがいくつかあるようで完全に同じ名前でない限りはちょっと動作が異なるようなのでいくつか入れてみて使いやすそうな物を選ぶといいと思います。アクセス状態を見られるようになったのはいいのですがダッシュボードにその状態を表示するための領域が大量に確保されてびっくりな状態です。必要であれば右上に張る表示オプションから見る必要がないものは隠してしまうといいと思います。

 

モバイル用のページについてカスタマイズした

Googleが検索で表示される順序をモバイルベースにする、でしたっけ?なんかそういうことが書いてあったのでモバイルで表示されるページが大丈夫になっているかどうかを調べるためにスマホで表示させてみようとしたら…モバイル用にはWPtouchを使っていますがいままでまともにスマホ側から見てみたことがなかったので。

そうするとなんか表示がすごいことに。記事のタイトルの表示がおかしかったりトップ画面の広告表示が何かいろいろとおかしかったり…。おかげで表示のカスタマイズを行いこれらの問題を解消してみました。特にトップページの変な表示を直して最後に広告が表示されるように設定をしてみましたが実はこの設定にはあるトリックがあり、WPtouchが更新されるたびに設定をやり直さないと維持されない、という物が…。面倒な状態となっています。

 

(GoogleAdsenseの)レスポンシブな広告を正しく表示されるように設定しよう

各記事の最後に表示される広告ですが、修正前は大きさが固定となっていたためPCで記事を読む分には何も問題はないのですがタブレットやスマホで見ようとすると広告が大きすぎて表示領域をはみ出してしまう、という問題が。こういうときに使えるのがレスポンシブな広告で表示されるときに表示される画面の大きさに従って適当な大きさのものを表示する、という便利な状態です。これは、ということで使ってみようとして広告ユニットの大きさを変えることはできないので新しく作り直して認証を待っているとモバイル用ページ側はあっさり確認されたのですが各記事に表示される広告がなぜかアクティブにならない、という問題に。

いろいろと調べてみるとレスポンシブな広告の場合、広告ユニットに対して「どの大きさで表示することが望ましい」ということを設定しないと正しく表示されないらしいです。そのため、CSSのプロパティより読み込まれた画面に応じて最大サイズを広告ユニットに設定するなどしないとまずいようです。GoogleAdsenseのページに設定のサンプルがあるので自分が使いたい状態を設定すればよいですが気がつくまでに時間がかかってしまい設定が通っていない間表示がない、という状態になったのが微妙に残念でした。まあ、仕事などでもしその手の設定を請け負ったときにどのようにすればよいか?を調べておくための要素が強く人気の記事にはなりにくい物を書いているので仕方がないか、ですむ話だったりします。これが人気の記事とかでアクセス数がかなりあるなら大問題だったでしょうが…。

 

blogのカスタマイズはこれで一段落

はてなダイアリー側ははてなブログに移動する気はほぼないのでそうするとカスタマイズの余地はほぼないためこれで一段落、という感じです。また、ちょっと前の記事からこの記事の間に私的にも落胆することもありちょっと傷心気味でプログラムの開発とかはあまり進んでいません。アフィリエイトで稼ぐ!とかそんなことは私の場合はおそらくできないだろうと見限っていますのでいろいろと別のことも試さないとな~というところです。

Win8.1でのTinyMCE Advancedの動きが・・・

設定でキャンセルできるのか、それとも私のPCの設定が悪いのか非常によくわからない現象があって悩んでいます。

 

TineMCE上のビジュアルエディタでATOKを利用して日本語入力すると

何が起こるか?といいますと、ビジュアルエディタ上で日本語を入力しようとすると一文字目だけ即座に入力確定してしまい・・・という現象が。しかも必ず起こる、というわけではないのでキャンセルするために文字をわざと入れるわけにもいきませんし、そうでなくてもそんな入力を毎回するわけにもいかないので記事は一度メモ帳で書いた上で貼り付けで移動させる様にしています。改行記号の削除が非常に面倒ですが仕方が無いですよね。

 

正しくはWin8.1+IE(保護モード)+ATOKの組み合わせで起こるらしい

誰だよ、こんな仕様にしたのは!と怒りたくなりますが、これが正しいらしいです。Chrome上からテストしてみると何事もなかったですし。通常のブラウジングはIEを使用していてChromeやFirefoxはデバッグ用途や通常以外のブラウジングに使用しているのであまりこういう変更はしたくないのですが、こうも漢字変換がうまくいかない様では考えないとまずいかもしれません。まあ、保護モードとやらを解除すればいける様な気がしないではないですが、一応セキュリティ機能の一つだと思われるためあまり解除したくもないですし。どうしようかな・・・と。

 

WordPress3.9+TinyMCE Advanced4.0の組み合わせがいいかな

というわけです。はい。私は以前からWordPressのビジュアルエディタプラグインにはTinyMCEを使っていたのですがWordPressを3.9に更新した付近から「何かおかしいな~」という感じで使い続けていました。で、理由がやっと分かったのでちょっとそれも交えて報告です。やっぱりビジュアルエディタはいいですね。

 

いくつかのビジュアルエディタプラグインがWordPress3.9で使えなくなっている

ま、これはいくつか記事が出ていますのでそれを参考に。特に影響が大きいと思われるのが上記と名前が似ていますが「Ultimate TinyMCE」というプラグインは現段階(2014-04-26)ではWordPress3.9に対応していないため使用できません。使っていた人は更新時にビジュアルエディタが動かなくなってびっくりしたことでしょう。とりあえず一時的に無効化するなりアンインストールして乗り換えるなりした方が良さそうです。

私の場合はTinyMCE Advancedを使っていた関係で本来ならこれに影響されない・・・はずだったのですが、更新の内容を読んでいなかったばっかりにとある現象に悩まされることになってしまったようです。もしかすると気になっている人がいるかもしれませんので参考に。

 

TinyMCE Advancedを4.0にバージョンアップするとエディタのボタン設定が一度リセットされる様子

 これがちょっとやっかい。バージョンアップでボタンによる修飾だけではなく先頭行にメニューバーによる表示が加わって便利・・・にはなっているのですが、その影響でバージョンアップをするとエディタのボタン状態がリセットされます。これに気がつかないと「エディタの状態がおかしい」と思い込んでしまいます。私もその一人でしたし。

これに関してはエディタのボタン配置を再設定すれば直る問題のようなのでWordPressとTinyMCE Advancedのアップデート後に調整を行いましょう。なお、調整時にちょっと気になったこととしていくつかのブラウザで日本語表示の問題点として「フォントサイズ」の項目(ボタン配置設定上では「FontSize」)がありますが、この文字列が長すぎる+短縮文字列作成の間違いの関係で終端が文字化けしてしまいます。(実際、InternetExplorerでは文字化けしていました。GoogleChromeでは大丈夫だったのに)気になる人はがんばって直しましょう。手動でスタイルシートを直すなり。

 

TinyMCE Advanced 4.0にPS Disable Auto Formattingは必要ない

ビジュアルエディタとテキストエディタを切り替えた時に改行などが消える現象を何とかするプラグインとしてPS Disable Auto Formattingがありますが、そのオプションはTinyMCE Advanced側に取り込まれていますのでこちら側で使うようにしましょう。いらなくなっているので削除してしまった方が安全です。いくつかのサイトでは逆に悪さをしてしまうパターンもあるとなっていますので。私の場合、効いていなかったのか切り替えた時に勝手に行間が縮まったりしていたので不便だったのですが、いまはそれがないのでかなりありがたかったりします。

 

バージョンアップ時には確認が大事

特に細かくカスタマイズしている場合はバージョンアップ時の互換性問題は気にしておかないと後が大変ですね。思っていた違和感の関係で初めは「エディタプラグインが動作していないのでは?」と思い込んでいたくらいですし。見た目が変わるだけでもそう思うくらいですのでWordPressをカスタマイズして顧客にサービスをしている、というパターンだといろいろと考えないとだめですね。