タグ: WordPress

ふと、Wordpressにアップロードしたjpegの最適化をしてみようという気になった。
続きを読む

WordPressの記事にGoogleMapを簡単に埋め込めるようにしてくれる、「MapPress Easy Google Maps」っていうプラグインがある。記事の編集画面の下側でボタンを押して、プロットしたいところの住所や名前を入れるとジオコーディングしてくれる機能もあったりして、まぁまぁ便利で使っていたんだけども。

このブログを始めとして、いくつかWordPressで構築してあるブログを運用しているが、その「MapPress Easy Google Maps」をインストールしてあって、普通に地図のプロットができるWordPressと、地図を編集しようとするとプロット地点の名称が保存できないWordPressがあって、ぱっと見で原因が分からなかった。

仕方ないからブラウザの開発ツールでエラーが出ていないか調べて見ると、tinymceが読み込まれていないエラー(Reference Error: tinyMCE is not defined)が出ているのを発見。tinymceというと、ビジュアルエディターで使われているモジュールのはず。その線で、2つのWordPressにインストールされているプラグインなどの差異を調べてみたが差異は発見されず…。

で、ブラウザを2つ起動して、「MapPress Easy Google Maps」がちゃんと動くWordPressと、動かないWordPressを見比べていたら、「MapPress Easy Google Maps」がちゃんと動いているWordPressでは、記事の編集画面のタイトルの下、本文を入力するtextareaの右上に「ビジュアル」「テキスト」と表示されていて切り替えることができたが、動かない方は、その切替用のリンクが存在していなかった。

確か、WordPressのどこかでビジュアルエディターを使う、使わないの設定を持っていたような…と思ったが、思い出せずテキトーにググってみたら、ユーザーのプロフィールで持っている設定(「ビジュアルリッチエディターを使用しない」)であることが判明。というわけで、動かない方のWordPressでビジュアルリッチエディターに関する設定をいじってみたら、難なく地図を編集できるようになった。地図のプロットの編集画面、よーくみるとTinyMCEをロードしてた。

まぁ、普通、こんな設定をいじらないんだろうけれど、一応、「MapPress Easy Google Maps」はこの設定に依存してましたってことで。プラグインの詳細ページのFAQの”Map Won’t Save”欄には、こんな感じで書かれていて、開発者の方もビジュアルリッチエディターの設定をいじっているケースは想定してなさそうなことがわかる。

This is caused by errors in another plugin or the theme. Disable all plugins and switch to a standard theme (for a moment). If you now see your map, re-activate until you find the problem.

ま、普通はいじらないもんなぁ…(てか、なんでいじってあったんだろう…)

WordPressで構築してある別サイトにログインしようとしたら、画面が真っ白。さらに、どのURLにアクセスしても真っ白…。しかも、httpのステータスコードとしては503を返しているけど、phpのエラーログには何も出てないし。

…というわけで、全くもって何がどうなっているのかわからなかったけれど、まぁ、とりあえずプラグインから疑ってみるとかと言うことで、SSHでサーバにログインして、wp-contentのpluginsディレクトリの下にある、プラグインのディレクトリをとりあえずmvして名前を変えて、アクセスしてみた。すると、「jetpack」をリネームしたら、普通にWordPressの各画面が表示されるようになったので、まぁ、これはAutomatticが公開しているjetpackプラグイン。ちょっと調べて見たら、jetpackプラグインのchangeログにこんな記載があった。

どうやら、jetpackのVer.4.0.2が2016年4月21日にリリースされていて、Ver.4.0が抱えていたバグが修正されたらしい。

Bug Fix:
Addresses an issue where Jetpack 4.0 caused a fatal error on sites with specific configurations.

specific configurationsってなんだろう…と思ったが、とりあえず、JetPackのバグでWordPressが真っ白になっていたようだ。specific configurationsという条件があるおかげで大騒ぎにはなってなさそうだけど、このバグを踏んじゃった人は割と慌てるんじゃないかなぁと…(遠い目)ま、それに4.0より古いバージョンだと問題なさそうなので、ピンポイントでVer.4.0をインストールした人となると、まぁまぁ少ないか。

運用しているWordPressが吐き出すPHPのログに「PHP Fatal error: Allowed memory size of 268435456 bytes exhausted」みたいなエラーが出ていた。これが出ていたときには、管理画面が真っ白になっていた(遠い目)まぁ、256MBもメモリーを食ってる処理をどうにかしなきゃいけないとは思うけど、とりあえず、上限値を押し上げてみて動くようなら、それで乗り切ってしまおう…と思った(ま、ヒマが出来たら調べてみようかと)

何にも考えずにphp.iniをいじって「memory_limit = 512M」としてhttpdを再起動(Apache httpdとmod_phpで動いてる)を再起動してみたが、やはりどこかでメモリー制限がかかっているようで、php.iniの設定が有効にならない。で、仕方ないのでWordPressのソースコードを読んでみたり、プラグインのソースをチェックしたりぐぐってみたりしているうちに、「WP_MAX_MEMORY_LIMIT」って定数の存在に気がついた。→詳細はこちら

要するに、WordPressはデフォルトでメモリー使用量上限値を設定していて、そのデフォルトが256MBらしい。普通は、この上限値で問題ないと言われれば確かにそうだろうなぁと思うが、php.iniで設定しても反映されなかったときはプラグインのどれかで設定しているのかなぁ…と調べてしまった(All in One SEO Packは制限値を変更できる機能がありそうだったが、デフォルトは256MBだった)

というわけで、wp-config.phpにて「define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );」と追記したら、メモリーを使い切った系のエラーは出力されなくなった。とりあえず、一件落着ということで…原因調査はそのうちに…。

私がうっかりそういう風に設定してしまったからなのか、それともデフォルトでそうなのか、よくわからないんだけども、気がついたら「All in One SEO」プラグインの「Use noindex for Author Archives:」にチェックが入っていた。

なんとなーくではあるけれど、とあるblogでAuthorの記事にアクセスが多少は来そうだなぁと思って、こそこそいじってみたんだけれども、しばらく経っても全くと言っていい位にアクセスが無かったので不思議に思って原因を調べてみたら、このチェックボックスを発見。うーむ、なんかもったいないことをしてしまったような気がする。しまった。

まぁ、さすがに個別の投稿ページではこういうことが起きづらいかもしれないけれど、カテゴリーページとかタグのページなど、SEO系のプラグインで自動的にnoindexになってしまっているけれど、実はそういうページのPVを期待していたみたいなケースって意外と…ないか(汗)