高度なWordPress開発者が犯す12の最悪の間違い

公開: 2022-03-11

WordPressは、サイトをすばやく立ち上げて実行するための非常に人気のある方法です。 しかし、急いで、多くの開発者が恐ろしい決定を下すことになります。 WP_DEBUGをtrueに設定したままにするなど、いくつかの間違いは簡単に発生する可能性があります。 すべてのJavaScriptを1つのファイルにまとめるなど、怠惰なエンジニアと同じくらい一般的なものもあります。 どちらの間違いを犯しても、初心者や熟練した開発者が犯す最も一般的な12のWordPressの間違いを見つけるために読んでください。 これらの間違いの1つを犯していることに気付いたとしても、絶望しないでください。 それぞれの間違いは学ぶ機会です。

WordPress開発者が犯す主な間違い

1.WordPressテーマのJavaScriptコードを1つのメインファイルに配置する

かつて、クライアントのWebサイトのページ速度の最適化を行っているときに、 main.js 、 theme.js 、またはcustom.jsという1つのファイルに、カスタムコードを含む、使用しているすべてのライブラリを含むプレミアムテーマを使用していることに気付きました。 。 この方法は、次の理由で不適切です。

  1. やがて、ファイルは非常に大きくなる可能性があります。テーマは積極的に開発されており、機能が大きくなり、場合によっては1MBものサイズのファイルが表示されることもあります。 一部のページでファイルのコードの10％しか必要ない場合でも、ファイルはサイト全体に読み込まれます。 これにより、特にページのヘッドセクション内のレンダリングブロックコードの場合、ページのダウンロードに時間がかかり、レンダリングに時間がかかります。
  2. wp_dequeue_script()などの関数を使用して一部のページのコードの一部をアンロードしてページ速度を向上させたり、他のJavaScriptコードとの競合を防止したりできないため、ファイル内のコードの管理がより困難になります。アクティブなプラグインの1つによってロードされます。 もちろん、ファイルを複数のファイルに分割してWordPressにエンキューすることはできますが、後でWebサイト管理者がテーマのmain.jsファイルの更新を実行した場合は、プロセス全体を最初からやり直す必要があります。

2.変数、関数、定数、またはクラスにあまりにも一般的な名前を使用する

プラグインを開発するときは、同じ名前を使用する他のプラグインがある場合にコードの競合を防ぐ命名規則を使用することをお勧めします。 そのため、多くの開発者は、変数と関数名の前に、プラグイン自体に関連する一意の何かを付けています。 コードの競合を排除するだけでなく、多くのプラグインを有効にしている場合に、物事を見つけやすくなります。

一方、PHP名前空間を使用してアイテムをカプセル化し、クラスや関数などの再利用可能なコード要素を作成するときにライブラリとアプリケーションの作成者が遭遇する2つの問題を解決することを好む開発者がいます。

  1. それらが作成するコードと、内部PHP、またはサードパーティ、クラス、関数、または定数との間の名前の衝突
  2. 最初の問題を修正したり、ソースコードの読みやすさを向上させたりするために設計されたExtra_Long_Namesをエイリアス（または短縮）する機能。 多くのコードを含むテーマやプラグインを開発することが多いので、これは私のお気に入りです。 これにより、長い一意の名前を気にすることなく、コードを簡単に読み取って管理できます。

名前空間は間違った方法で使用されることが多いため、使用する前に名前空間をよく理解することをお勧めします。

参加するプロジェクトによっては、作業が既存のコーディングスタイルとほとんど別のものでない限り、既存のコーディングスタイルに固執する必要がある可能性があります。 WordPressのPHPコーディング標準にすでに準拠している既存のプラグインまたはテーマを拡張する必要がある場合は、コードがクリーンで読みやすくなるように一貫したスタイルにするために、それらに固執するのが最善です。 コーディングスタイルを無視して、パフォーマンスを向上させるために、いくつかのルールが普遍的に適用されることに注意してください。 たとえば、文字列内で何も評価しない場合は、（二重引用符ではなく）一重引用符を使用するのが常に最善です。 また、コードを読み取るには、特にネストされたコード（たとえば、 IF内のIF 、ネストされたFOREACHおよびFOR ）がある場合は、コードをインデントする必要があります。

