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

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

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

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

Javaで不和ボットを書く方法

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

// 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テーマに基づいて子テーマを作成します。 二十六 。このコードの最も重要な行は、「テンプレート」という単語を含む行です。これは、子のクローンを作成する親テーマのディレクトリ名と一致する必要があります。

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

androidは開発者にクラッシュレポートを送信します

よくある間違いその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を編集しますファイルを作成し、次の行を挿入します。

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

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

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

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に次のコードを追加できますファイル：

nodejsリアルタイムの例

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を使用してボタンのラベルを変更できますが、何が問題になっていますか？ええ、はい、できます。ただし、WordPressで最も便利なフィルターの1つであるgettextを代わりに使用できる場合は、余分なコードとボタンをレンダリングするための余分な時間が追加されます。プラグインの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 );

このフィルターフックは、国際化関数__()によって翻訳されたテキストに適用されます。および_e()、textdomainである限り上記の機能で設定します。

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

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

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

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

結論

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

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