最も一般的なWordPressテーマ開発の間違い（およびそれらを修正する方法）

公開: 2019-05-14

テーマをWordPress.orgテーマディレクトリに送信することは、作業を共有し、WordPressコミュニティに貢献するための優れた方法です。現在、ディレクトリには7000を超えるテーマがあり、その中で最も人気のあるテーマは300,000を超えるアクティブなインストールです。（WordPressにパッケージ化され、インストール数が数百万のTwenty ____テーマは含まれません。）

テーマをディレクトリに送信する前に、まずレビュープロセスを理解することが重要です。テーマがこれらの要件を満たしていない場合、その場で拒否される可能性があるためです。

3つ以上の明確な問題があるテーマは、未承認としてクローズされる場合があります。ただし、テーマの作成者は、問題を修正した後、テーマを再送信できます。

https://make.wordpress.org/themes/handbook/review/required/

レビューアはあなたの味方であり、必要な基準を満たしたら、テーマが公開されることを望んでいます。テーマにディレクトリに含めることを妨げる小さな問題しかない場合は、レビュー担当者が協力してそれらを修正します。

残念ながら、テーマに問題が多すぎる場合は、未承認としてクローズされます。問題を修正することにした場合は、テーマを再度アップロードできますが、キューの後ろに参加します。

100を超えるテーマを確認した経験から、テーマの承認を妨げる最も一般的な問題を特定することができました。この記事でこれらを共有することで、キューに詰まったり拒否されたりするのを防ぐのに役立つことを願っています。

テーマをアップロードする

テーマをアップロードすると、レビュー対象のキューに参加します。テーマがキューの先頭に到達して最初のレビューを受け取るまで、平均して2か月かかります。すべてのレビュー担当者はボランティアであり、レビューを完了するために利用できる時間は限られています。さまざまな要因が待機時間に影響を与える可能性があります。より多くの人がテーマをレビューするボランティアをするとき、キューはすぐに移動します。逆に、問題の多いテーマが送信されると、キューが遅くなります。

すべての要件を満たすテーマを送信することで、レビュープロセスが非常にスムーズになり、最終的にテーマがより早く公開されます。このガイドでは、テーマをキューに入れて承認されないようにする最も一般的な問題について説明します。

注：問題のないテーマを提出した実績のあるテーマ作成者は、「信頼できる作成者」になるために申請できます。

命名の問題

テーマをアップロードするときに実行される最初のチェックは、名前がすでに使用されているかどうかを確認することです。ディレクトリにその名前のテーマが表示されていない場合でも、選択した名前はすでに使用されていると通知されることがよくあります。

どうしてそうなるのでしょうか？その理由は、テストがディレクトリだけをチェックするのではなく、WordPressエコシステム全体をチェックするためです。テーマがどこか（Github、ThemeForestなど）でリリースされており、50を超えるアクティブなインストールがある場合、その名前は使用できなくなります。

注：テーマを他の場所でリリースし、50以上のインストールを蓄積した場合でも、ディレクトリでその名前を使用できます。

エスケープされていない出力

テーマレビューアはセキュリティを非常に真剣に受け止めており、専用のリソースもあります。安全なテーマの作成について記事全体を書くこともできますが、このセクションでは、出力のエスケープという1つの側面について説明します。

エスケープされていない出力は、テーマのユーザーを危険にさらします。エスケープされていない値（$ title）の例を次に示します。

 $ title = get_option（ 'my_custom_title'）;
エコー '<h2>'。 $ title。 '</ h2>';

上記の問題は、$ titleの値のタイプ（文字列）はわかっているものの、それが当てはまるかどうかを確認していないことです。

ハッカーがデータベース内の「my_custom_title」の値を変更した場合、テーマはその値を出力します。意図した出力をインラインJavascriptに置き換える可能性があるため、これには大きなリスクが伴います。

 alert（ 'これは危険です'）;

解決策は、すべての出力をエスケープして、期待するタイプのデータのみが含まれるようにすることです。

この例は次のように修正できます。

 $ title = get_option（ 'my_custom_title'）;
エコー '<h2>'。 esc_html（$ title）。 '</ h2>';

esc_htmlを使用することの欠点は、すべてのHTMLタグを削除することです。 $ titleに太字または斜体が含まれている場合、次に例を示します。

 $ title = 'この記事は<strong>非常に</ strong>役に立ちます';
echo esc_html（$ title）;

「非常に」という言葉は、フロントエンドでは太字ではありません。代わりに、コードを<strong>非常に</ strong>出力します。