3.既存のWordPressコア機能を真の可能性に活用しない

WordPressには、プラグインやテーマで呼び出すことができる定期的に更新されるライブラリのスイートが付属しているため、既存のコア機能を可能な限り活用することをお勧めします。 すでにWordPressコアファイルにあるファイル（jQueryやColor Pickerなど）がアセットディレクトリにあるWordPressテーマとプラグインを見てきました。 パッケージが大きくなり、ネットワーク経由での読み込みに時間がかかるという事実に加えて、すべてのサードパーティライブラリが定期的に更新されていることを確認する必要があります。これはもう1つの注意事項です。

ライブラリはWordPress開発コアチームによってすでに更新されており、プロジェクトを軽量で保守しやすいものにすることができるため、WordPressがすでに提供しているものを活用してください。 WordPressの更新を定期的に行うことで、より多くの機能（プラグイン、テーマ、またはダッシュボードが一貫して改善されているWordPressコア自体）にアクセスし、古いコードリリースで脆弱性が見つかった場合にWebサイトをより安全にします。

4.アクションとフィルターを使用してプラグインまたはテーマを簡単に変更できないようにする

もちろん、WordPressプラグインまたはテーマを直接編集することは、そのパッケージの開発に直接関与し、そのコードに貢献している場合を除いて、悪い考えです。 プラグインまたはテーマの自動更新が実行されると、パッケージへの直接の変更はすべて失われ、ファイルをもう一度編集する必要があります。

そのため、アクションとフィルターの使用、および子テーマ（親テーマを拡張する）の作成は、親テーマまたはプラグイン自体を編集せずに既存の機能を変更できるため、テーマを変更するための最も効果的なアプローチです。 さらに、WordPress.orgで無料でダウンロードできるプラグインを提供していて、後で親プラグインに依存するプレミアム拡張機能を作成したい場合は、無料のプラグインを開発する必要があります。簡単に拡張してプレミアム拡張機能を追加できます。

WP_DEBUGをfalseに設定して開発する

デフォルトでは、PHPエラー、警告、および通知の出力を回避するために、 WP_DEBUG定数は「false」に設定されています。 ライブ環境では、これはプライベートサーバーパスとスクリプトをパブリックビューから隠しておくため、推奨される選択です。これは、セキュリティ上の理由から優れています。 ただし、開発段階では、コードのエラーが通知されるため、「true」に設定することをお勧めします。 エラーが機能に直接影響を与えない場合でも、多くの場合、より優れたコードを記述し、より優れたコーディング習慣を身に付ける必要があります。 それは私に起こりました。 これにより、開発したプラグインまたはテーマがWordPressのインストールでPHPエラーを生成しないようにすることもできます。

これは最も経験豊富な開発者が行うことですが、特に急いで発生します。 どんなに緊急の仕事であっても、開発者は常にWordPressのコーディング標準を維持し、PHPのベストプラクティスに目を向ける必要があります。

6.ページがいつかキャッシュされる可能性があることを考慮せずにPHPコードを作成する

これは一般的なPHPの間違いであり、前の例と同様に、PHPのコーディング標準に固執すれば比較的簡単に回避できます。

一部の開発者は、PHPコードが常にトリガーされる場合にのみ有効なテーマとプラグインにPHPスニペットを実装する習慣があります。 たとえば、特定のアクションでHTTPユーザーエージェントに応答するPHP関数を実行するかどうかを指定する必要があります（たとえば、モバイルユーザー専用のスクリプトをキューに入れる）。

クライアントが、テーマまたはプラグインの条件をトリガーせずにページをキャッシュするプラグイン（W3 TotalCacheやWPRocketなど）をインストールすると、PHPコードは役に立たなくなります。 ページをレスポンシブにすることを目的としている場合は、メディアクエリとJavaScriptを使用してフロントエンド側でこれを行う必要があります。 後者は、本当に必要な場合に限ります。 理想的には、JavaScriptを使用してサイトをレスポンシブにすることは避けたいと思います。

7.Gitなどのバージョン管理システムを介して専門的な方法で行われた変更を追跡しない

