WordPress開発者が犯す10の最も一般的な間違い

公開: 2022-03-11

私たちは人間だけであり、人間であることの特徴の1つは、間違いを犯すことです。一方、私たちは自己修正も行っています。つまり、私たちは自分の過ちから学ぶ傾向があり、それによって同じものを2回作成することを回避できることを願っています。私がWordPressの領域で犯した多くの間違いは、ソリューションを実装するときに時間を節約しようとすることに起因しています。ただし、このアプローチの結果として問題が発生した場合、これらは通常、頭を下げます。間違いを犯すことは避けられません。しかし、他の人の見落とし（そしてもちろんあなた自身の見落とし）から学ぶことは、あなたが積極的にとるべき道です。

エンジニアはスーパーヒーローのように見えますが、私たちはまだ人間です。私たちから学びましょう。

つぶやき

よくある間違いその1：デバッグをオフにしておく

コードが正常に機能しているのに、なぜデバッグを使用する必要があるのですか？デバッグはWordPressに組み込まれている機能であり、すべてのPHPエラー、警告、および通知（非推奨の機能など）が表示されます。デバッグをオフにすると、重要な警告や通知が生成されることはありませんが、時間内に処理しないと、後で問題が発生する可能性があります。コードをサイトの他のすべての要素とうまく連携させたいと考えています。したがって、WordPressに新しいカスタムコードを追加するときは、常にデバッグをオンにして開発作業を行う必要があります（ただし、サイトを本番環境にデプロイする前に必ずオフにしてください）。

この機能を有効にするには、WordPressインストールのルートディレクトリにあるwp-config.phpファイルを編集する必要があります。典型的なファイルのスニペットは次のとおりです。

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

これは、使用できる構成オプションの完全なリストではありませんが、この推奨されるセットアップは、ほとんどのデバッグニーズに十分なはずです。

よくある間違いその2： `wp_head`フックを使用したスクリプトとスタイルの追加

スクリプトをヘッダーテンプレートに追加することの何が問題になっていますか？ WordPressには、すでに多数の人気のあるスクリプトが含まれています。それでも、多くの開発者はwp_headフックを使用してスクリプトを追加します。これにより、スクリプトは同じになりますが、バージョンが異なり、複数回読み込まれる可能性があります。

ここでのエンキューは、WordPressに適したスクリプトとスタイルをWebサイトに追加する方法です。プラグインの競合を防ぎ、スクリプトが持つ可能性のある依存関係を処理するために、エンキューを使用します。これは、組み込み関数wp_enqueue_scriptまたはwp_enqueue_styleを使用して、スクリプトとスタイルをそれぞれエンキューすることで実現されます。 2つの関数の主な違いは、 wp_enqueue_scriptには、スクリプトをページのフッターに移動できる追加のパラメーターがあることです。

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

折り目の上のコンテンツをレンダリングするためにスクリプトが必要ない場合は、スクリプトをフッターに安全に移動して、折り目の上のコンテンツがすばやく読み込まれるようにすることができます。スクリプトをキューに入れる前に、最初にスクリプトを登録することをお勧めします。これにより、他の人がプラグインのコアコードを変更せずに、自分のプラグインのハンドルを介してスクリプトの登録を解除できるようになります。これに加えて、登録されたスクリプトのハンドルが、エンキューされた別のスクリプトの依存関係の配列にリストされている場合、そのスクリプトは、強調表示されたエンキューされたスクリプトをロードする前に自動的にロードされます。

よくある間違いその3：子テーマの回避とWordPressコアファイルの変更

テーマを変更する場合は、必ず子テーマを作成してください。一部の開発者は、テーマへのアップグレード後に変更が上書きされて永久に失われたことを発見するためにのみ、親テーマファイルに変更を加えます。

子テーマを作成するには、次の内容のstyle.cssファイルを子テーマのフォルダーのサブディレクトリに配置します。

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

上記の例では、デフォルトのWordPressテーマであるTwentySixteenに基づいて子テーマを作成します。このコードの最も重要な行は、「テンプレート」という単語を含む行です。これは、子のクローンを作成する親テーマのディレクトリ名と一致する必要があります。

同じ原則がWordPressコアファイルにも当てはまります。コアファイルを変更して簡単な方法をとらないでください。 WordPressのプラグイン可能な関数とフィルターを使用して、WordPressのアップグレード後に変更が上書きされないようにすることで、余分な労力を費やしてください。プラグ可能な関数を使用すると、一部のコア関数をオーバーライドできますが、この方法は徐々に段階的に廃止され、フィルターに置き換えられています。フィルタは同じ最終結果を達成し、WordPress関数の最後に挿入されて、出力を変更できるようにします。プラグイン可能な関数を使用する場合、このラッパーなしで同じプラグイン可能な関数をオーバーライドしようとすると致命的なエラーが発生するため、常に関数をif ( !function_exists() )でラップするのがコツです。

