WordPressプラグインの開発中に学んだ教訓

すべてのWordPressプラグイン開発者は、保守が難しい難しい問題やコードに苦労しています。 私たちは深夜にユーザーをサポートし、アップグレードによってプラグインが壊れたときに髪を引き裂きます。 それを簡単にする方法をお見せしましょう。

この記事では、WordPressプラグインの開発における5年間の経験を共有します。 私が最初に書いたプラグインは、単純なマーケティングプラグインでした。 Googleの検索フレーズを含む召喚状（CTA）ボタンが表示されました。 それ以来、私はさらに11個の無料プラグインを作成し、それらのほとんどすべてを維持しています。 私はクライアントのために約40のプラグインを作成しました。非常に小さなプラグインから、1年以上維持されているプラ​​グインまでです。

優れた開発とサポートにより、ダウンロード数が増加します。 より多くのダウンロードはより多くのお金とより良い評判を意味します。 この記事では、プラグインの開発を改善できるように、私が学んだ教訓と私が犯した間違いを紹介します。

1.問題を解決する

プラグインで問題が解決しない場合、プラグインはダウンロードされません。 それはそれと同じくらい簡単です。

Advanced Cron Managerプラグインを使用します（8,000以上のアクティブなインストール）。 これは、cronのデバッグに苦労しているWordPressユーザーに役立ちます。 プラグインは必要に応じて作成されました—私は自分自身を助けるために何かが必要でした。 人々がすでにそれを必要としていたので、私はこれを売り込む必要はありませんでした。 それは彼らのかゆみを掻きました。

一方、バグがあります—画面上を飛ぶプラグイン（70以上のアクティブなインストール）。 画面上のハエをランダムにシミュレートします。 それは実際には問題を解決しないので、大勢の聴衆がいることはないでしょう。 ただし、開発するのは楽しいプラグインでした。

問題に焦点を合わせます。 SEOのパフォーマンスが良くない場合は、SEOプラグインをインストールします。 人々が彼らのウェブサイトをスピードアップしたいとき、彼らはキャッシングプラグインをインストールします。 人々が自分の問題の解決策を見つけることができないとき、彼らは彼らのために解決策を書く開発者を見つけます。

David Hehenbergerが成功したプラグインの作成に関する記事で証明しているように、特定のプラグインをインストールするかどうかをWordPressユーザーが決定する際の重要な要素は必要です。

誰かの問題を解決する機会があれば、チャンスをつかんでください。

2.製品をサポートする

「アメリカ人の5人に3人は、より良いサービス体験のために新しいブランドや会社を試すでしょう。 10人中7人が、優れたサービスを提供していると信じている企業にもっとお金をかけたいと言っています。」

— Nykki Yeager

あなたのサポートをおろそかにしないでください。 それを必需品のように扱うのではなく、もっとチャンスのように扱ってください。

プラグインを拡張するには、高品質のサポートが不可欠です。 最高のコードを備えたプラグインでさえ、いくつかのサポートチケットを取得します。 プラグインを使用する人が増えるほど、より多くのチケットを取得できます。 ユーザーエクスペリエンスが向上すると、チケットは少なくなりますが、受信トレイ0に到達することはありません。

誰かがサポートフォーラムにメッセージを投稿するたびに、私はすぐに電子メール通知を受け取り、できるだけ早く応答します。 それは報われる。 私の良いレビューの大部分は、サポートのおかげで獲得されました。 これは副作用です。優れたサポートは、多くの場合、5つ星のレビューに変換されます。

あなたが優れたサポートを提供すると、人々はあなたとあなたの製品を信頼し始めます。 また、プラグインは、完全に無料でオープンソースであっても、製品です。

良いサポートは、1日に1回短い答えを書くよりも複雑です。 プラグインが勢いを増すと、1日に数枚のチケットを獲得できます。 顧客が質問する前に積極的に質問に答えれば、管理がはるかに簡単になります。

実行できるアクションのリストは次のとおりです。