子テーマやカスタムプラグインなど、カスタムコーディングされたファイルは、理想的にはバージョン管理下にある必要があります。 Gitは変更内容の記録を作成し、開発者が同じWordPressプロジェクトで共同作業したり、Webサイトに問題が発生したときに以前のバージョンに簡単に戻したりできるようにします。 さらに、クライアントはGitを使用して、その特定のプロジェクトに採用されたすべての開発者によって行われたすべての作業履歴を追跡できます。特に、それが大規模で長期的なWordPressカスタムWebサイトである場合はそうです。

最初は特にジュニア開発者にとっては恐ろしいことかもしれませんが、Gitを理解することは時間の価値があり、SourceTree（私のお気に入りの1つ）などのGit GUIソフトウェアは、Gitリポジトリと対話する方法にすぎません。学習曲線がより楽しくなります。 それがどのように機能するかを理解したら、Gitのいくつかの使用方法をより詳細に説明しているToptalDevelopersによるGitのベストプラクティスとヒントを確認することを検討してください。

8.CSSおよびJavaScriptファイルが不要なときにエンキューする

HTTPリクエストが多いと、ウェブサイトの読み込みが遅くなり、Google PageSpeedのスコアが低くなり、検索ランキングに影響を与える可能性があります。 また、プラグイン間の競合が原因でJavaScriptエラーが発生する可能性もあります。 たとえば、共通のjQueryライブラリを使用する2つのプラグインが存在する可能性があります。これは、2回ロードされ、問題を引き起こす可能性があります。 そして実際、これは最良の例です。jQueryはライブWebサイトに複数回ロードされるのが非常に一般的だからです。 これは、プラグインまたはテーマの記述が不十分なために発生する可能性があります。

9.静的な.cssおよび.jsファイルの代わりに.phpファイルを使用してCSSまたはJavaScriptコードを出力する

カスタムCSSコードを生成して印刷するためだけに使用されるstyle.phpなどのファイルを含むテーマやWordPressプラグインを見てきました。 色、フォントサイズ、要素の周囲の間隔などは、テーマの設定で設定され、データベースに保存されました。 次に、style.phpが読み取られ（たとえば、 <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ）、カスタム設定に基づいてCSSコードが生成されます。ダッシュボードで更新されました。

これは、WordPressのパフォーマンスの観点からは本当に悪い習慣です。 これに伴う主な欠点は次のとおりです。

  1. CSSファイルはheadタグ内にロードされているため（これは正常であり、ほとんどがこのようにロードされます）、ブラウザーはページをレンダリングする前にファイルを完全にダウンロードする必要があるため、これに伴うパフォーマンスの問題があります。 一部のプラグインが原因でWordPress環境が遅い場合、ロード時間が大幅に遅れます。 キャッシュ技術が使用されている場合、またはデータベースから値を取得するためにWordPress環境の一部のみがロードされている場合でも。 代わりに、静的な.cssファイルを使用することをお勧めします。
  2. PHPファイルでは、コード（PHP変数と条件節が混在するCSSルール）は、開発者が何かをチェックアウトする必要があるときに読みにくくなります。 もちろん、ファイルはブラウザで実行できます（ただし、印刷時にインデントされたり見栄えが良くなったりすることはありません）が、プロジェクトのローカルコピーがあり、テーマのコードを参照している場合は、 CSSまたはJavaScript構文を見つけるために（script.phpが使用される場合）、それは読みやすさを難しくします。

解決策：プラグインディレクトリの外にカスタムCSSを保存します。 例： /wp-content/uploads/theme-name-custom-css/style-5.css 。 このようにして、テーマまたはプラグインが更新された場合でも、カスタムファイルが失われることはありません。

10. WordPressプラグインとテーマに適切なアーキテクチャ（コード編成）を使用していない

プラグインのサイズと性質（たとえば、スタンドアロンプ​​ラグイン、またはWooCommerceなどのメインプラグインがアクティブ化されている場合にのみ機能するプラグイン拡張機能）に応じて、適切なアーキテクチャとコード編成を設定する必要があります。

クライアント用の単一目的のWordPressプラグインを構築する必要があり、WordPressコア、テーマ、およびその他のプラグインとの相互作用が制限されている場合、プラグインがかなり後で拡張されることを確信していない限り、複雑なクラスを設計することは効果的ではありませんオン。