よくある間違いその4：値のハードコーディング

多くの場合、コードのどこかに値（URLなど）をハードコーディングする方が速いように見えますが、その結果として発生する問題のデバッグと修正にかかる時間ははるかに長くなります。対応する関数を使用して目的の出力を動的に生成することにより、コードのその後のメンテナンスとデバッグを大幅に簡素化します。たとえば、サイトをテスト環境からハードコードされたURLを使用して本番環境に移行すると、突然、サイトが機能していないことに気付くでしょう。これが、ファイルパスとリンクを生成するために以下にリストされているような関数を使用する必要がある理由です。

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

ハードコーディングのもう1つの悪い例は、カスタムクエリを作成する場合です。たとえば、セキュリティ対策として、デフォルトのWordPressデータテーブルプレフィックスをwp_からwp743_などのもう少しユニークなものに変更します。テーブルプレフィックスは環境間で変わる可能性があるため、WordPressのインストールを移動すると、クエリは失敗します。これを防ぐために、 wpdbクラスのテーブルプロパティを参照できます。

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

テーブル名に値wp_usersを使用していないことに注意してください。代わりに、WordPressに処理させています。これらのプロパティを使用してテーブル名を生成すると、正しい結果を確実に返すのに役立ちます。

よくある間違いその5：サイトのインデックス作成を妨げない

検索エンジンに自分のサイトのインデックスを作成させたくないのはなぜですか？インデックス付けは良いですよね？ええと、ウェブサイトを構築するとき、あなたはそれを構築し終えてパーマリンク構造を確立するまで、検索エンジンがあなたのサイトにインデックスを付けることを望まないでしょう。さらに、サイトのアップグレードをテストするステージングサーバーがある場合、Googleのような検索エンジンがこれらの重複ページのインデックスを作成することは望ましくありません。区別できないコンテンツが複数ある場合、検索エンジンは、どのバージョンが検索クエリにより関連性があるかを判断するのが困難です。このような場合、検索エンジンはコンテンツが重複しているサイトにペナルティを科し、その結果、サイトの検索ランキングが低下します。

以下に示すように、 WordPressの読書設定には、「検索エンジンがこのサイトのインデックスを作成しないようにする」というチェックボックスがありますが、「このリクエストを受け入れるのは検索エンジン次第です」という重要な注意事項があります。

多くの場合、検索エンジンはこの要求を尊重しないことに注意してください。したがって、検索エンジンがサイトのインデックスを作成しないようにする場合は、 .htaccess .htaccessを編集して次の行を挿入します。

 Header set X-Robots-Tag "noindex, nofollow"

よくある間違いその6：プラグインがアクティブかどうかをチェックしない

プラグインが常にオンになっているのに、プラグイン機能が存在するかどうかを確認する必要があるのはなぜですか？確かに、99％の確率でプラグインがアクティブになります。しかし、何らかの理由で非アクティブ化された場合の1％の時間はどうでしょうか。これが発生した場合、Webサイトに醜いPHPエラーが表示される可能性があります。これを防ぐために、関数を呼び出す前に、プラグインがアクティブであるかどうかを確認できます。プラグイン関数がフロントエンドを介して呼び出されている場合、関数is_plugin_active()を呼び出すためにplugin.phpライブラリを含める必要があります。

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

この手法は通常、非常に信頼性があります。ただし、作成者がメインプラグインのディレクトリ名を変更した場合があります。より堅牢な方法は、プラグインにクラスが存在するかどうかを確認することです。

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

作成者がプラグインのクラスの名前を変更する可能性は低いため、通常はこのメソッドを使用することをお勧めします。

よくある間違いその7：リソースの読み込みが多すぎる

ページのプラグインリソースの読み込みを選択する必要があるのはなぜですか？ユーザーが移動したページでプラグインが使用されていない場合、プラグインのスタイルとスクリプトをロードする正当な理由はありません。必要な場合にのみプラグインファイルをロードすることで、ページのロード時間を短縮でき、エンドユーザーエクスペリエンスが向上します。たとえば、WooCommerceサイトでは、プラグインをショッピングページにのみロードする必要があります。このような場合、肥大化を減らすために、他のすべてのサイトページにロードされているファイルを選択的に削除できます。テーマまたはプラグインのfunctions.phpファイルに次のコードを追加できます。

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

