WordPressプラグインでComposerを使用する方法の説明

この作品は、ゲスト作家のピーター・スームによって寄稿されました。 Peterは、Land of theDanesのWeb開発者です。 彼はWPプッシャーの作成者であり、旅行中毒者であり、彼の作品を彼と一緒に持っていきます。

先日、WPPusherブログにWordPressプラグインでのComposerの使用に関する警告を投稿しました。 この投稿は大きな注目を集めており、すべての人に明確ではなかったいくつかの点を明確にする必要があると感じています。 この記事は技術的なことにも少し重かったので、この投稿では、簡単な説明を使って説明することで、私の要点をより明確にしようと思います。

物語

しばらくの間、あなたと私が両方ともプラグインの作者であると想像してみましょう。 私たち二人は、WordPress.orgを介して配布したいプラグインについて素晴らしいアイデアを持っています。 無料版のユーザーがライセンスキーを入力することでロックを解除できるプラグインにいくつかのプレミアム機能を含めたいと思います。

このプロセスを処理できるコードが必要です。 私たち二人は、この問題はおそらく他の誰かによってすでに解決されていることを認識しています。 私たちの誰もが車輪の再発明のファンではないので、Packagistに向かい、「ライセンスマネージャー」と入力します。 私たちの仮定は正当化されたようです。 Yoastには、これを処理できるパッケージがすでにあります。 私たちは両方ともcomposer require yoast/license-managerを実行することにしました。 簡単に簡単。 これで、本当に重要なこと、つまりそれぞれのプラグインのコア機能に取り掛かることができます。

早送りして、プラグインをリリースする準備ができたら、何かに気づきます。WordPress.orgからプラグインをインストールするときにユーザーがComposerを持っているとは限らないので、ライセンスマネージャーのコードをどのように取得するのでしょうか。 この状況は少し厄介です。実際に目にする唯一の解決策は、Composerで生成されたvendorディレクトリ全体をプラグインにコミットし、それをWordPress.orgにプッシュすることです。 これがComposerの動作方法ではなく、何でもかまいません。 他に選択肢はありません。

その間、私は私のプラグインで同じ結論に達しました。 ライセンスマネージャーコードを含めるだけで、それで完了します。

もう一度早送りすると、両方のプラグインがWordPress.orgリポジトリに存在し、たまに誰かがプレミアムバージョンにアップグレードすることを決定します。 すべてが順調に進んでいるようで、Yoastが寛大にオープンソース化したコードを使用でき、車輪の再発明をする必要がなかったことに、私たちは両方とも感謝しています。

ある日、あなたは奇妙な電子メールを受け取ります。 プレミアム機能のロックを解除しようとすると、顧客は非常に奇妙な動作を経験しています。 他の誰もこれを報告したことがないので、それはあなたには意味がありません。 何時間もデバッグした後、最後に、プラグインを除く他のすべてを非アクティブ化するように顧客に依頼します。その後、次のようになります。 うーん。 あなたのプラグインはどういうわけか別のプラグインと互換性がないようです。 私のプラグイン。

これは、顧客がインストールした他のすべてのプラグインのソースコードを何時間も調べた後でわかります。 両方がライセンスマネージャーを使用していることに気付くと、ベルが鳴ります。 これは本当にそれでしょうか？ もしそうなら、どうしてfatal errors: cannot redeclare classのでしょうか。

1週間前に、プラグインのライセンスマネージャーの必要なバージョンを、いくつかの（架空の）重大な変更を含む最新バージョンにバンプしました。 さらにデバッグとvar_dump()を実行すると、私のバージョンのライセンスマネージャーがPHPによってプラグインにロードされたバージョンでもあることがわかります。 Composerで別のバージョンのライセンスマネージャーが特に必要だったので、これは本当に奇妙だと思います。 あなたはこれについて何をすべきか本当にわかりません。

本当にあなたがそれについてできることはあまりないので。

ここで何が起こったのですか？

私たち全員が問題を見たので、物語の中で実際に起こったことを少し見てみましょう。 まず第一に、2つのクラスが明らかに同じ名前であり、両方がライセンスマネージャーを含んでいるのに、PHPが致命的なエラーを引き起こさなかったのはなぜですか？

これは、Composerによって生成されたオートローダーを使用したためです。 このオートローダーは、依存関係のディレクトリ構造をスキャンし、すべてのクラスをオートローダーに追加します。 クラスがすでに追加されている場合、Composerはそれを無視します。 静かに。 自分で見たい場合は、小さなコード例を作成しました。 GitHubにあります。

私のバージョンのライセンスマネージャーがあなたのバージョンの前に含まれていたのはなぜですか？

これは、私のプラグインの名前があなたのプラグインの前に読み込まれる原因となったために発生しました。 たぶん、将来的には、最初にロードするために、プラグインに「AaaaaaMyPlugin」という名前を付ける予定です。

