Global, website ou store view: por que “mudar só numa loja” mexe no orçamento Magento

Diferença entre website, loja e store view no Magento

A documentação da Adobe descreve a hierarquia em cascata. Global vale para a instalação inteira. Website é o nível das configurações de funcionalidade e pode ter domínio próprio. Loja (store) define a categoria raiz, ou seja, o menu e o catálogo que aparece. Store view é o nível do idioma e da tradução, e cada uma pode ter base URL própria. Um exemplo de estrutura:

Global (instalação inteira)
└── Website: sualoja.com.br
    ├── Loja: Varejo (categoria raiz Varejo)
    │   ├── Store view: Português
    │   └── Store view: Español
    └── Loja: Atacado (categoria raiz Atacado)
        └── Store view: Português

Em Stores > Settings > Configuration, o admin mostra em letra pequena, abaixo do nome de cada campo, até onde ele desce. Quando você troca o seletor de escopo no topo da tela, aparece uma caixa ao lado do campo: Use Default no nível de website e Use Website no nível de store view. Marcada, ela diz que aquele nível herda o valor de cima. Desmarcada, o nível passa a ter valor próprio. Se o campo nem aparece quando você escolhe uma store view, é porque ele não aceita valor naquele nível.

Três configurações que decidem o que cada website pode ter

Catalog Price Scope

Fica em Stores > Configuration > Catalog > Catalog > Price, com o caminho catalog/price/scope, e só pode ser alterada no escopo padrão. Tem duas opções: Global ou Website. Quando vai para Website, o próprio Magento troca o escopo de todos os atributos de preço para website, e a moeda base pode ser diferente em cada website. Não existe a opção store view: no core, preço nunca desce abaixo de website.

Por mexer em todos os atributos de preço de uma vez, essa troca eu só faço depois de testar num ambiente de homologação.

Share Customer Accounts

Em Stores > Configuration > Customers > Customer Configuration > Account Sharing Options (customer/account_share/scope), também só no escopo padrão. Per Website, o valor de fábrica, prende a conta ao website onde ela foi criada. Global deixa o cliente entrar em qualquer website. A troca para Global é recusada, com mensagem de erro, se o mesmo e-mail já existir em mais de um website.

Moeda base e moeda de exibição

Em Stores > Configuration > General > Currency Setup, a Base Currency aceita valor por website, e o próprio campo do Catalog Price Scope avisa que é ele que define o escopo da moeda base. A Default Display Currency desce até store view, mas só muda a moeda mostrada: a cobrança continua na moeda base.

Dez pedidos comuns e o menor escopo em que cada um cabe sem código

Conferi os campos de configuração nos atributos showInDefault, showInWebsite e showInStore do system.xml do Magento 2.4.9, que é onde o core define até onde cada campo desce. Nome, descrição e preço por grupo de cliente não são campos de configuração: o escopo deles vem dos atributos de produto do catálogo.

Repare no padrão: tudo que envolve dinheiro (preço, pagamento, frete, pedido mínimo) para no website. Tudo que envolve texto e idioma desce até store view. Loja com vários idiomas no mesmo website que quer preço ou pagamento diferente por idioma esbarra nesse limite.

Configuração só para uma store view: por que o esforço muda

Enquanto o pedido cabe no escopo do campo, o trabalho é trocar um valor no admin, testar e pronto. Quando ele desce abaixo, o programador Magento de backend precisa escolher entre caminhos que envolvem código:

• Campo de configuração novo com o escopo desejado, declarado num módulo, e código que leia esse campo no lugar do original.
• Plugin sobre o método do core que decide o comportamento, por exemplo a disponibilidade de um meio de pagamento, consultando a store view atual.
• Atributo ou regra própria, quando o valor mora no produto ou no cliente.

Preço é o caso mais caro. O índice de preços do Magento, a tabela catalog_product_index_price, é organizado por website e grupo de cliente, sem coluna de store view. Preço por idioma dentro do mesmo website briga com esse índice, com o carrinho e com a listagem de categoria ao mesmo tempo.

Tem ainda o custo que não aparece no código: cada store view afetada precisa ser homologada separadamente, e cada atualização futura do Magento precisa ser testada contra essa customização. Por isso não há número de horas aqui: a estimativa vem do dev, depois de confirmar o escopo do campo.

Como pedir ao dev uma mudança que vale só para uma loja

Junto com os dados da loja, escreva antes de mandar o pedido:

1. Em qual website, loja e store view a mudança vale, com o código de cada um (aparece em Stores > All Stores, e o dev lista com bin/magento store:website:list e bin/magento store:list).
2. Qual é o comportamento atual em cada um deles.
3. O que não pode mudar nos outros.
4. Se clientes e carrinhos são compartilhados entre essas lojas.

E faça ao dev uma pergunta só: qual é o menor escopo desse campo no system.xml? Se a resposta cobre o seu pedido, peça configuração. Se não cobre, peça a descrição da solução e a lista do que será testado em cada store view antes do valor.