• リポジトリにFAQセクションを作成します。
• サポートフォーラムの上部にある「質問する前に」スレッドを固定し、トラブルシューティングのヒントとFAQを強調します。
• プラグインが使いやすく、ユーザーがプラグインをインストールした後に何をすべきかを知っていることを確認してください。 UXは重要です。
• サポートの質問を分析し、問題点を修正します。 人々が必要な機能に投票できるボードを設定します。
• プラグインがどのように機能するかを示すビデオを作成し、WordPress.orgリポジトリのプラグインのメインページに追加します。

製品をサポートするためにどのソフトウェアを使用するかは実際には重要ではありません。 WordPress.orgの公式サ​​ポートフォーラムは、電子メールや独自のサポートシステムと同様に機能します。 無料のプラグインにはWordPress.orgのフォーラムを使用し、プレミアムプラグインには独自のシステムを使用しています。

3.Composerを使用しないでください

Composerはパッケージマネージャーソフトウェアです。 パッケージのリポジトリはpackagist.orgでホストされており、プロジェクトに簡単にダウンロードできます。 これは、PHP用のNPMまたはBowerのようなものです。 Composerと同じようにサードパーティのパッケージを管理することは良い習慣ですが、WordPressプロジェクトでは使用しないでください。

私は爆弾を落としました。 説明させてください。

Composerは素晴らしいソフトウェアです。 私はそれを自分で使用していますが、公開されているWordPressプロジェクトでは使用していません。 問題は対立にあります。 WordPressにはグローバルパッケージマネージャーがないため、すべてのプラグインが独自の依存関係をロードする必要があります。 2つのプラグインが同じ依存関係をロードすると、致命的なエラーが発生します。

この問題に対する理想的な解決策は実際にはありませんが、Composerはそれをさらに悪化させます。 ソースに依存関係を手動でバンドルして、安全にロードできるかどうかを常に確認できます。

WordPressプラグインに関するComposerの問題はまだ解決されておらず、近い将来、この問題に対する実行可能な解決策はありません。 この問題は何年も前に提起されたものであり、WP Tavernの記事で読むことができるように、多くの開発者が運がなくても問題を解決しようとしています。

できる最善のことは、コードを実行するための条件と環境が適切であることを確認することです。

4.古いPHPバージョンを合理的にサポートする

5.2のような非常に古いバージョンのPHPはサポートしないでください。 セキュリティの問題とメンテナンスはそれだけの価値はなく、それらの古いバージョンからより多くのインストールを獲得することはありません。

公式サポートは2018年末までに廃止されますが、最小要件としてPHP5.6を使用してください。WordPress自体にはPHP7.2が必要です。

従来のPHPバージョンのサポートを思いとどまらせる動きがあります。 YoastチームはWhipライブラリをリリースしました。これはプラグインに含めることができ、PHPバージョンとアップグレードが必要な理由に関する重要な情報をユーザーに表示します。

サポートしているバージョンをユーザーに伝え、プラグインが低すぎるバージョンにインストールされた後にWebサイトが壊れないようにします。

5.品質コードに焦点を当てる

良いコードを書くことは最初は難しいです。 「SOLID」の原則とデザインパターンを学び、古いコーディングの習慣を変えるには時間がかかります。

かつて、WordPressで単純な文字列を表示するのに3日かかりました。そのとき、より良いコーディング手法を使用してプラグインの1つを書き直すことにしました。 30分かかるはずだったのでイライラしました。 私の考え方を変えるのは苦痛でしたが、それだけの価値がありました。

なんでそんなに大変だったの？ 最初はやり過ぎで直感的ではないように見えるコードを書き始めるからです。 「これは本当に必要なのか」と自問し続けました。 たとえば、ロジックを異なるクラスに分割し、それぞれが1つのことを担当していることを確認する必要があります。 また、翻訳、カスタム投稿タイプ登録、アセット管理、フォームハンドラーなどのクラスを分離する必要があります。次に、単純な小さなオブジェクトからより大きな構造を構成します。 これは依存性注入と呼ばれます。 これは、すべてのコードを詰め込む「フロントエンド」クラスや「管理者」クラスとは大きく異なります。

