Pourquoi Magento a-t-il 3 pools de codes?

Magento dispose de trois pools de codes:

1. communauté
2. coeur
3. local

Noyau: il contient tous les modules par défaut de Magento

Communauté et local: nous utilisons ces pools de codes pour le développement de nos modules personnalisés.

Maintenant, j'en doute:

• pourquoi Magento utilise-t-il deux pools de codes pour notre personnalisation?
• pourquoi Magento n'utilise-t-il pas un seul pool de codes pour la personnalisation?

Quelqu'un pourrait-il expliquer cela?

app / code / core - Contient les modules qui sont distribués avec la base Magento et constituent la fonctionnalité de base.

app / code / community - Contient des modules développés par des tiers

app / code / local - Contient les modules personnalisés que vous avez développés, y compris les remplacements de code Mage.

Pourquoi Magento utilise-t-il deux pools de codes pour notre personnalisation?

Magento utilise en fait trois pools de codes. Il chargera le premier local , le deuxième de la communauté et le troisième de base . Il en utilise trois à des fins d'organisation et pour aider à résoudre les problèmes lorsque deux extensions tierces + tentent de réécrire la même chose. Dans un exemple, si vous avez deux extensions dans app / code / community essayant de réécrire le même modèle, vous pouvez simplement créer une extension dans app / code / local et fusionner la logique des deux extensions ensemble.

Pourquoi Magento n'utilise-t-il pas un pool de codes unique pour la personnalisation?

Cela a été fait de cette façon pour essayer d'avoir une certaine organisation du code. De plus, lorsque vous rencontrez des conflits avec des tiers, le local est idéal pour aider à résoudre ces problèmes. Le local est également formidable d'avoir des extensions que seul ce site aura jamais.

core :Ce pool de codes appartient à l'équipe de développement principale de Magento. Vous ne devez donc PAS apporter de modifications à ce pool de codes.

community :Cela appartient aux développeurs de la communauté Magento (y compris tout développeur qui développe des extensions tierces). Si vous créez des extensions tierces, vous pouvez donc utiliser ce pool de codes pour cela.

local :Cela peut être utilisé si vous souhaitez apporter des modifications (ajouter de nouvelles fonctionnalités / remplacement d'extensions / modifications de fonctionnalités de base, etc.) spécifiquement pour votre boutique Magento et ne souhaitez pas les partager avec la communauté. Dans le même temps, vous pouvez remplacer la fonctionnalité dans les pools de code de base et de communauté

Décrire les Codepools Magento

Pool de base

Tout d'abord, ce dossier stocke tout le code qui rend Magento si puissant, flexible et charmant. La règle principale du développement de Magento est que vous ne devez jamais y apporter de modifications. En d'autres termes, ce dossier appartient uniquement aux développeurs principaux de Magento et si vous allez modifier quoi que ce soit dans ce pool, leur mauvais esprit pourrait vous punir même à travers l'affichage.

Piscine communautaire

Ce dossier appartient entièrement aux développeurs de la communauté. C'est le bon endroit pour des centaines d'extensions tierces, gratuites et payantes, qui peuvent être trouvées sur MagentoConnect ou disponibles sur le magasin de développement d'extensions. Donc, fondamentalement, si vous avez installé une extension, elle doit être dans app / code / community / only.

Piscine locale

Si vous avez votre propre boutique basée sur Magento et que vous voulez tout faire par vous-même ou que vous êtes un développeur Magento et que vous avez un objectif de changer la logique d'une manière ou d'une autre, le pool local est l'endroit où tout doit être fait. Si vous souhaitez remplacer les extensions, blocs ou méthodes Magento, copiez les dossiers nécessaires à partir du pool Core et faites tout ce que vous avez envie de faire. Appliquez la même règle pour les extensions personnalisées créées spécifiquement pour le site Web - tout le code doit être dans le pool local.

Ajouter tout ce qui précède en toute simplicité pour établir des priorités et avoir une modularité. Vous pouvez vérifier la même chose dans Mage.php.

Chargement de pools de codes avec

 $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';

SO d'abord Local appelé ensuite communauté puis core et magento ne trouveront aucun fichier core puis ils rechercheront dans le dossier lib qui contient les fichiers Core de Zend-Framework

La meilleure explication que j'ai est que si vous visez à distribuer vos extensions à un public plus large, par exemple via Magento Connect, vous pouvez le placer dans la communauté.

Cela permettrait à un autre développeur de remplacer le comportement en plaçant une classe dans le dossier local.