WordPressのローカライズ、つまり日本語化 – その1 _関数と_e関数

「WordPressのローカライズ、つまり日本語化」は3部に分けて書いています。
WordPressのローカライズ、つまり日本語化 – その2 gettextとPoeditとpot
WordPressのローカライズ、つまり日本語化 – その3 poとmo

今回は「WordPressのプラグインのローカライズ、つまり日本語化 – その1 __関数と_e関数」です。

WordPressを使っていると、お世話になるのがプラグインです。
しかし、世界中で使われているWordPressですから、そのプラグインも海外のものが圧倒的に多く、表示は外国語だったりするわけです。
誰でも使い易いサイトを作る為には、プラグインの日本語へのローカライズが必要になります。

ではどうするか?
プラグインのコードを眺め、手当り次第、外国語で表示される部分を日本語訳に書き換えていくわけではないんですね。

gettextを使います。

gettextはソフトウェアの多言語化の為のライブラリーとツール群の事を言います。
英文で表示されるプログラム内の他言語に翻訳して表示させたい英文を関数やマクロでラップし、その英文を言語ファイルから呼び込んだ他言語の翻訳文に置き換える為に使う関数やツールをまとめてgettextと言うんですね。

C言語はもとよりC++やObjective-C、Bourne ShellやBashの様なUnixシェル、Python、Perl、Ruby、PHPなどのスクリプト、JavaやSmalltalk[GNU]やAwk[GNU]やPascalその他、多くのプログラム言語で採用されています。
WordPressは、PHPで書かれていますから、gettextを使えるわけです。

gettextのキーワードは__関数_e関数と、言語ファイル(.pot .po .mo)、Poeditです。

wikipedia gettext
WordPress私的マニュアル __
WordPress私的マニュアル _e

今回は、触りの__関数_e関数について。

__関数_e関数もWordPressのテンプレートタグで、翻訳したテキストを取得したり表示させたりするものです。__関数の__は_(アンダースコア)を2つ並べたもの。_e関数は_(アンダースコア)1つにeです。

プラグイン内に

を打ち込んでおき、プラグイン用に作った単語・文の翻訳一覧を載せた言語ファイルから該当するものを取得または表示させます。

__関数と_e関数の違いは、_e関数が__関数に出力機能を持たせたもので、WordPressのテンプレートタグで言うなら、get_bloginfo関数(__関数の方)とbloginfo関数(_e関数の方)の関係と同じです。

プラグイン内では大体__関数・_e関数が使われていますが、エスケープ処理をした翻訳テキストを取得する場合はesc_attr__関数、翻訳テキストを出力させる場合はesc_attr_e関数、htmlを取得する場合はesc_html__関数、htmlを出力するにはesc_html_e関数が用意されています。

WordPress私的マニュアル esc_attr__
WordPress私的マニュアル esc_attr_e

具体的な例をプラグイン「WP Multibyte Patch」の「wp-multibyte-patch.php」で見てみると、

3行目に__関数が使われていて、その中の
Sorry, WP Multibyte Patch requires WordPress %s or later. ‘ が翻訳する英文の文字列
wp-multibyte-patch‘ がドメイン名です。

ドメイン名と言うのは、このプラグインで使う言語ファイルを識別する為のもので、ドメイン名の後に 翻訳後の言語の略称.moを付けるとその言語ファイル名になります。
日本語に翻訳する言語ファイルなら、「ドメイン名-ja.mo」
ドメイン名「wp-multibyte-patch」の日本語ファイルなら、「wp-multibyte-patch-ja.mo」
となります。

言語ファイル「wp-multibyte-patch-ja.mo」
に書き込まれている
Sorry, WP Multibyte Patch requires WordPress %s or later.
に対応する日本語訳が、この__関数の部分に入ります。
ここの__関数はsprintf関数の第1引数になっているので、この英文内の%sにsprintf関数の第2引数の$required_version(このWP Multibyte Patchが使用できるWordPressのバージョン)が代入されます。

これがスクリプトの

ここで「.mo」と言う拡張子が出てきましたので、次回は言語ファイルgettextPoeditについて。

wp-login.phpのデバッグ忘れ(WordPressのデバッグ方法)

WordPressは頻繁にバージョンアップします。
バージョンアップでセキュリティーが強化されたりするわけで、WordPressを使ったサイトは最新の状態を維持する様に、常に最新のバージョンにしておくのがサイト管理の基本になっているわけです。

しかしこのバージョンアップで機能も向上します。その機能向上の為、使えなくなったり、非推奨となるテンプレートタグが出てくるわけです。

それに気が付かずに放置していると、表示がおかしくなる・動作がおかしくなる・まともに動かないなどという危険な状態になるんですね。

そうならない様に事前にチェックする為、またthemeやplugin開発時のデバッグの為に、WordPressにはデバッグモードが用意されているわけです。