これは、コンテキストに適切なエスケープ関数を使用することが重要である理由を示しています。出力にHTMLが含まれていると予想される場合は、wp_kses_post（）またはwp_kses（）を使用し、$ allowed_htmlパラメーターを設定することをお勧めします。

出力する関数もエスケープする必要があります。

 <a href="<?php echo esc_url(get_permalink()）;?> ">

例外は、名前に「the_」を含むWordPressコア関数です。これらは通常、すでにエスケープされています。

 関数the_permalink（$ post = 0）{
    / **
     *現在の投稿のパーマリンクの表示をフィルタリングします。
     *
     * @since 1.5.0
     * @since 4.4.0 `$ post`パラメータを追加しました。
     *
     * @param string $ permalink現在の投稿のパーマリンク。
     * @param int | WP_Post $ post投稿ID、WP_Postオブジェクト、または0。デフォルトは0。
     * /
    echo esc_url（apply_filters（ 'the_permalink'、get_permalink（$ post）、$ post））;
}

翻訳できないテキスト

ディレクトリに受け入れられるには、すべてのテーマが100％「翻訳対応」である必要があります。つまり、テーマが出力する各テキスト文字列は翻訳可能でなければなりません。

WordPressには、翻訳プロセスを処理するためのシステムと機能がすでに備わっています。文字列が正しい関数を使用していることを確認する必要があります。

実装は簡単ですが、これは人々がHTMLを書く方法の流れに反するため、見過ごされがちです。

通常、次のようなことを行うことができます。

 <h1> 404-見つかりません</ h1>

翻訳可能にするには、PHPを追加する必要があります。

 // __関数はローカリゼーションの基礎です。
<h1> <？php echo __（ '404'、 'text-domain'）; ？>

// _ e関数は値をエコーします。
<h1> <？php _e（ '404'、 'text-domain'）; ？>

//文字列をエスケープしてエコーします。
<h1> <？php esc_html_e（ '404'、 'text-domain'）; ？>

//ローカリゼーションと変数。
<h1> <？php _n（ '1つの投稿'、 '％sの投稿'、$ count、 'text-domain'）; ？>

関数によって出力される文字列も、翻訳に対応している必要があります。

 //翻訳対応ではありません:-(
<？php next_posts_link（ '古いエントリ'）; ？>

//翻訳対応:-)
<？php next_posts_link（esc_html __（ '古いエントリ'、 'text-domain'））; ？>

ヒント：codex.wordpress.orgの多くのコード例では翻訳関数を使用していないため、それらをコピーして貼り付ける場合は注意が必要です。

リソースを誤ってエンキューする

テーマが使用する.cssファイルと.jsファイルは、正しい関数を使用してキューに入れる必要があります。CSSの場合はwp_enqueue_style（）、Javascriptの場合はwp_enqueue_script（）です。

一般的なエラーは、スクリプトとスタイルを<head>に直接または</ body>の前にハードコーディングすることです。このアプローチには2つの問題があります。

1.削除できません

プラグインがロードしたリソースを削除する必要がある場合、それは不可能です。適切なエンキュー関数を使用した場合は、次のように実行できます。

 / **
 *テーマのJavaScriptをデキューします。
 *
 * wp_enqueue_scriptsアクションにフックし、優先度が遅い（100）、
 *スクリプトがエンキューされた後になるようにします。
 * /
関数wptavern_dequeue_script（）{
   wp_dequeue_script（ 'theme-scripts'）;
}
add_action（ 'wp_enqueue_scripts'、 'wptavern_dequeue_script'、100）;

2.重複読み込み

リソース（たとえばjQuery）をエンキューし、プラグインもそれをエンキューする場合、WordPressはリソースを1回だけロードするのに十分賢いです。

 / **
 * jQueryをエンキューします
 *
 * jQueryは、2つのエンキューにもかかわらず、1回だけロードされます。
 * jQueryはWordPressにパッケージ化されているため、srcを指定する必要はありません。 
 * /
関数wptavern_enqueue_script（）{
   wp_enqueue_script（ 'jquery'）;
   wp_enqueue_script（ 'jquery'）;
}
add_action（ 'wp_enqueue_scripts'、 'wptavern_enqueue_script'）;

代わりに、jQueryを<head>にハードコーディングした場合、WordPressが知る方法はなく、2回読み込まれます。

プラグイン-テリトリー機能

