WordPressプラグインの10の最も一般的な間違い

公開: 2019-08-27

WordPressの最も成功した機能の1つは、プラグインの作成を通じてこのコンテンツ管理システムの基本機能を拡張する開発者のコ​​ミュニティを奨励することができたことです。 それと、WordPressの市場シェアが近年成長を止めていないという事実は、才能を引き付けるための鍵です。

WordPressプラグインは最高です。 あなたがあなたのウェブサイトをカスタマイズする必要があるならば、あなたがあなたがあなたに安心を与える必要なことをするプラグインを探すことによってあなたがそうすることができるということを知っています。 また、コストも大幅に削減されます。

(ほとんどの場合)カスタムソリューションを開発する必要がないのは安心です。 複雑なWebサイトへのアクセスを、数年前の数分の1の価格で民主化します。

雨が降っている間に彼の足を見ている悲しい男
私はあなたが信じられないものを見てきました。 エディター以外の書き込みプラグインを検出します。 WordPressデータベースの近くでバグが暗闇で光るのを見てきました。 それらのすべての瞬間は…時間内に…雨の中の涙のように失われます。 それらを書き留める時が来ました。

しかし、すべてがバラのベッドというわけではありません。 WordPressプラグインを選択するときは、非常に注意する必要があります。 WordPressの人気は才能を引き付けます。 しかし、それはまた、望ましい品質レベルを持たないプラグインを作成することがある経験の浅い開発者を引き付けます。 それらを検出することは、それらが持っている肯定的な評価の数またはそれらがインストールされているサイトの数を数えるほど簡単ではありません。 それははるかに複雑です。

顧客のWordPressインストールの分析を開始して以来、Nelioで苦しんでいるのは、そこにインストールされているゴミの量です。 信じられないようなことを見てきました…

そのため、本日は、WordPressプラグインでここ数年に遭遇した最も一般的で奇妙な問題のいくつかについて説明します。

WordPressプラグインの問題リスト

ここでは、WordPressプラグインで見つけることができる問題のリストを残します。 それらは一般的な問題であり、それらに苦しむプラグインの特定の名前は示しませんが、それらは存在するため、それらを回避するように注意する必要があります。

データベースに追加のテーブルを作成する

WordPressデータベースは戦争地帯です。 多くのプラグインは、独自のテーブルを追加するためにそれを拡張します。 これは間違っている必要はありませんが、ほとんどの場合、必要ありません。

WordPressデータベース
WordPressデータベースのメインテーブル。

WordPressデータベースは、プラグインが使用するために新しいテーブルを追加する必要がないほど汎用的です。 では、なぜ開発者はWordPressにテーブルを追加する必要があると考えているのでしょうか。 答えは非常に簡単です:快適さと無知。

多くの場合、WordPressの経験がほとんどない人にとっては、追加のテーブルを配置し、SQLで直接クエリを実行して、データを読み取ったり変更したりする方が簡単です。 これは、うまく行われなかった場合のセキュリティホールであることに加えて、メタテーブルの使用を回避します。

ユーザー情報を拡張する場合は、 wp_usermetaテーブルがあります。 同じことが、コンテンツ( wp_postmeta )、コメント( wp_commentmeta )、さらには分類用語(ラベルとカテゴリ、 wp_termmetaテーブル)にも当てはまります。

WordPressは、このメタ情報を標準的かつ安全な方法で読み取って変更するためのメソッドを提供します。 パフォーマンスの正当性がない限り、WordPress開発者の皆様、プラグインで追加のテーブルを使用しないでください。

悪いスクリプトとスタイルをロードする

ほとんどのWordPressプラグインは、遅かれ早かれ独自のJavaScriptファイルとCSSファイルをロードする必要があります。WordPressの管理パネルやWebの前面にある場合もあります。 そして悲しいことに、これはしばしば間違って行われることです。

安全から火へと男を運ぶスパイダーマン(つまり、間違ったことをしている)
WordPressにCSSスタイルとJavaScriptファイルをロードすることは、残念ながら、うまくいく開発者はほとんどいません。

