WordPressには、PSRとはちがう独自のコーディング規約があります。
大部分はコード整形ツールがあるので気にする必要もないし覚えなくてもいいんですが、手作業で直さなければいけないものもあります。
今回はこの手作業が必要なコーディング規約の合わせ方です。
- まずはツールで一気に解決しよう！
- php Documentやコメント
- Use Yoda Condition checks, you must.
- Spaces must be used to indent lines; tabs are not allowed
- All output should be run through an escaping function (see the Security sections in the WordPress Developer Handbooks), found '$xxxxx'.
- All output should be run through an escaping function (like esc_html_e() or esc_attr_e()), found '_e'.
- The $text arg must be a single string literal, not '$xxxxx'.
まずはツールで一気に解決しよう！
これからWordPressコーディング規約（WordPress Coding Standards）でエラーが出たときの直し方を説明するんですが、エラーのほとんどは PHP_CodingSniffer などの静的コードチェックツールを使えば一気に無くなります。
WordPressのコーディング規約は、一般的に使われる PSR とはだいぶ違います。
PSR (PHP Standards Recommendations)
PHP標準勧告。PHPコーディングの標準化を目指す活動のこと。PHP-FIGが策定している。
PHP-FIG (PHP Framework Interop Group)
PHPフレームワーク相互運用グループ。PHPプロジェクトが集まって意見を出し合い、お互いの製品の互換性を調整する団体。
有名なプロジェクトが多く参加している。
たとえば、functionやクラスの開始括弧（ { ）は、PSRでは次行に書くのにWordPressでは半角スペース1個で空けて書きます。
function ()
{
}
class Test
{
}function () {
}
class Test {
}また、functionの () は、引数との間に半角スペース1個がないといけません。
function test($aaa, $bbb)
{
}function test( $aaa, $bbb ) {
}まずはこのようなツールで直せるものから行いましょう。手作業で修正が必要なエラーもあって、それをあぶり出せません。
今回ご紹介するエラーは、手作業で修正が必要なものです。
php Documentやコメント
WordPressのコーディング規約は、コメントを使った説明はきちんと書くようになっています。コメント作成を強制しないPSRに慣れている人は、結構な量のエラーが出る。
こちらのほうにまとめました。
まず最初に、コメントを書いていってエラーを減らしましょう。コメントを直すとエラー数が一気に減るので楽です。
Use Yoda Condition checks, you must.
WordPressでの固定値と変数の比較では、固定値を先に書く規約になっています。
if ( $post_id === 0 ) {
}if ( 0 === $post_id ) {
}Spaces must be used to indent lines; tabs are not allowed
プログラミングのインデントには2つあります。ひとつはタブ。もうひとつは半角スペース。
このエラーは、半角スペースを使いましょうというメッセージ。
プログラミングではタブの都合が悪いことがあります。タブのサイズはOSやエディタの設定で変わることがあり、サイズが大きくなると横長の読みづらいコードになるから。
それに比べ半角スペースはOSやエディタの種類に影響されずサイズは一定です。最近は半角スペースが多いのかな？
逆にタブじゃないといけないよ、というメッセージもあります。
PHPの一般的なコーディン規約の PSR は半角スペース、WordPress はタブでルールは統一されていません。
これもツールで瞬時に直せるんですが、頻繁に使うので一応紹介しました。
All output should be run through an escaping function (see the Security sections in the WordPress Developer Handbooks), found '$xxxxx'.
すべての出力は、エスケープ関数を通して実行しなければいけません。
（WordPress Developer HandbooksのSecurityセクションを参照）
見つかった変数 '$xxxxx'
筆者訳
このエラーは、おそらく最も出てくるメッセージです。コーディング規約を意識してプログラミングしないと大量に出てくる。
とくに、テーマのテンプレートは。
WordPressに限らないことなんですが、Webでのデータの入出力はエスケープ処理を通すのが常識です。これを知らないとエンジニアとして疑われるレベル。
理由は、HTMLで直接変数の値を出力すると、HTMLタグの文字列をそのままHTMLとして出力するから。そして一番の理由はセキュリティです。
たとえば、URLのクエリーにデータベースを操作するSQLを組み込んだり、出力するHTMLにJavaScriptを埋め込んだりして意図しない動きをさせることもできます。
（その他、いろいろなことができる。）
これを防ぐのがエスケープ処理。『エスケープ = 危険から逃れる』なので意味は分かりますよね？
シンプルな変数の出力
ここから、コーディング規約でエラーになるパターンを見ていきましょう。一緒に対応策もご紹介します。
まずは、単純な変数の出力から。
<div><?php echo $title; ?></div>これは、最も汎用的なエスケープ関数 esc_html()を使います。
<div><?php echo esc_html( $title ); ?></div>変数を直接出力するのではなく、エスケープ関数を通してしまえばOK。
HTMLの属性を変数で出力
HTMLの出力に変数を使う方法として、HTMLの属性を動的に出力する使い方があります。よくあるのは、class属性の値を変数で出力して、CSSでスタイルをあらかじめ定義しておき、動的にスタイルを変更したりします。
<body class="<?php echo $body_class; ?>">
</body>WordPressには属性用のエスケープ関数が用意されています。HTMLの属性を変えるときにはこれを使いましょう。
<body class="<?php echo esc_attr( $body_class ); ?>">
</body>esc_html() じゃダメなのか？ と言われれば、今のところ同じ結果になります。しかし、属性用の関数が用意されてるということは考えがあってのこと。
せっかく用意されてるんだからそれを使いましょう。
esc_attr()は、属性値だけでなく属性名でも使います。
URLの出力
エスケープ処理で最もポピュラーなものはURLのエスケープでしょう。『エスケープと言えばこれ』と思ってる人も多いのではないでしょうか？
WordPressではesc_url()を使います。
<a href="<?php $link_url;?>">くわしくはこちら</a><a href="<?php echo esc_url( $link_url );?>">くわしくはこちら</a>PHPの関数にもURLエスケープの関数があるんですが、WordPressではさらに処理を追加しています。これを使わない手はありません。というか使ってください。
<textarea>の本文出力
WordPressには<textarea>の本文用のエスケープ関数が用意されています。esc_textarea()です。
<textarea>の中身はそのまま出力すると改行がおかしなことになったりします。
もう使用前のサンプルはいいですよね？
<textarea><?php echo esc_textarea( $text ); ?></textarea>All output should be run through an escaping function (like esc_html_e() or esc_attr_e()), found '_e'.
すべての出力はエスケープ関数を通さなければいけない。
（esc_html_e()やesc_attr_e()）
_e()関数が見つかった。
筆者訳
テンプレートなどでは、翻訳関数を通して変数を出力することもあるでしょう。
<div><?php __e('タイトル', 'my-theme' ); ?></div>よく見るコーディングですが、これもコーディング規約違反です。エスケープ処理を通してないから。
WordPressには、翻訳とエスケープをまとめて処理する関数が用意されています。esc_html_e() を使います。
<div><?php esc_html_e('タイトル', 'my-theme' ); ?></div>同じように esc_attr_e() もあります。
また、echo せずに変数に保存する、esc_html__(), esc_attr__() もあります。
WordPressのエスケープ関数には、SQLのエスケープの esc_sql() やデータベースに登録する時の esc_html_raw() などがある。
こっちは入力側。つらつらと紹介してきたのは出力側。
The $text arg must be a single string literal, not "$xxxxx".
single string literal とは定数のことで、変数ではいけないという意味です。値の直書きも定数に含まれる。
このエラーはクラスのプロパティの右辺（初期値）に変数を入れたりすると起きます。
今回エラーが出たコードはこちら。
esc_html_e( $xxxxx, 'my-theme' );メッセージの $text は esc_html_e() の第1パラメータで $xxxxx の受け皿のこと。
WordPressの翻訳関数（__(), _e()など）の第1パラメータはすべて $text なんですが、これらの関数はリテラルを期待しているらしい。
だから変数を与えたものはエラーになりました。
修正はこちら。
esc_html( $xxxxx );翻訳をあきらめました。$xxxxx は処理の結果をメッセージでもってるんですが、すべてのパターンを翻訳ファイルに書いてしまえばイケると思ったらダメだった。
内容をそのまま出力しています。