デバッグモードを有効にするには、サイトのディレクトリ直下に有るwp-config.phpの84行位に有る define(‘WP_DEBUG’, false); を define(‘WP_DEBUG’, true); 変更・保存してやれば良いだけです。
(余談ですが、wp-config.phpは、1つ上の階層の非公開ディレクトリへ移動させた方がセキュリティー的に良いみたい。)

テンプレートに何か問題が有る場合、ブラウザーでサイトを表示させるとエラーメッセージが表示されます。
functions.php内に原因が有る場合は大体ページ冒頭に、plug-inの場合もページ冒頭か、そのプラグインで表示されている要素の始めに、テンプレートファイルの場合は、そのテンプレートに内容が表示されている部分の始めの箇所に、エラーメッセージは表示されます。

因にこのデバッグモードはオプションが有りまして、
① wp-contentフォルダ内にdebug.logとして記録させたり
② ブラウザには表示させなくしたりできます。

デバッグモードの詳細や、他のオプションについては
CodexのDebugging_in_WordPress
で詳しく説明されています。

前置きが長くなりましたが、これからが本題。

今迄デバッグした後は、wp-config.php の define(‘WP_DEBUG’, true); を元の define(‘WP_DEBUG’, false); に戻して保存し、wp-config.phpのパーミッションを400にして書き込みできなくした後、WordPressをログアウトさせていました。それが習慣みたいになってました。

それがたまたま手順を逆にしてしまい、wp-config.php を define(‘WP_DEBUG’, false); に戻す前にWordPressのログアウトしてしまったんですね。

すると wp-login.php のログイン画面上に

get_bloginfo(‘home’); は2.2から非推奨

とエラーメッセージが表示されたんですよ。

2.2からとはWordPressのver.2.2からと言う事です。WordPressって、今のver.は4.5.2なんですよ。

「ver.2.2って、いったいいつの時代の事なんだよ!」
「どれほどの年月、気が付かずにいたの?」

我ながら、自分の間抜けさに飽きれてしまいましたよ。

原因のget_bloginfo(‘home’) はログイン画面のカスタマイズで使っていたものです。get_bloginfo(‘home’) はサイトアドレスを取得するのに使っていましたが、2.2以降は非推奨です。
現在では get_bloginfo(‘url’)  か home_url() を使う事になっています。

しかし、ログイン画面のデバッグと言うのは盲点でした。
上にも書いた方法で、debug.logを残す様にしておけばよかったんですね。

これはデバッグの盲点でした。お気を付け下さい。

 

WordPressで投稿記事編集中、更新ボタンが
押せなくなった時の対処法

現象

管理しているWordPressのサイトで、バージョンを4.5.2にアップしてから投稿記事作成時に「更新」ボタンが押せなくなる現象が、たびたび起きる様になりました。

更新ボタンがグレイアウト

今迄起きなかった事なので、WordPressのバージョンアップによるpluginの不適合かと思い、色々試しましたが駄目。

同じ様な現象似合っている人はいないか?とネット上を探してみると、何例も見つかりました。

アプリ徹底紹介 – WordPress で記事編集中に [下書き保存/プレビュー/公開/更新] ボタンがグレーアウトして押せない時の対処方法

Simple Stock 3.1 – WordPressで記事の公開/更新ボタンがグレーアウトしてしまう問題の対処方法

枯れてます – WordPressで公開ボタンが押せない

原因

同じ様な現象がロリポップのサーバに置いたWordPressで起きていました。どうもWAFが原因の様です。
うちの問題の起きたサイトも、ロリポップのサーバを使っています。

WAFとはWeb Application Firewallの略で、Webサイト上のアプリケーションに特化したファイアウォールです。
CMSなどリクエストを受けて動的なページを生成するタイプのWebアプリを、不正ログインや改竄・情報詐取などから防ぐものです。
WordPressで投稿記事を打ち込んでいると自動保存しますが、WAFが自動保存を不正なアクセスと判断して、通信をブロックしてしまうみたいです。ロリポップのWAFの設定が強力すぎるんでしょうね。

このブロックは投稿記事の自動保存だけではなく、管理画面外観 > テーマの編集でPHPやCSSを編集した場合も、保存時にブロックされてしまう様です。

キャリコ – WordPress で「 下書きを保存しています… 」が永遠に終わらない原因はロリポップの WAF だった

ロリポップサーバのWAFと言えば、以前、外部サイトをスクレイピングしてWordPressで表示させるスクリプトの実行をブロックされた事も有ります(まあ当然と言えば当然か)。

対策方法

対策としては、

① WAF自体を無効にする。

ロリポップサーバのユーザー専用ページ > WAF設定 で、該当WordPressサイトの設定変更ボタンを無効にするに設定する。
WAFの設定

② WordPressの自動保存を解除する

FTPクライアントでサイトのルートディレクトリに有るwp-config.phpのパーミッションを600に変更し、テキストで開いて編集します。
wp-config.phpの最後の方に有る

より後ろに