もう1つの直感に反する方法は、すべてのアクションとフィルターをコンストラクターメソッドの外部に保持することでした。 このように、オブジェクトの作成中にアクションを呼び出す必要はありません。これは、単体テストに非常に役立ちます。 また、どのメソッドをいつ実行するかをより適切に制御できます。 コンストラクターメソッドのアクションによって引き起こされる無限ループのプロジェクトを作成する前に、これを知っていればよかったのですが。 これらの種類のバグは、追跡や修正が困難です。 プロジェクトはリファクタリングする必要がありました。

上記はほんの一例ですが、SOLIDの原則を理解する必要があります。 これらは、すべてのシステムおよびすべてのコーディング言語に有効です。

すべてのベストプラクティスに従うと、すべての新機能がぴったり合うようになります。既存のコードに何かを微調整したり、例外を設けたりする必要はありません。 すごい。 複雑になる代わりに、柔軟性を失うことなく、コードがさらに高度になります。

また、コードを適切にフォーマットし、チームのすべてのメンバーが標準に準拠していることを確認してください。 標準により、コードが予測可能になり、読みやすく、テストしやすくなります。 WordPressには独自の標準があり、プロジェクトに実装できます。

6.プラグインを事前にテストします

私はこのレッスンを難しい方法で学びました。 テストが不足しているため、致命的なエラーのあるプラグインの新しいバージョンをリリースしました。 2回。 どちらの場合も、私は1つ星の評価を得ましたが、これは肯定的なレビューにはなりませんでした。

手動または自動でテストできます。 Travis CIは、GitHubと統合する継続的テスト製品です。 私は、通知プラグイン用の非常に単純なテストスイートを構築しました。このテストスイートは、プラグインがすべてのPHPバージョンで正しく起動できるかどうかをチェックするだけです。 このようにして、プラグインにエラーがないことを確認でき、すべての環境でプラグインをテストすることにあまり注意を払う必要はありません。

自動化された各テストには、ほんの一瞬かかります。 100の自動テストは完了するのに約10分かかりますが、手動テストは各ケースで約2分かかります。

プラグインのテストに前もって投資すればするほど、長期的には節約できます。

自動テストを開始するには、WP-CLI \\ `wpscaffoldプラグイン-test \\`コマンドを使用できます。これにより、必要なすべての構成がインストールされます。

7.あなたの仕事を文書化する

開発者がドキュメントを書くのを好まないのは決まり文句です。 これは開発プロセスの中で最も退屈な部分ですが、少しは大いに役立ちます。

自己文書化コードを記述します。 変数、関数、クラスの名前に注意してください。 簡単に読み取れないカスケードのような複雑な構造を作成しないでください。

コードを文書化する別の方法は、すべてのファイル、関数、およびクラスのコメントである「docブロック」を使用することです。 関数がどのように機能し、何をするのかを書くと、6か月後にデバッグする必要があるときに非常に理解しやすくなります。 WordPressコーディング標準は、ドキュメントブロックの記述を強制することで、この部分をカバーしています。

両方の手法を使用すると、ドキュメントを作成する時間を節約できますが、コードド​​キュメントがすべての人に読まれることはありません。

エンドユーザーのために、システムがどのように機能し、どのように使用するかを説明する、高品質で短くて読みやすい記事を書く必要があります。 ビデオはさらに優れています。 多くの人は、記事を読むよりも短いチュートリアルを見ることを好みます。 彼らはコードを見るつもりはないので、彼らの生活を楽にしてください。 優れたドキュメントは、サポートチケットも削減します。

結論

これらの7つのルールは、BracketSpaceのコアビジネスになり始めている高品質の製品を開発するのに役立ちました。 WordPressプラグインの旅にも役立つことを願っています。

コメントで、あなたの黄金の開発ルールが何であるか、または上記のいずれかが特に役立つと感じたかどうかを教えてください。