プラグインが多くのコードで豊富に機能する場合は、オブジェクト指向プログラミング（OOP）コーディングアプローチ（多くのクラスを持つ）を使用するのが理にかなっています。 たとえば、ショートコードがたくさんある場合は、それらをすべてclass.shortcodes.phpなどの個別のクラスファイルに保存するか、ダッシュボードとフロントエンドビュー内にロードすることを目的としたCSSファイルとJavaScriptファイルがある場合です。次に、 class.scripts.phpなどの1つのクラスを使用して、 enqueue_admin_scripts()メソッド内の管理領域にロードするファイルをキューに入れながら、 enqueue_public_scripts()などのメソッド内でフロントエンドファイルをエンキューできます。

HTMLとPHPコードを混在させるのではなく、プラグインとテーマにMVCパターンを実装して、HTMLを分離しておくことをお勧めします。 良い例はWooCommerceプラグインです。 ロジックがデザインから分離されているという理由だけで、テーマやさまざまなフィルターを介して簡単に上書きできるさまざまなレイアウトのテンプレートがあります。 HTMLレイアウトを含むテンプレートは、主に、すでに処理された情報を印刷するために使用されます。 PHPメソッド内にHTMLコードを含めることは、通常は悪い習慣です（もちろん、HTMLコードの小さなビットには例外があります）。特に、サイズが大きくなるにつれて複数の開発者によって維持されるプラグインの場合はそうです。

WordPressプラグインハンドブックによると、考えられるアーキテクチャパターンは多数ありますが、大きく3つのバリエーションに分類できます。

  • 関数を含む単一のプラグインファイル
  • クラス、インスタンス化されたオブジェクト、およびオプションで関数を含む単一のプラグインファイル
  • メインプラグインファイル、次に1つ以上のクラスファイル

11.コードを書くときにWordPressのセキュリティを真剣に受け止めていない

多くの初心者開発者はクライアントが望む結果にもっと焦点を合わせているため、WordPress開発ではセキュリティが真剣に受け止められていないことがよくあります。 クライアントのWebサイトがハッキングされるか、WordPress.orgで公開されているプラ​​グインに脆弱性があり、何千ものWebサイトが影響を受けるまでは、すべて問題ありません。 これらのことは時々起こり、WordPressコアでさえCMSの初期からかなりの数のセキュリティの脆弱性に対処してきました。 それを可能な限り安全にし、何かが起こった場合には、迅速に行動し、しっかりした、十分にテストされたパッチをリリースすることを確認するのは私たちの責任です。

最も重要なセキュリティのヒントのいくつかは次のとおりです。

XSSの脆弱性：これを回避するには、データ入力のサニタイズと出力データのサニタイズの2つのことを行う必要があります。 データとそれが使用されるコンテキストに応じて、WordPressにはコードをサニタイズするためのいくつかの方法があります。 入力データや、印刷されるデータを信頼してはなりません。 データ入力をサニタイズするための一般的な関数の1つは、 sanitize_text_field()です。 無効なUTF-8文字をチェックし、単一の<文字をHTMLエンティティに変換し、すべてのタグを削除し、改行、タブ、余分な空白を削除し、オクテットを削除します。 データの印刷に関しては、リンクを出力するための良い例は、無効なURLを拒否し、無効な文字を削除し、危険な文字を削除するesc_url()関数です。

ファイルへの直接アクセスを防止する：ほとんどのホストで許可されているため、ファイルに直接アクセスできます。 ただし、これが発生し、コードが適切に記述されていない場合は、潜在的な攻撃者にとって価値のある情報を含むエラーが出力される可能性があります（たとえば、関数の欠落や宣言されていない変数）。 プラグインやテーマでよく見られる一般的なコードスニペットの1つは、次のとおりです。

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

定数ABSPATHが定義されていない場合（WordPressのインストール用である必要があります）、スクリプトは終了し、何も出力しません。

ノンスの使用：WordPressのドキュメントに記載されているように、ノンスは、悪意のある、またはその他の特定の種類の誤用からURLとフォームを保護するのに役立つ「1回使用される番号」です。

たとえば、ダッシュボード内の次のURLは、投稿をゴミ箱に移動するために使用されますhttp://example.com/wp-admin/post.php?post=123&action=trash ?post=123&action=trash —このURLにアクセスすると、WordPressは認証Cookie情報を検証しますまた、適切な権限がある場合（たとえば、すべての権限を持つ管理者である場合）、その投稿は削除されます。