WordPressにCSSスタイルまたはJavaScriptファイルを追加するには、標準のWordPressキューにエンキューする必要があります。 これを行うには、最初に関数wp_register_stylewp_register_scriptで登録し、次にそれぞれwp_enqueue_stylewp_enqueue_scriptでエンキューします。

これらの関数を使用すると、スタイルとスクリプトが持つ依存関係を定義できるため、WordPressは依存関係を正しく管理し、必要なものだけをエンキューすることに注意してください。

他の何かが間違っています。 そして、ここでは開発者のドキュメントでさえ責任があります。 WordPressCodexのwp_headフックに含まれている例を見てください。 開発者はこれを参照として受け取ります、そして次に何が起こるかは彼らが物事を壊すということですか?

wp_dequeue_scriptまたはwp_dequeue_styleを使用してWordPressからスクリプトまたはスタイルをデキューすることを考えないでください。 プラグインがWordPressに付属するバージョンのjQueryをデキューして、プラグインが独自のバージョン(通常は古くなっています)を追加し、そこからすべてが機能しなくなる様子を何度も見てきました…

WordPressのガイドラインに従ってスクリプトとスタイルを正しくロードしないプラグインを検出した場合、これは今すぐインストールからプラグインを無効にするのに十分な理由です。

プラグインを非アクティブ化するときにデータベースをクリーンアップしない

これはWordPressプラグインのもう一つの古典的な側面であり、おそらくあなたが見つける最も一般的なものです。 動作するために、WordPressプラグインはデータベースにレコードを追加する必要があります。 ここでの問題は、プラグインを非アクティブ化すると、それらのレコードがデータベーステーブルに永久に残るのが一般的であるということです。

WordPressプラグインは通常、非アクティブ化したときにデータベースに作成されたデータを消去しません。 いいえ、時々通り過ぎてこの役に立たないデータを持って行くごみ収集車はありません。

WordPressプラグインは、ユーザーが非アクティブ化したときに、作成した追加のテーブルと標準テーブルに追加したデータを削除する必要があります。 しかし、それはめったに起こりません。 データベースにアクセスして、監視することをお勧めします。 きっとあなたはそこに役に立たないゴミを見つけるでしょう。

NelioContentの非アクティブ化ダイアログのスクリーンショット
プラグインを非アクティブ化すると、このようなダイアログが表示され、一時的に非アクティブ化するか、すべてを削除できます。

開発者が注意している場合、WordPressでプラグインを非アクティブ化すると、プラグインを一時的または永続的に非アクティブ化するかどうかを尋ねられます。 後者のオプションは、操作中に追加したすべてのデータを消去するため、ゴミを取り除き、すべてをクリーンな状態に保ちます。

ユーザーガイダンスを提供しない

WordPressプラグインをインストールしてアクティブ化すると、通常、プラグインの機能を見つけることができる新しいメニューがWordPressダッシュボードに表示されることを期待します。 しかし、これは常に当てはまるわけではありません。

びっくりした男
WordPressプラグインをインストールしてアクティブ化した後、そのように感じた場合、開発者は何か間違ったことをしています。

新しいプラグインが既存のメニュー(通常はツールメニューまたは設定メニュー)内にメニューを追加する場合があります。 そのため、ユーザーは、インストールしてアクティブ化したばかりの新しいプラグインを含むメニューがどこにあるかを調査する必要があります。

通常、WordPressでプラグインをアクティブ化すると、プラグインのREADME.txtファイルに何が起こるかを説明することをお勧めします。 このようにして、ユーザーの不安を軽減し、生活を少し楽にします。 そうしないと、プラグインが追加する機能がどこにあるかをユーザーが見つけられない場合、ユーザーはプラグインを非アクティブ化することになり、開発者としては最後にやりたいことです。

これは初心者にしか起こらないことだと思うかもしれません。 しかし、そうではありません。 最近、特定のことを行うために特定のプラグインをインストールしました(名前を付けるのを避けるつもりだったことを思い出しますか?)、そして私はこれと同じ状況にいることに気づきました。 プラグインの設定がどこにあるかわかりませんでした。 そして、長い間WordPressを使っていたはずの私に起こったとしたら、これと同じ状況は経験の浅い人にとってはひどいものです。

