WordPressの日本語周りの不具合解消とApacheのメモリー最適化のきっかけ
WordPressはApacheなどのWebサーバの上のPHP環境で実行されるCMS(コンテンツマネージメントシステム)となります。そのため、WordPressだけの知識ではなく、ApacheやPHPに関する知識も必要になってきます。
投稿するためのネタはあるのですが、最近忙しくてなかなか楽しめる記事を投稿できず残念なのですが、気持ちを切り替えてWordPressの設定をあれこれを見直してみました。
qTranslate-Xを使って日本語のRSS参照不可を解消
i-simTripはqTranslate-Xを使って日本語と英語のマルチランゲージでブログを作成しています。このサイトは主に日本人向けの記事ではありますが、東北のことをもっと海外の人にも知ってほしいからです。機械翻訳で英語にしているため、残念がらあまりよい投稿とは言えません。Apacheのアクセスログを時々見ていて、RSSのfeedの読み取りをGoogleBotなどからアクセスされている事を認識していたのですが、英語用のアクセス先である「GET /en/feed」だけ応答コード200を返して、日本語のRSSである「GET /feed」が200ではない応答コードを返しているときが時々あり、気にしていました。そこで今回実際に自分でアクセスして確認した所、「http://www.i-wmobile.com/feed」（以降略して～/feedなどに記載）にアクセスるすると、自動的に「http://www.i-wmobile.com/en/feed」になってしまい日本語のRSS情報の取得ができない事がわかりました。最初は何らかのプラグインが悪さをしているのかな？と思って無効にして試しましたが改善されません。そこで、URL 変更モードの「デフォルト言語の URL 言語情報を隠す」のチェックを外しました。
そうすることで今までデフォルトである日本語の場合は～/xxxというサイトで、英語の場合だけ～/en/xxxのURLになる事より、今度は日本語の場合、～/ja/xxxとなります。実際にアクセスして試したら、～/のURLにアクセスすると～/ja/xxxと自動的に切り替わります。そして問題のRSSの方は～/feedへアクセスすると自動的に～/ja/feedとなり、日本語のRSS情報を取得できました。事前パスモードにしている人はぜひ、このチェックを外した運用の方がいいと思います。
これはi-simTripの予想ですが、～/へアクセスしたときにブラウザから渡される言語の変数を確認して言語別のURLに切り替えている部分の不具合があり、既定の言語も～/jaのようにどの言語のサイトかわかるようにする必要があるのではないでしょうか？
iThemes SecurityプラグインのHide Login Areaと相性が悪いため、対処
このqTranslate-XプラグインとiThemes SecurityプラグインでHide Login Area機能は相性が悪いのが判明しました。通常WordPressのログインURLはスラッシュ(/)の最後にlogin, dashborad, wp-login.phpにするとログイン画面が表示されます。このHide Login Area機能を使うことで、通常のログインURLではアクセス不可能にして、ログイン用URLを知っている人だけがログイン画面を表示できるようにします。つまり、誰か悪意を持っている人のブルートフォースアタック攻撃を防ぐ手段の１つになります。
この設定とqTranslate-XプラグインよるURL途中に言語ごとのディレクトリが挿入される機能を設定するとログイン画面を表示できなくなります。
対処は以下のようにHide Login Areaで設定される.htaccessのRewriteルールの変更です。qTranslate-Xプラグインで追加される言語ディレクトリ名をOR(この場合|)で追加するとログイン画面が表示可能になります。
- .htaccess
| 変更前) RewriteRule ^(/)?/?$ /wp-login.php [QSA,L] 変更後) RewriteRule ^(/|ja/|en/)?/?$ /wp-login.php [QSA,L] |
WP Multibyte Patchプラグインの有効化のエラー対処
WordPressをインストールすると最初から２つのプラグインが入っている事は皆さんご存知だと思います。「WP Multibyte Patch」、「Hello Dolly」の２つになります。このうちの１つ「WP Multibyte Patch」プラグインは日本語のマルチバイトに関する不具合解消のためのプラグインという説明があるため、気にしていました。しかしi-simTripが利用している部分では特に不具合らしい箇所がわからなかったので、特に気にせず有効にしていませんでした。今回有効化をしよう思いつき、いざ試した所エラーが表示されて失敗します。 「お使いの WP Multibyte Patch を有効化するには PHP の mbstring 関数が必要です。」 というエラーが表示されます。そこで以下の対処をした所、無事有効化できました。
- /etc/php.ini
| short_open_tag = On output_buffering = On max_execution_time = 300 error_reporting = E_ALL & ~E_NOTICE post_max_size = 20M default_charset = “UTF-8” upload_max_filesize = 20M date.timezone = Asia/Tokyo mbstring.language = Japanese mbstring.internal_encoding = UTF-8 mbstring.http_input = auto mbstring.http_output = UTF-8 mbstring.encoding_translation = On mbstring.detect_order = auto mbstring.substitute_character = none; |
apacheのメモリー最適化
i-simTripのWPサイトを稼働させているApacheのMPMはworkerで稼働させています。moduleは全て初期値のままにしてあり、いい加減1プロセスあたりの使用メモリーが大きい状態になっていました。現在、既に最適化済みになっており記録していなかったためあまり覚えていませんが、記憶では300MB以上あったと思います。Apacheのセキュア化についてモジュール無効化以外、全て設定済みの状態にしておりました。モジュールのみ、どのモジュールがどの機能でWPに必要なのかわからなかったので、なんも変えていなかったという経緯がありました。WordPressはPHP実行環境であるため、ある程度、どのモジュールが必要なのか予想され、反対にこの機能は絶対に使っていないだろうと思うmodukeを無効化する方針としました。
今回無効にしたmoduleは以下となります。
- /etc/httpd/conf/httpd.conf
| #LoadModule auth_digest_module modules/mod_auth_digest.so #LoadModule authn_anon_module modules/mod_authn_anon.so #LoadModule authn_dbm_module modules/mod_authn_dbm.so #LoadModule authz_owner_module modules/mod_authz_owner.so #LoadModule authz_dbm_module modules/mod_authz_dbm.so #LoadModule authz_default_module modules/mod_authz_default.so #LoadModule ldap_module modules/mod_ldap.so #LoadModule authnz_ldap_module modules/mod_authnz_ldap.so #LoadModule dav_module modules/mod_dav.so #LoadModule autoindex_module modules/mod_autoindex.so #LoadModule dav_fs_module modules/mod_dav_fs.so #LoadModule userdir_module modules/mod_userdir.so #LoadModule proxy_module modules/mod_proxy.so #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so #LoadModule proxy_ftp_module modules/mod_proxy_ftp.so #LoadModule proxy_http_module modules/mod_proxy_http.so #LoadModule proxy_ajp_module modules/mod_proxy_ajp.so #LoadModule proxy_connect_module modules/mod_proxy_connect.so #LoadModule cache_module modules/mod_cache.so #LoadModule disk_cache_module modules/mod_disk_cache.so #LoadModule version_module modules/mod_version.so |
Apacheの使用メモリチューニングの最終結果
最終的に1プロセスあたりのメモリは158MBまで減らすことができました。これでサイトに多くの人がアクセスしても良い環境に近づきました。
当たり前ですが、この無効にしたモジュールで使っているパラメータはサービス起動しようとするとエラーで表示されますので、対象モジュール用パラメータもコメントアウトしてください。
プロセス数やスレッド数の最適化はシステム環境ごとに違いますし、他の人も紹介しているので割愛します。
コメント