Magentoに3つのコードプールがあるのはなぜですか？

Magentoには3つのコードプールがあります。

1. コミュニティ
2. コア
3. 地元

コア：すべてのMagentoのデフォルトモジュールが含まれています

コミュニティおよびローカル：これらのコードプールをカスタムモジュール開発に使用します。

今、私はこれについて疑問を持っています：

• Magentoがカスタマイズに2つのコードプールを使用するのはなぜですか？
• なぜMagentoはカスタマイズに単一のコードプールを使用しないのですか？

誰かがこれについて説明できますか？

app / code / core-基本Magentoとともに配布され、コア機能を構成するモジュールを保持します。

app / code / community- サードパーティによって開発されたモジュールを保持します

app / code / local -Mageコードオーバーライドを含む、開発したカスタムモジュールを保持します。

Magentoがカスタマイズに2つのコードプールを使用するのはなぜですか？

Magentoは、実際には3つのコードプールを使用します。最初にローカル、2番目にコミュニティ、3番目にコアをロードします。組織化の目的で3つを使用し、2つ以上のサードパーティの拡張機能が同じことを書き直そうとしているときの問題の解決を支援します。app / code / communityに2つの拡張機能があり、同じモデルを書き換えようとしている例では、単にapp / code / localに拡張機能を作成し、2つの拡張機能ロジックをマージできます。

なぜMagentoはカスタマイズに単一のコードプールを使用しないのですか？

このようにして、何らかのコード編成を試みました。また、サードパーティの競合がある場合、地元の人たちはそれらの問題を解決するのに役立ちます。ローカルは、そのサイトだけが持つ拡張機能を持つことも素晴らしいです。

core :このコードプールは、Magentoコア開発チームに属します。そのため、このコードプールを変更しないでください。

community :これはMagentoコミュニティ開発者（サードパーティの拡張機能を開発する開発者を含む）に属します。サードパーティの拡張機能を作成している場合は、そのためにこのコードプールを使用できます。

local :これは、Magentoストア専用に変更（新しい機能の追加/拡張機能のオーバーライド/コア機能の変更など）を行い、コミュニティと共有したくない場合に使用できます。同時に、コアおよびコミュニティコードプールの機能をオーバーライドできます

Magentoコードプールの説明

コアプール

まず、このフォルダーには、Magentoを非常に強力かつ柔軟で美しいものにするすべてのコードが格納されています。Magento開発の主なルールは、絶対に変更しないでください。言い換えれば、このフォルダーはMagentoのコア開発者のみに属し、このプールで何かを編集しようとすると、彼らの悪霊がディスプレイを通してあなたを罰する可能性があります。

コミュニティプール

このフォルダは完全にコミュニティ開発者に属します。これは、MagentoConnectで見つけることができる、または拡張機能開発ストアで入手できる、無料および有料の何百ものサードパーティ拡張機能に適した場所です。したがって、基本的に、拡張機能をインストールした場合は、app / code / community /にのみ存在する必要があります。

ローカルプール

独自のMagentoベースのストアを所有していて、自分ですべてを作成したい場合、またはMagentoの開発者であり、何らかの形でロジックを変更する目的がある場合、ローカルプールはすべてを行うべき場所です。Magentoの拡張機能、ブロック、またはメソッドをオーバーライドする場合は、コアプールから必要なフォルダーをコピーして、やりたいことを実行します。Webサイト専用に作成されたカスタム拡張機能に同じルールを適用します。すべてのコードはローカルプールにある必要があります。

上記のすべてを簡単に追加して、優先順位を付け、モジュール性を持たせます。Mage.phpで同じことを確認できます。

でコードプールをロードする

 $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'local';
 $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'community';
 $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'core';
 $paths[] = BP . DS . 'lib';

最初にローカルと呼ばれ、次にコミュニティと呼ばれ、コアとmagentoはコアファイルを見つけられず、Zend-Frameworkコアファイルを含むlibフォルダーを検索します

私が持っている最良の説明は、例えばMagento Connectを介して拡張機能をより多くの聴衆に配布することを目指しているなら、それをコミュニティに配置できるということです。

これにより、別の開発者がローカルフォルダーにクラスを配置して動作をオーバーライドできます。