要約すると、ここでの主な問題は、どのバージョンの依存関係がいつ利用可能かわからないということです。 プラグイン開発者として完全に制御できない要因に依存します。

これはComposer固有の問題ですか？

いいえ、そうではありません。 WordPressには、プラグインやテーマのサードパーティコードを処理する方法がありません。 そこに問題があります。 私がComposerについて話している理由は、最近多くの注目を集めているからです。 WordPress開発者がWordPress.org経由でリリースされたプラグインでComposerを使用したい場合、これは何らかの方法で解決する必要があります。 そうしないと、使用するプラグインが異なるためにすべてのプラグインが相互に互換性を失い始めると、真の混乱が生じます。 地獄のデバッグへようこそ。

これについて何ができますか？

これを本当に心配し、潜在的な解決策を見つけるために一生懸命働いた人は、CoenJacobsです。 私はCoenに連絡して、これについて私たちにできることがあるかどうか彼に尋ねることにしました。

多くの開発者はすでにプラグインにサードパーティのコードを組み込んでいます。 これは本当に問題ですか？

はい、これはプラグインエコシステムの問題です。 より多くの人々が共通の機能を別々のパッケージに入れるのが良い考えであると理解するとき、それはさらに悪化するでしょう。 これらのパッケージは複数のプラグインにバンドルでき、問題はますます発生します。 私は、この問題の原因を突き止めようとして、すでにデバッグ地獄を経験している2人の開発者と話をしています。

今後、開発者がプラグインにサードパーティのコードを含めるのをやめることを提案しますか？

私はこの問題について少し引き裂かれています。 開発者の観点からは、プラグインに共有パッケージをバンドルするのをやめるように人々に指示することは意味がありません。 一方、誰もが自分のユーザーにとって可能な限り最高のユーザーエクスペリエンスを望んでいます。 確かに決めるのは難しい決断です。

この時点で、WordPress関連の開発を進めていきたいと思います。 ライブラリを共有し、他の人が共有しているライブラリを使用したい。 誰も何度も何度も車輪の再発明をするべきではありません。 ですから、私はこのような問題にぶつかるリスクを冒して、問題が発生したときにそれを解決します。

これはまた、私がこの問題の長期的な解決策を見つけるために最善を尽くすことを意味します。 より多くの人々がComposerを使い始め、より多くの人々がプラグインにライブラリをバンドルするでしょう。 この問題はより頻繁に発生するため、修正する必要があります。

この問題を防ぐためにプラグイン開発者は何ができますか？

一部の人々がすでに使用しているのを見た回避策があります。 基本的には、依存関係をプラグインの名前空間に移動することになります。 Danny van Kootenは、彼のプラグインの1つに対してこれを行いました。 ただし、これは理想的ではありません。 依存関係を更新するたびに、すべてのファイルを調べて、名前空間を再度変更する必要があります。 現在、これはPimpleのような比較的小さなライブラリにとってはそれほど大きな作業ではありませんが、大きなライブラリにとっては大規模な作業です。

ただし、これは名前空間でのみ実行できるため、プラグインにPHP5.3以降も必要にする必要があります。 うそをつくつもりはありません。遅かれ早かれ、すべてのプラグインがそれを開始する必要があると思いますが、これを行うことを決定するときは、間違いなく考慮する必要があります。

もしあれば、理想的な解決策は何でしょうか？

理想的な状況は、ある種の依存関係マネージャーを使用することです。 もちろん、最も使用されている依存関係マネージャーであるComposerもあります。 Composerは、不可能ではないにしても、WordPressユーザーの大多数が使用するのは非常に困難です。 結局のところ、それは開発者のツールです。

WordPressは、開発者が必要なほとんどすべてのパッケージを利用できるようにしながら、エンドユーザーにとってこれを容易にする必要があります。 この考えで、私はWordPress Composerインストーラープラグインをまとめ始めました。これは、人々がいつものようにプラグインをインストールしている間、すべてのハードなComposer作業を実行します。 これを完了することができたらすぐに、プラグインインストーラーフロー全体に適切に統合します。

いつか、これをコアのWordPressに統合できるようになるかもしれません。 まだ長い道のりですが、概念実証はすでに機能しています。

結論

あなたがこれまで読んでいるなら、まず第一に：ありがとう。 第二に、これが最終的に問題になるものであることがわかります。 必要なツールがないため、現在の状況は非常に苛立たしいものです。 それでも、これについて話し続け、WordPress開発者として、コード内のサードパーティの依存関係の競合によって引き起こされる潜在的な問題を理解することが重要だと思います。

最後に、これはComposerの問題ではないことをもう一度述べたいと思います。 これはWordPressの問題です。