WordPressユーザーインターフェースの変更

WordPressは使いやすい、またはそう彼らは言います。 そして、これの重要な部分は、WordPressがデフォルトで含むユーザーインターフェースのおかげです。 このインターフェースは、新しいWordPressのインストールでは単純ですが、プラグインを追加するにつれて、より複雑になります。

さらに、WordPressプラグインの一般的な問題は、WordPressダッシュボードでユーザーが期待するものとはまったく異なるユーザーインターフェイスを使用する場合があることです。

通りを歩いているホーマーシンプソン
WordPressを使用しているが、WordPressのように見えない場合は、ユーザーを不必要に混乱させています。

WordPressのユーザーインターフェイスはデザイナーの観点からはやや退屈ですが、まったく異なるソリューションを選択するよりも、ユーザーが慣れているのと同じスタイルと同じユーザーエクスペリエンスに従う方がはるかに賢い場合があります。

私たちのプラグインでは、同じWordPressスタイルを維持し、ユーザーが表示されると思われる場所にユーザーインターフェイスのすべての要素を配置しようとしています。 しかし、WordPressにほとんどまたはまったく似ていないプラグインインターフェイスが多数あり、ユーザーを混乱させています。

WordPressプラグインの設計者は、WordPressスタイルガイドに従い、Gutenbergブロックエディターから直接エクスポートされたReactでインターフェイスを作成するために提供されているコンポーネントを再利用することをお勧めします。 Nelio A / B Testingの改修に使用しており、すばらしいものです。

あなたの財産の限界を突破する

WordPressダッシュボードには、開発者の観点から2つの異なるタイプのゾーンがあります。 一方では、特定のプラグインが追加するページであるプライベートエリアがあります。 これらのゾーン内では、それらのページが属するプラグインに含まれるCSSスタイルとスクリプトのみをキューに入れる必要があります。

一方、WordPressにデフォルトで付属しているすべての共通領域があります。 一般的な領域の例としては、コンテンツエディター、メニューまたはウィジェットエディター、設定などがあります。

クリームを注ぐ
プラグインが壊れている場合、原因はスタイルを破壊している、またはジャンクコードでスクリプトを壊している別のプラグインである可能性があります。

適切にプログラムされたプラグインは、WordPressガイドラインに準拠しており、プライベートゾーンにのみ影響するスクリプトとスタイルをキューに入れます。 これは、これらのリソースをキューに入れるときに、コード内に、自分のプロパティのプライベートページでそれを実行しようとしているかどうかを確認する条件があることを意味します。 それ以外の場合は、そのスコープ外のものをキューに入れません。

残念ながら、コードにこの条件を含めることを「忘れる」プラグインはたくさんあります。 これにより、JavaScriptコードとスタイルが常にすべてのページに読み込まれ、他の一般的なページや他のプラグインのプライベートページを壊す可能性があります。

見た目よりも簡単に検出できます。 プラグインを使用していて、そのユーザーインターフェイスが壊れているように見える場合は、別のプラグインがJavaScriptまたはCSSを配置してはいけない場所に配置し、最初のプラグインのスタイルと動作を壊している可能性があります。 私たちはそれを見てきました。 それは私たちに起こりました(彼らは私たちのインターフェースを壊します)、そして残念ながら、それは起こり続けるでしょう。

優れたプログラミング慣行に従わない

WordPressでプログラミングするのに世界最高のハッカーである必要はありませんが、プログラミングに関しては最低限の品質が期待されます。

WordPressの利点の1つ(最大ではないにしても)は、そのオープンソース哲学です。 プラグインのソースコードを調べることは、いつでもできることです(少なくとも公式リポジトリにあるプラグイン)。

足でコンピューターを操作している太った男
注意深いプログラミングは、生成したコードを見るだけでわかります。 ソースコードを探索するときに泣かせるプラグインはたくさんあります。