を入れます。
終了後は、wp-config.phpのパーミッションを400に戻すのをお忘れなく。

この①②のどちらかを行えば更新ボタンを押せない問題は解決します。

ロリポップは3年前に8438件の大量ハッキングを受けた為、セキュリティーの設定を強くしていると思われます。
しかし、その副作用で通常の操作に支障をきたすのは困ったものです。対処方法も判らず困惑している人も多いでしょうし、こうした情報は広く知ってもらうのが良いと思われます。

is_dynamic_sidebar()と dynamic_sidebar()のID指定の違い

WordPressでサイトを作成するとき、どんなサイトでも使うであろうWidget。
手軽に設置できて便利ですよね。

自作のTemplateでWidgetを使う場合、まず自作Theme内のfunctions.phpに

などと書き加え、Widget表示箇所の’name’とその前後のtagやタイトルのtagをしていしておきます。

そしてWidgetを表示させたい箇所、例えばsidebar.phpなどに

と書き込んでおけば、「ダッシュボード > 外観 > ウィジェット」の右側に表示される「hoge-hoge-1」のセクションに、目的のWidgetをドラッグする事で使える様になります。

は ‘hoge-hoge-1’ でWidgetを使っていない場合、functions.php内で設定した、Widgetの前後に表示されるtagも一緒に表示されなくなります。

これとは別に、Widgetが有効か(使っているか)を判定するtemplate tagに is_active_sidebar( ) があります。

‘hoge-hoge-1’ の有効判定をさせようと

とやっても、何も表示されません。

がbool(false)となるのです。

???と思い、「wp-includes/widgets.php」を見てみると、WordPress3.8なら975行目で

となっているのですが、wp_get_sidebars_widgets()で取り出した連想配列のkeyが「sidebar-整数」の型にしてやらないといけないんですね。
is_active_sidebar( $index )の$indexは「整数」か「sidebar-整数」しか使えず、「整数」の場合は前に「sidebar-」が加えられ、「sidebar-整数」の型に整形されて$indexに代入されます。

print_r(wp_get_sidebars_widgets())の結果が

となり、keyは「sidbar-整数」の型になっていますから、is_active_sidebar(‘hoge-hoge-1’)と、functions.phpで設定した ‘name’ は使えないわけです。

「sidbar-1」「sidbar-2」「sidbar-3」の整数は、functions.phpのregister_sidebar()でWidgetを設定した時、上の方から順に番号が振られます(追加でWidgetを設定した場合は追加分が一番大きい数字になる)。

is_active_sidebar(‘hoge-hoge-1’)はfunctions.phpのregister_sidebar()で最初に設定したものなので、is_active_sidebar(‘sideber-1’)とし

とすると「true」と表示されました。

因に、dynamic_sidebar()は、「wp-includes/widgets.php」のWordPress3.8なら845行目に書かれています。

となっています。
$wp_registered_sidebarsでWidgetの情報を連想配列として取得し、各値の ‘name’ をインデックスとして使っています。
$wp_registered_sidebarsをprint_r()で表示させてみると、

となっています。
この違いがあるので、dynamic_sidebar()functions.phpのregister_sidebar()で設定した ‘name’ が使えるんですね。

WordPressが3.7になったから?PHP5.4の所為?・・・UserHeatで<head>内の要素が<body>内に落ちてしまう。

User Heat

「HeatMap」、使ってますか?

地域やモノの温度の違いを色で表し、画像化・映像化したものです。夏の暑さを色分けした地図など、ニュースなどでよく見かけるアレです。

Webでも、サイトを観に来た人がページ上をどの様に観ていき、どこをクリックしたかを、多い/少ない→暑い/暑くないに置き換えて同じ様な表示方法で見せてくれますね。

(こんな感じです↓)

Heat Mapはこんな感じ

SEOのデータとして、サイトがどう見られているかがわかったりするもんで、なかなか面白かったりします。

私はUserHeat(http://userheat.com/)という無料のサイトを使っていたんですが、WordPressを3.7に、使っているPHPを5.4にアップした時、何故かWordPressが出すhtmlがおかしくなったんですよ。

<head></head>内にあるべき<script>や<link>などが大量に<body></body>内に落ちてしまうんです。

こんなケースは大体PHPファイルのエンコードが「UTF-8 with BOM」になっているか、プラグインの関数がサーバで指定したPHPのバージョンでは使えなかったり、中には「<?〜?>」とか「<%〜%>」みたいな古いスクリプティングデリミタを使っていたからなんてのも有ったりしましたが、今回はそうでもない。

という事になると、<head></head>内に書き込んだJavaScriptが臭い。

チェックしてみると、UserHeatの解析用JavaScriptがワルサしてたんですね。google経由で呼び込まれるJavaScriptとぶつかってるのかな?全てのプラブインを外してもなってしまうんですよ。

残念ながら、解決方法が見つかる迄は使えないという事になりました。
助かっていたんですが。

因にHeat Map toolのサイトは、

があります。