攻撃者が行う可能性があるのは、次の例のようにサードパーティのページにリンクを作成して、知らないうちにブラウザにそのURLにアクセスさせることです。 <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> WordPressにこのリクエストを送信すると、ブラウザは自動的に認証Cookieを添付し、WordPressはリクエストを有効と見なします。

攻撃者はnonce値（実際にWordPressにログインしている管理者用に生成されたもの）を簡単に取得できないため、nonceが発生します。 新しいリクエストURLは次のようになります： http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204 ：//example.com/wp-admin/post.php？post = 123＆action = trash＆_wpnonce = b192fc4204

有効なナンスがないと、WordPressによって403 Forbidden応答がブラウザに送信され、よく知られているエラーメッセージが表示されます。「これを実行してもよろしいですか？」

ほとんどの人はWordPressのセキュリティを真剣に受け止めていませんが、自分のWebサイトがハッキングされることは決してないと考え、ホスティングを信頼し（これは役立つ可能性がありますが、特定のポイントに限られます）、商用のプラグイン/テーマを購入したという事実（多くの場合、それらが非常に安全であるという前提で）、ハッカーがそれらを識別して悪用する前に、悪用可能な脆弱性を特定するために、常にWebサイトの侵入テストを行う必要があります。

そこにある多数のハッキングは、あなたのWebサイトを具体的にハッキングすることを意図して1人の人間によってさえ行われていないことに注意してください。 多くの場合、WordPress Webサイトを一貫して自動的にスキャンするボットがあり、既知の脆弱性が見つかるとすぐに悪用され、サーバーがスパムに使用され、データベースから個人情報を取得し、Webサイトの特定のページ内に隠しリンクを配置します。あらゆる種類の危険なウェブサイト（ポルノ、違法薬物など）につながる可能性があります。 場合によっては、ハッキングがうまく隠されているため、Webサイトを適切にスキャンし、ハッキングされたコードを検出するために特定のファイルが更新された日付を確認する必要があります。 そのため、WordPressを再インストールして（最後のバージョンがある場合は同じバージョン）、ハッキングされたファイルが本物のWordPressコアファイルで上書きされるようにすることもできます。

12.WordPress関数とコードスニペットを理解せずに使用する

多くの場合、開発者が行き詰まり、StackOverflowのような場所で解決策を見つけたとき、そのコードの背後にあるロジックをわざわざ理解することなく、またはそのコードを変更して読み込みを高速化または削減できるかどうかを気にせずに何かを機能させることができたという事実に満足しています。コードの行。

コードのスニペットがPHPスクリプト内でコピーされ、そのコードの3分の1しか実際に使用されていない場合、この慣習を何度も目にしました。

これには、次のようないくつかの欠点があります。

  1. このコードは、既存のプロジェクトコードと同じスタイルを使用していません。 はい、箱から出してすぐに機能するスニペットをコピーして貼り付けるだけで快適です。小さな個人的なプロジェクトには問題ありませんが（いつか大きなプロジェクトになる可能性があります）、この方法はうまくいかないことがよくあります。スタイルの一貫性を維持しなければならない商業的な仕事に。
  2. コードはその役割を果たしますが、達成する必要のあるタスクには推奨されない効果のない関数が含まれている可能性があります。 コードが最適化されていない場合、特にプロジェクト内のさまざまな場所で複数のスニペットが使用されている場合、この「コピーアンドペースト」の方法により、Webサイトの保守が遅くなり、困難になる可能性があります。
  3. コードは再利用のライセンスが付与されていない可能性があり、クライアントのプロジェクトにコードを含めると、多くの法的な問題が発生する可能性があります。

絶え間ない改善

誰もが間違いを犯し、それぞれの間違いは自分自身を向上させる機会です。 WordPress開発者として、私たちの業界は非常に速いペースで動いており、物事を行うための「正しい方法」を設定することは決してありません。 しかし、練習して学ぶほど、上手になります。

私が指摘した間違いのいずれかに同意しませんか、それとも私が見逃したと思いますか？ コメントで教えてください。話し合います。

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