あなたはすべてを見つけるかもしれません:見やすいコードとあなたを泣かせるコード。 そして、それはパフォーマンスの観点から一方が他方より悪いという意味ではありません。 しかし、十分に文書化され、インデントされており、ファイルとフォルダーの論理的な分散に従って構造化されている場合は、聖杯が見つかります。

WordPressプラグインのコードが見やすい場合は、プログラマーが注意深く洗練されていることが原因である可能性があります。 それは品質の明らかな兆候です。

セキュリティホールを開く

WordPressプラグインは、一連のコード命令にすぎません。 通常、WordPressの機能を拡張するPHPとJavaScript。 このコードは、ユーザーから非常に安全にデータを取得し、画面に情報をレンダリングすることになります。

コンピューターで超高速でタイピングする猫
ほとんどの場合、それは意図的ではありませんが、データを検証してエスケープしないと、攻撃者の可能性があるよりも多くの扉を開くことになります。

データを取得して画面に印刷するときに、そのデータを正しく処理しないと、セキュリティホールが追加される可能性があります。 WordPressは、入力データの検証とサニタイズ、および出力でのデータのエスケープに重点を置いています。

データを検証し、ユーザーがプラグインに入力したものが本当に必要なものであることを確認して、コードインジェクションを回避するための関数はたくさんあります。 プラグイン開発者がそれらを使用しない場合、それは怠惰または無知が原因です。 WordPressに何をインストールするか注意してください。そうしないと、後悔することになります。

不適切な活動の実行

前のセクションを続けると、疑わしい起源のソースから来たプラグインがあります。 時々、あなたはあなたが欲しいプラグインを含んでいるがあなたが支払いたくない.zipファイルを探してインターネット上の暗い場所を飛び回るいくつかのお金を節約するために。

深層ウェブがどのように機能するかを理解していると主張する男性
私たちは皆それを知っており、時にはそれをやったことさえあります。 いくつかのお金を節約するために、私たちは何か無料のものを探してインターネットの暗い領域に行きました。

あなたがそれを見つけたとき、そのプラグインが贈り物に付属していることに気付くまで、すべてが幸せです。 クローラー、暗号通貨マイナー、スパムから、Webサイトを制御する可能性のある悪意のあるコードまで。 あなたはすべてを見つけることができます。

そこにあるプラグインの起源に注意してください。 公式のWordPressリポジトリと最も有名なマーケットプレイスは、WordPressプラグインの唯一の信頼できるソースです。 これらのリポジトリ内に入るには、プラグイン開発者はいくつかの品質テストに合格する必要があります。 既知の場所のみを信頼し、信頼できないソースから取得したプラグインは避けてください。

付加価値がない

WordPressプラグインが犯す可能性のある最悪の間違いは、ユーザーに付加価値を与えないことです。 開発者として、他の人にとって非常に役立つと思うクレイジーなアイデアを持っていることがあります。 真実は、プラグインがもたらすものが非常に少ない場合、プラグインがもたらすユーザーの数は同じになるということです。

公式のWordPressリポジトリには、価値の低いプラグインがたくさんあります。 しかし、これはどのマーケットプレイスやアプリケーションリポジトリでも発生することです。

開発者として他の競合他社との差別化を図りたい場合は、潜在的なユーザーに価値を提供することに重点を置いてください。 そうすれば、プラグインはWordPress内で成功するために必要な人気を得ることになります。

WordPressプラグインの選択は複雑です

すべてがユーザーレビューの数と星の数に基づいているわけではありません。 良いWordPressプラグインの選択は複雑です。 プラグイン自体のソースコードを分析することによってのみ発見される多くの隠れた驚きがあります。 そして、それを理解するための知識がない場合は、注意してください。

リポジトリ内のプラグインサポートフォーラムにあるコメントを見て、人々がどのような問題を抱えているかを確認してください。 制御された環境でプラグインを試してみてください。何か奇妙なことがある場合は、開発者に連絡してください。

この後、表示内容に満足できない場合は、別の方法を探してください。 何千ものプラグインがあなたを待っています。 または、以下にコメントを残してください。 私たちは常に、コレクションに追加する新しい興味深いプラグインのアイデアを探しています。

UnsplashのGohRhyYanによる注目の画像