Entendendo herança de temas no Magento 2.0

O conceito de herança do tema

Um aspecto muito importante do Magento é o modelo de retorno(fallback model). A herança de tema no Magento 2.x foi completamente redesenhada. O resultado principal disso é que recursos alternativos ilimitados são suportados e o diretório padrão não é mais uma parte do mecanismo de retorno.

A ordem de retorno é ligeiramente diferente para assets estáticos (JavaScript, Less CSS, CSS) e modelos, então analisaremos esses dois casos em detalhes. Antes de explicar a ordem de retorno, precisamos entender como os temas pais são estabelecidos no theme.xml.

Configurando um tema pai no theme.xml

Este é modelo principal de recurso. Em qualquer tema, você tem a opção de identificar o tema pai. Isso é feito no arquivo theme.xml, no diretório raiz do tema.

Como você pode ver, o tema principal é especificado explicitamente e, neste caso, é o tema Magento Luma. Isso significa que todos os arquivos não encontrados no tema "Vendor Theme" serão retirados do tema Luma. Quaisquer arquivos que não sejam encontrados, por padrão, serão retirados do tema Magento "em branco", e se não forem encontrados, eles serão retirados dos arquivos do módulo.

Substituindo arquivos estáticos

Os recursos estáticos são conteúdo como arquivos JavaScript, CSS, imagens, fontes e arquivos Less CSS. Embora os arquivos Less CSS não sejam, tecnicamente falando, arquivos estáticos, eles produzem o CSS final, então são categorizados como tais:

 1 - Se o contexto do módulo não for definido para um arquivo, o Magento começará por verificar os arquivos estáticos do tema atual, no diretório web, /web/imagename.jpg.

•  Se uma correspondência não for encontrada, verificará recursivamente os arquivos estáticos do tema ancestral até que um tema sem pai seja encontrado.
• Se ainda não houver correspondência, o Magento verificará os arquivos de exibição estática da biblioteca em lib / web /.

2 - Se houver um contexto de módulo estabelecido para um arquivo estático, o retorno é um pouco diferente. Ele começará com os arquivos estáticos do módulo atual do tema.

3 - Depois disso, procurará antepassados, novamente recursivamente, até encontrar um tema sem pais. O Magento procurará os arquivos estáticos do módulo na área do frontend: / view / frontend / web /.

4 - E, finalmente, na área base, / view / base / web /.

Substituindo arquivos de tema 

O mecanismo de retorno para arquivos de tema é mais simples, pois o contexto do módulo é sempre conhecido por eles.

1. O Magento começa por olhar os modelos para o tema atual em / _ /templates.
2. A seguir, o Magento verifica os modelos dos antepassados até que um antepassado com nenhum pai seja atingido: / _ /templates.
3. Finalmente, os modelos do módulo: / view / frontend / templates.

Aqui está uma representação do novo modelo de retorno no Magento 2.0. É um pouco complicado, então vamos percorrer cada cenário representado aqui: 

• no caso de Vendor_Theme_1, não há nenhum pai declarado no theme.xml, e não há arquivos module_override e não há arquivos de substituição estática. Neste caso, os pedidos para o tema retornarão aos arquivos do tema do módulo. 
• No caso do Vendor_Theme_2, há uma substituição do módulo, mas nenhum pai foi declarado. Os pedidos para o tema aqui retornarão para o magento_blank e, posteriormente, os arquivos do tema do módulo.
• Vendor_Theme_3 e Vendor_Theme_4 ambos têm o Vendor_Theme_2 identificado como pai no theme.xml e tem substituições do CSS. Nesses casos, os pedidos para o CSS voltarão a Vendor_Theme_2 e, em seguida, Magento_Blank:

O modelo de retorno é um tremendo atalho para os desenvolvedores. Quando um novo tema é criado, ele só tem que conter os elementos que são diferentes do que é fornecido pelos arquivos do pacote pai ou módulo. Por exemplo, se todas as partes de um design de site desejado são semelhantes ao tema pai, exceto pela aparência gráfica do site, um novo tema pode ser criado simplesmente adicionando novos arquivos CSS e imagens a um novo tema. Todos os novos arquivos CSS precisarão ser incluídos no arquivo local.xml para o seu tema. Se o design requer estruturas de layout diferentes, apenas os arquivos de layout e modelo alterados precisam ser criados; Tudo o que permanece o mesmo não precisa ser duplicado. 

Se você tiver o cuidado de não alterar o tema do magento_blank e os arquivos do módulo do módulo padrão, as futuras atualizações para a funcionalidade principal do Magento não quebrarão sua instalação. Você terá acesso às novas melhorias com base em seu pacote ou tema de design personalizado, tornando sua instalação virtualmente a prova de atualização.