テーマの範囲は、Webサイトのデザインと美学のみを処理する必要があり、他のすべての機能は、WordPress自体またはプラグインによって処理する必要があります。

テーマにさらに価値を加えるために、テーマの作成者は、SEOコントロールやカスタム投稿タイプなどの追加機能を取り入れようとすることがよくあります。

機能をテーマにバンドルする際の問題は、データが移植できないことです。 SEOコントロールを例にとると、ユーザーがテーマを変更すると、ページを最適化するために行ったすべての作業が失われます。対照的に、SEOプラグインを使用すると、データと機能はテーマに依存せず、テーマを変更しても保持されます。

プラグインテリトリー機能のいくつかの例：

分析/追跡
SEOコントロール
お問い合わせフォーム
ショートコード
グーテンベルクブロック

ヒント：コードがデータベースに書き込む場合、プラグインの領域である可能性が高くなります。例外は、デザイン関連の設定（サイドバーの位置、色など）です。

接頭辞なし

プレフィックスは、コードがプラグインのコードと衝突しないようにする方法です。 PHPでの名前空間は、同じ効果を実現するためのより良い方法です。ただし、一部のユーザーは、その機能をサポートしていない古いバージョンのPHP（5.2）をまだ使用しています。

Justin Tadlockは、接頭辞を付ける必要がある一般的なもののリストを共有しました。

PHP関数名。
PHPクラス名。
PHPグローバル変数。
アクション/フィルターフック。
スクリプトハンドル。
スタイルハンドル。
画像サイズ名。

ソース：https：//themereview.co/prefix-all-the-things/

 //関数の例。
my_prefix_example（）;

//クラスの例。
クラスMy_Prefix_Example {…}

//アクションとフィルターの例。
do_action（ 'my_prefix_action'）;
apply_filters（ 'my_prefix_filter'、$ values）;

//例をキューに入れます。
wp_enqueue_script（ 'my_prefix_script'、get_template_directory_uri（）。 '/ js / custom-script.js'）;
wp_enqueue_style（ 'my_prefix_style'、get_template_directory_uri（）。 '/ css / styles.css'）;

//画像サイズの例。
add_image_size（ 'my_prefix_image_size'、220、180）; //幅220ピクセル、高さ180ピクセル。

例外：サードパーティのリソースをキューに入れるときは、プレフィックスを追加しないでください。

 //サードパーティのスクリプト（chosen.js）をエンキューします。
 wp_enqueue_script（ 'chosen'、get_template_directory_uri（）。 '/ js / chosen.js'）;

ライセンスの問題

テーマとそのすべてのファイルは、100％GPL互換である必要があります。これには、画像、ライブラリ、スクリプト、およびフォントが含まれます。

すべてのサードパーティリソースは、ソースとライセンス情報をリストする必要があります。

すべてのライセンスがGPLに対応しているわけではないため、この要件は特に注意が必要です。 Unsplashライセンスには、次の1つの制限のみがあります。

「このライセンスには、Unsplashから写真を編集して、類似または競合するサービスを複製する権利は含まれていません。」

ただし、この1つの制限は、GPLと互換性がないようにするのに十分であるため、wordpress.orgテーマに含まれるUnsplash画像は表示されません。

GPL互換ライセンスのリストはこちらから入手できます– https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

最近、 stocksnap.ioは、リストされているすべての画像がCC0（GPL互換）としてライセンスされているため、ディレクトリ内の画像の最も一般的なソースです。

スクリーンショットの間違い

要件では、スクリーンショットは、広告のように見えないテーマの編集されていない表現である必要があると規定されています。つまり、フォトショップの作業、オーバーレイ、境界線、または派手な効果はありません。

画像も、上記で検討したのと同じライセンス要件に従う必要があります。

ボーナス：コーディング標準を使用する

読みやすく理解しやすいと思われるコードは、コードをチェックするのに10〜15分しかかからないレビュー担当者にとっては正反対の場合があります。

コーディング標準に関する要件はありませんが、それに従うと、コードが読みやすく、理解しやすくなり、保守しやすくなります。他にもありますが、私は個人的に「WordPressコーディング標準」を使用して推奨しています。

コードエディターでPHP_CodeSnifferとWordPressルールセットを使用すると、標準への準拠がはるかに簡単になります– https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

結論

テーマ要件は、エンドユーザーを念頭に置いて作成されます。上に挙げたよくある間違いをしないでください。そうすれば、あなたのテーマはすぐに承認されます。反対側からレビュープロセスを体験したい場合は、レビュー担当者になることもできます。