Por que o Magento tem 3 conjuntos de códigos?

O Magento possui três conjuntos de códigos:

1. comunidade
2. testemunho
3. local

Núcleo: contém todos os módulos padrão do Magento

Comunidade e local: usamos esses conjuntos de códigos para o desenvolvimento de módulos personalizados.

Agora eu tenho dúvidas sobre isso:

• por que o Magento usa dois conjuntos de códigos para nossa personalização?
• por que o Magento não usa um único conjunto de códigos para personalização?

Alguém poderia explicar sobre isso?

app / code / core - Contém módulos que são distribuídos com o Magento base e compõem a funcionalidade principal.

app / code / community - contém módulos desenvolvidos por terceiros

app / code / local - contém módulos personalizados que você desenvolveu, incluindo substituições de código Mage.

Por que o Magento usa dois conjuntos de códigos para nossa personalização?

Magento realmente usa três pools de códigos. Carregará primeiro o local , o segundo da comunidade e o terceiro do núcleo . Ele usa três para fins de organização e para ajudar a resolver problemas quando duas extensões de terceiros tentam reescrever a mesma coisa. Em um exemplo, se você tiver duas extensões no aplicativo / código / comunidade tentando reescrever o mesmo modelo, você pode simplesmente fazer uma extensão no aplicativo / código / local e mesclar a lógica das duas extensões.

Por que o Magento não usa pool de código único para personalização?

Foi feito dessa maneira para tentar ter alguma organização de código. Além disso, quando você tem conflitos de terceiros, o local é ótimo para ajudar a resolver esses problemas. O local também é ótimo para ter extensões que somente esse site terá.

core :Esse pool de códigos pertence à equipe de desenvolvimento principal do Magento. Portanto, você NÃO deve fazer nenhuma modificação nesse conjunto de códigos.

community :Isso pertence aos desenvolvedores da comunidade Magento (incluindo qualquer desenvolvedor que desenvolva extensões de terceiros). Se você estiver criando extensões de terceiros, poderá usar esse conjunto de códigos para isso.

local :Isso pode ser usado se você quiser fazer modificações (adicionar novas funcionalidades / substituição de extensão / modificações de funcionalidade principal etc.) especificamente para sua loja Magento e não quiser compartilhá-lo com a comunidade. Ao mesmo tempo, você pode substituir a funcionalidade nos conjuntos de códigos principais e da comunidade

Descrever Magento Codepools

Pool principal

Antes de tudo, esta pasta armazena todo o código que torna o Magento tão poderoso, flexível e adorável. A principal regra do desenvolvimento do Magento é que você nunca deve fazer alterações nele. Em outras palavras, essa pasta pertence apenas aos desenvolvedores principais do Magento e, se você quiser editar algo neste pool, o espírito maligno deles poderá puni-lo mesmo através da exibição.

Piscina comunitária

Esta pasta pertence inteiramente aos desenvolvedores da comunidade. Este é o lugar certo para centenas de extensões de terceiros, gratuitas e pagas, que podem ser encontradas no MagentoConnect ou disponíveis na loja de desenvolvimento de extensões. Então, basicamente, se você instalou alguma extensão, ela deve estar em app / code / community / only.

Piscina local

Se você possui sua própria loja baseada em Magento e deseja fazer tudo sozinho ou é um desenvolvedor de Magento e tem o objetivo de mudar a lógica de alguma forma, o pool local é o lugar onde tudo deve ser feito. Se você deseja substituir extensões, blocos ou métodos do Magento, copie as pastas necessárias do pool Core e faça o que estiver disposto a fazer. Aplique a mesma regra para extensões personalizadas criadas especificamente para o site - todo o código deve estar no pool local.

Adicionando tudo o que foi dito acima, é simples fazer prioridades e ter modularidade. Você pode verificar o mesmo no Mage.php.

Carregando pools de códigos com

 $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 primeiro Local chamado então comunidade então core e magento não encontrará nenhum arquivo core então procurará na pasta lib que contém os arquivos Core do Zend-Framework

A melhor explicação que tenho é que, se você pretende distribuir suas extensões para um público mais amplo, por exemplo, através do Magento Connect, pode colocá-lo na comunidade.

Isso permitiria que outro desenvolvedor substituísse o comportamento colocando uma classe na pasta local.