スクリプトは、登録されたハンドルを介して関数wp_dequeue_script($handle)を使用して削除できます。同様に、 wp_dequeue_style($handle)は、スタイルシートがロードされないようにします。ただし、これを実装するのが難しすぎる場合は、投稿タイプやページ名などの特定の基準に基づいてプラグインを選択的にロードする機能を提供するプラグインオーガナイザーをインストールできます。 W3Cacheなどのキャッシュプラグインを無効にして、行った変更を反映するためにキャッシュを定期的に更新する必要がないようにすることをお勧めします。

よくある間違いその8：管理バーを維持する

WordPress管理バーをすべての人に表示したままにすることはできませんか？はい、ユーザーに管理ページへのアクセスを許可することができます。ただし、これらのページは、選択したテーマと視覚的に統合されておらず、シームレスな統合を提供していないことがよくあります。サイトをプロフェッショナルに見せたい場合は、管理バーを無効にして、独自のフロントエンドアカウント管理ページを提供する必要があります。

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

上記のコードをテーマのfunctions.phpファイルにコピーすると、サイトの管理者の管理バーのみが表示されます。 WordPressのユーザーロールまたは機能をcurrent_user_can($capability)関数に追加して、ユーザーが管理バーを表示できないようにすることができます。

よくある間違いその9：GetTextフィルターを利用しない

CSSまたはJavaScriptを使用してボタンのラベルを変更できますが、何が問題になっていますか？ええ、はい、できます。ただし、代わりにgettextと呼ばれるWordPressで最も便利なフィルターの1つを使用できる場合は、ボタンをレンダリングするための余分なコードと余分な時間が追加されます。プラグインのtextdomain （WordPressがロードされたすべての翻訳を区別できるようにする一意の識別子）と組み合わせて、 gettextフィルターを使用して、ページがレンダリングされる前にテキストを変更できます。関数load_plugin_textdomain($domain)のソースコードを検索すると、問題のテキストを上書きするために必要なドメイン名が表示されます。評判の良いプラグインは、プラグインの初期化時にプラグインのtextdomainが設定されていることを確認します。変更したいテーマのテキストの場合は、コードのload_theme_textdomain($domain)行を検索します。もう一度例としてWooCommerceを使用すると、「関連製品」の見出しに表示されるテキストを変更できます。次のコードをテーマのfunctions.phpファイルに挿入します。

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

このフィルターフックは、テキストtextdomainが前述の関数を介して設定されている限り、国際化関数__()および_e()によって翻訳されたテキストに適用されます。

 _e( 'Related Products', 'woocommerce' );

プラグインでこれらの国際化関数を検索して、カスタマイズできる他の文字列を確認してください。

よくある間違いその10：デフォルトのパーマリンクを維持する

デフォルトでは、WordPressは投稿のIDを持つクエリ文字列を使用して、指定されたコンテンツを返します。ただし、これはユーザーフレンドリーではなく、ユーザーはURLをコピーするときにURLの関連部分を削除する可能性があります。さらに重要なことに、これらのデフォルトのパーマリンクは検索エンジンに適した構造を使用していません。「きれいな」パーマリンクと呼ばれるものを有効にすると、URLに投稿タイトルの関連キーワードが含まれるようになり、検索エンジンのランキングのパフォーマンスが向上します。特にサイトがかなりの期間実行されていて、検索エンジンによってすでに何百もの投稿がインデックスに登録されている場合は、パーマリンクを遡及的に変更しなければならないのは非常に困難な作業になる可能性があります。したがって、WordPressをインストールした後は、パーマリンクの構造を、単なる投稿IDよりも検索エンジンに適したものにすぐに変更するようにしてください。私は通常、私が構築するサイトの大部分に投稿名を使用しますが、利用可能なパーマリンク構造タグを使用して、パーマリンクを好きな形式にカスタマイズできます。

結論

この記事は、WordPress開発者が犯した間違いの完全なリストではありません。ただし、この記事から取り上げるべきことが1つあるとすれば、それは決してショートカットをとるべきではないということです（そして、それはWordPressだけでなく、どの開発プラットフォームにも当てはまります！）。貧弱なプログラミング慣行によって今節約された時間は、後であなたを悩ませるために戻ってきます。以下にコメントを残して、過去に犯したいくつかの間違い、そしてさらに重要なことに、学んだ教訓を私たちと自由に共有してください。

関連：私の5つの最悪のWordPress開発の間違い