DocumentaçãoAEMGuia do usuário

Criar, Atualizar e Refatorar Blocos block-development

Última atualização: 12 de novembro de 2026
  • Aplica-se a:
  • Experience Manager as a Cloud Service

Criado para:

  • Usuário
  • Admin
  • Desenvolvedor

Use o Agente de modernização de experiência para o desenvolvimento e a migração contínuos do Edge Delivery Services. Comece com a necessidade do autor e o conteúdo real e escolha a menor implementação compatível.

O agente segue o CDD (Content-Driven Development, desenvolvimento orientado por conteúdo) nesse trabalho. Ele começa a partir de conteúdo real e de como os autores irão criá-lo, e escreve código depois disso. Isso mantém os modelos de conteúdo fáceis de usar pelos autores e evita blocos que somente os desenvolvedores podem preencher.

Conecte o repositório e a ramificação pretendidos, confirme as permissões de modificação e identifique onde o conteúdo está armazenado. Preserve uma linha de base antes de alterar o código compartilhado ou os modelos de conteúdo.

Compor antes de criar um bloco composition

Os elementos do HTML são as unidades fundamentais ou átomos: cabeçalhos, parágrafos, links, listas e imagens. Os autores devem usar o conteúdo padrão, o conteúdo fora dos blocos, sempre que possível para eles. Estilos globais e propriedades personalizadas de CSS, ou tokens de design, definem tipografia, cores, espaçamento e apresentação de link/botão compartilhados.

Um bloco permite que os autores marquem qual conteúdo forma um componente, como um conjunto de cartões ou um carrossel, em que o código não poderia separá-lo do conteúdo padrão ao redor. No HTML que o site fornece, um bloco é um div com o nome do bloco como sua classe. O blocks/<name>/<name>.js e o blocks/<name>/<name>.css do projeto o decoram no navegador. Onde o código pode reconhecer um padrão no conteúdo padrão, ele pode criar o próprio bloco, que o aem.live chama bloqueio automático: o modelo do AEM, por exemplo, transforma um link para uma página /widgets/ em um bloco de widget. Mantenha um bloco leve e focado. Uma diferença visual por si só não precisa de um novo bloco: o CSS e o JavaScript podem estilizar o conteúdo padrão, e uma variante ou um estilo de seção podem carregar a diferença.

O Modelo de David coleta as regras aem.live para conteúdo que os autores podem criar facilmente: prefira conteúdo padrão, evite blocos dentro de blocos, mantenha o número de blocos e variantes pequeno e permita que os botões assumam seu estilo do bloco ou seção em que estão. Quando um bloco executar a mesma tarefa que a Coleção de Blocos, reutilize o modelo de conteúdo do bloco.

Verifique as convenções do projeto antes de gerar o código:

Necessidade
Decisão de verificação
Call to action (CTA)
Como um link criado se torna um botão (consulte o exemplo), quais variantes existem e como o rótulo e o destino permanecem editáveis.
Grupo de botões
Se os links adjacentes/conteúdo padrão já oferecerem suporte ao agrupamento ou se um modelo reutilizável for necessário para a ordem, o encapsulamento e as variantes.
Nota de rodapé
Como marcadores, IDs de público alvo, links de retorno e ordem de leitura são criados e preservados.
Conteúdo repetido
Se um bloco ou variante de cartões/lista existente o representa sem campos de autor adicionais.

O Edge Delivery Services não tem controle de grupo de botões ou nota de rodapé integrado. Cada uma é uma convenção que o código do projeto aplica ao conteúdo criado, portanto, verifique como seu projeto o implementa e teste o resultado renderizado.

Exemplo: Um Teaser Flexível Sem Blocos Atômicos composition-example

Os projetos do Adobe Experience Manager baseados em componentes geralmente fornecem um componente de teaser ou componentes de cabeçalho, imagem, texto e botão separados, para que os autores possam combiná-los. A página inicial do site de amostra do WKND, por exemplo, promove cada viagem com um teaser dos Componentes principais. Com o Edge Delivery Services, os autores gravam os mesmos elementos diretamente como conteúdo padrão, em uma seção ou em uma célula de bloco:

[Image]
## Downhill Skiing Wyoming
A skier's paradise far from crowds and close to nature.
**[View trip](/adventures/downhill-skiing-wyoming)**
_[All adventures](/adventures)_

Na chapa do AEM atual, um link que está sozinho em seu parágrafo se torna um botão quando está formatado: negrito para um botão principal, itálico para um botão secundário e negrito mais itálico para um botão de ênfase. Um link simples, ou um link dentro de uma sentença, permanece um link. Os estilos globais dão a esses botões a mesma aparência no conteúdo padrão e dentro dos blocos.

Os autores podem adicionar, remover ou reordenar o cabeçalho, texto, imagem e links sem novos componentes. Um teaser ou bloco herói é necessário apenas onde os autores devem marcar quais elementos pertencem juntos; o CSS e o JavaScript também podem colocar a imagem ao lado do texto no conteúdo padrão. Os projetos podem alterar essas convenções, portanto, peça ao agente para verificar os scripts e estilos do projeto antes de depender deles.

Solicitar um bloco block-prompts

Você pode começar com um aviso curto, como “Criar um bloco de depoimentos”. Adicione contexto onde ajuda o agente a corresponder a algo específico:

Para mostrar o agente
Fornecer
Um design em um site existente
O URL da página e a seção a ser correspondida.
Um design que não esteja online
Uma captura de tela ou imagem (JPEG, PNG, GIF ou WebP), com Anexar arquivos na entrada de prompt. Para designs do Figma, consulte Criar um bloco do Figma.
Um elemento na visualização do console
Selecione-o com Modo de inspeção nas exibições de conteúdo, para que o agente limite suas alterações a esse elemento. Consulte Fazer A Primeira Alteração.
Como os autores preenchem o bloco
Exemplo de conteúdo, as partes que são opcionais ou repetidas e as variantes necessárias.

Uma página de referência ou captura de tela mostra a aparência do público alvo. Ele não define o que os autores editam, então diga isso também.

Reutilizar blocos existentes reuse-blocks

Antes de o agente criar um bloco, ele procura um para reutilizar ou adaptar: na pasta blocks do seu projeto e na Coleção de Blocos e Parte do Bloco para o código de referência. Durante a migração, ele também verifica a biblioteca de blocos, se você tiver uma.

  • Para reutilizar blocos de outro repositório, adicione-os primeiro à pasta blocks do projeto, por exemplo, enviando-os por push à sua ramificação e depois enviando o código para o console.
  • Registre suas convenções de nome, variante e conteúdo nos arquivos de instrução do projeto, para que novos blocos as sigam.

Blocos de construção, um de cada vez iterate-blocks

Quando precisar de vários blocos, não solicite todos eles em um único prompt. Crie um ou dois blocos representativos primeiro e verifique o modelo de conteúdo, o estilo e a criação. Em seguida, continue com as outras, para que as decisões tomadas, como nomes, variantes e espaçamento, continuem. Em uma migração, gere e valide os blocos de um modelo representativo antes do restante; consulte Fluxo de Trabalho de Importação em Massa.

Definir comportamento de bloco antes de uma migração block-instructions

A migração gera blocos do conteúdo que encontra nas páginas de origem. Para orientar como um bloco é criado antes que o agente o gere:

  • Descreva no prompt de migração, por exemplo, quais seções de origem se tornam um bloco com variantes, quais partes os autores editam ou que uma lista deve carregar seus itens dinamicamente.
  • Grave convenções duradouras nos arquivos de instruções do projeto antes de começar.
  • No modo de exibição de Planejamento, corrija os tipos de blocos e as variantes antes de gerar o código. Para descrever como um bloco deve se comportar, selecione-o, escolha Adicionar ao chat e escreva sua solicitação.

O modo automático não aceita instruções durante uma execução. Refine seus blocos no console posteriormente.

Criar um bloco create

Forneça a tarefa do autor, exemplo de conteúdo, o comportamento e o design que você deseja, onde o conteúdo está armazenado e uma página de teste.

  1. Peça ao agente que inspecione os blocos existentes e as implementações de referência adequadas. Prefira reutilização ou uma variante a uma duplicata.
  2. Defina um modelo de conteúdo que os autores possam entender. Use cabeçalhos, links, imagens e conteúdo agrupado naturalmente, em vez de expor o CSS ou os detalhes da implementação como campos.
  3. Crie conteúdo representativo primeiro. Inclua texto longo, valores opcionais ausentes, vários itens e imagens/links significativos.
  4. Implemente apenas a decoração, o CSS e o JavaScript do HTML necessários. Reutilizar tokens de projeto e utilitários compartilhados.
  5. Para criação no Experience Manager, atualize a configuração dos modelos/componentes de origem e gere novamente as agregações por meio do fluxo de trabalho do projeto. Um modelo de bloco define os campos que os autores editam no Editor Universal; o editor lê o modelo, não uma tabela em um documento, então o bloco é editável lá apenas quando seu modelo define esses campos. Verifique as dicas de conversão e criação.
  6. Valide e documente um exemplo que os autores possam editar e as variantes permitidas.

Por exemplo:

Crie um bloco de depoimentos para nossas páginas baseadas em documento. Comece a partir destes exemplos de conteúdo real: /about e /customers. Verifique primeiro os blocos existentes. Os autores precisam editar a cotação, a atribuição e a imagem opcional sem a configuração de layout. Use nossos tokens. Inclua texto longo e exemplos sem imagem. Não carregue, envie nem publique.

Substitua os caminhos de exemplo pelos seus próprios.

O resultado é um código reutilizável, um modelo em que os autores precisam de um e um exemplo de conteúdo que os autores podem editar.

O que o agente fornece com um bloco block-deliverables

  • Documentação de bloqueio: quando a migração cria um bloco, ela gera o bloco do modelo de conteúdo encontrado nas suas páginas e adiciona um README para desenvolvedores e um guia de criação para autores. Revise ambos, mantenha-os atualizados ao alterar o bloco e faça referência a eles nos arquivos de instrução do projeto para que conversas posteriores sigam as convenções do bloco.
  • Conteúdo de exemplo: o agente gera conteúdo de exemplo para blocos, de modo que você possa visualizá-los com conteúdo realista. No catálogo de sites, use Exibir exemplo para abrir a página de exemplo de um bloco.
  • Biblioteca de blocos: a biblioteca de blocos permite que os autores encontrem seus blocos personalizados e os insiram em páginas, com conteúdo de exemplo que mostra como cada bloco deve ser usado. Para configurá-la, peça ao agente para gerar uma biblioteca de blocos, incluindo conteúdo de amostra e a configuração da biblioteca, para a Experience Workspace (que substitui a Criação de documentos) ou para a criação de Experience Manager. A configuração da biblioteca de blocos é um recurso opcional que ela oferece para ser ativado para o seu projeto. Verifique o resultado na experiência de criação. Defina a URL da Biblioteca em Configurações para o arquivo library.json da biblioteca, que lista os blocos disponíveis, suas variações e o conteúdo de exemplo.

Atualizar um bloco existente update

Forneça o nome do bloco, exemplos/variantes atuais, alteração solicitada e requisitos de compatibilidade.

  1. Identifique páginas usando o bloco, os estilos/utilitários compartilhados e os testes existentes.
  2. Informe o que deve permanecer inalterado, incluindo as estruturas de conteúdo e interações existentes.
  3. Faça a alteração. Uma alteração na apresentação é somente CSS ou JavaScript, de modo que não afeta modelos de conteúdo nem exige a reimportação do conteúdo.
  4. Teste o comportamento alterado e as variantes não afetadas no conteúdo representativo.
  5. Se uma alteração de modelo incompatível for necessária, concorde como o conteúdo existente será migrado e quem aceitará o impacto de criação antes de aplicá-lo.

Por exemplo:

Atualize cards para que a variante de link secundário aprovada funcione em /products e /blog. Preservar as variantes padrão e de imagem existentes e seu conteúdo criado. Verifique a interação do teclado e o invólucro móvel. Não regrave outras páginas nem faça upload de conteúdo.

Substitua os caminhos de exemplo pelos seus próprios.

Entregue o comportamento alterado, as variantes afetadas, as instruções do autor e todas as alterações de conteúdo necessárias.

Refatorar sem alterar o resultado refactor

A refatoração melhora a implementação, preservando o comportamento acordado. Não é o mesmo que reagrupar um catálogo, reprojetar um bloco ou migrar seu modelo de conteúdo.

  1. Nomeie o código a ser melhorado e o motivo, como lógica de decoração duplicada.
  2. Registre o que não deve mudar: modelo de conteúdo, aparência, comportamento responsivo, acessibilidade, os seletores e APIs das quais depende outro código e integrações.
  3. Estabelecer exemplos de linha de base e testes existentes. Verifique os usos de código compartilhado e estilos antes de consolidá-los.
  4. Solicite o menor refatoração que atenda à meta. Mantenha qualquer alteração de comportamento/modelo necessária explícita e separada.
  5. Comparar antes e depois entre as páginas e variantes afetadas, executar as verificações do projeto e inspecionar a comparação.

Por exemplo:

Refatorar lógica de decoração de cartão duplicada em blocks/cards/cards.js e blocks/teaser/teaser.js. Preservar modelos criados, semântica de saída, aparência, comportamento do link, acesso ao teclado e ganchos de análise. Use /products e /blog como exemplos de regressão. Relatar riscos de compatibilidade e resultados do teste. Não migre conteúdo nem envie alterações.

Substitua os caminhos de exemplo pelos seus próprios.

Não há comando de refatoração separado: você pergunta no chat, e o agente altera o código como um desenvolvedor faria, dentro dos limites definidos.

Criar um bloco dinâmico dynamic-blocks

Um bloco dinâmico carrega ou calcula seu conteúdo no navegador, em vez de mostrar apenas o que os autores escrevem. Os exemplos são uma lista dos artigos mais recentes, resultados de pesquisa ou uma lista filtrada. Solicite ao agente que crie um após a migração, como qualquer outro bloco, ou que altere um bloco migrado para funcionar dessa maneira. Descrever:

  • A fonte de dados, como o índice de consulta do site, uma planilha entregue como JSON ou uma API.
  • O que os autores controlam, como o número de itens, a pasta a ser listada ou a ordem de classificação. O agente modela essas configurações como um bloco de configuração: uma tabela de duas colunas de chaves e valores. Use-o somente para configurações que alteram o que o bloco carrega ou mostra, e use variantes para diferenças de estilo.
  • O que cada item mostra e o que o bloco mostra quando não há resultados ou quando os dados não podem ser carregados.

Por exemplo:

Crie um bloco de lista de artigos que mostre os seis artigos mais recentes do índice de consulta do site, com imagem, título e data. Os autores definem o número de artigos e a pasta a ser listada em uma tabela de valores-chave. Mostrar uma mensagem curta quando não houver artigos. Teste no /news. Não carregue, envie nem publique.

O índice de consulta inclui somente páginas publicadas e somente as propriedades que sua configuração extrai. Portanto, verifique ambas antes de testar. Valide os estados vazio e de erro, bem como o resultado normal.

Conectar Serviços e Aplicativos integrations

O agente grava o código que conecta seu site a outros sistemas, incluindo sistemas que não são cobertos por seus complementos. Trabalhar além do Edge Delivery Services explica como trabalhar com ele por meio de uma integração. Esta seção aborda onde esse código é executado.

As páginas do Edge Delivery Services executam esse código no navegador do visitante, de modo que cada conexão faz parte de um bloco, de um widget ou dos scripts do projeto. Se o agente precisar chamar uma API que precise de uma chave enquanto funciona, adicione a chave em Configurações, não no chat.

  • Aplicativos: um formulário, uma página de pesquisa, um localizador de loja ou uma área de conta tem pouco conteúdo de autoria. Criá-lo como um widget: um aplicativo independente na pasta /widgets/ do repositório, que os autores colocam em uma página inserindo seu link. Uma aplicação existente, como uma construída com o React, pode ser adaptada da mesma maneira.
  • APIs: um bloco ou widget chama uma API do navegador. A API deve aceitar solicitações dos domínios do seu site, incluindo os sites de visualização e ativos. Se outros sites precisarem ler os recursos do site, configure cabeçalhos personalizados para os caminhos necessários, nunca para todas as origens.
  • Segredos: Tudo no repositório é entregue ao navegador, portanto, ele não pode conter chaves de API ou tokens. Quando uma API precisar de um segredo, faça uma chamada por meio de um serviço do lado do servidor que mantém o segredo, como Adobe App Builder ou API Mesh, e deixe o bloco chamar esse serviço.
  • Mapas, vídeo e outros serviços inseridos: Alguns serviços emitem chaves destinadas ao navegador, como muitos serviços de mapas, e você restringe cada chave aos domínios do seu site, incluindo a visualização e sites ativos. Essa restrição protege a chave, já que cada visitante pode lê-la. Carregue o serviço quando o visitante chegar a ele, não com o restante da página, para que ele não torne a página mais lenta.
  • Commerce: Páginas do Commerce aborda o complemento para as vitrines da Adobe Commerce e a rota para outras plataformas de comércio.
  • Forms: Envios de formulários aborda o complemento para o Adobe Experience Manager Forms e como conectar um formulário a qualquer destino.
  • Analytics, gerenciamento de tags e consentimento: carregue esses scripts depois que a página for renderizada, para que eles não fiquem lentos. Consulte Manter A Pontuação Do Lighthouse Como 100. Com as Incluir integrações do modo Automático, o agente adiciona as configurações com suporte, desligadas até você ativá-las.

Os complementos são recursos opcionais que o agente oferece para serem ativados quando uma tarefa precisar de um. Quais sistemas se conectam, quem os possui e quem aceita o resultado são as decisões do projeto. Consulte O que resta do Trabalho no Projeto.

Envios de formulários form-submissions

O Edge Delivery Services entrega um formulário, mas não armazena envios ou executa o que os segue. No site de origem, um servidor manipulou cada envio e a importação de página não pode ver esse servidor. Conectar um destino é o mesmo trabalho em qualquer site do Edge Delivery Services, migrado ou não, e como o agente é um agente de codificação de uso geral, você pode solicitá-lo a qualquer momento.

O que o complemento do Forms faz forms-add-on

O complemento de formulários é criado para organizações que licenciam o Adobe Experience Manager Forms. Prepara formulários do Edge Delivery Services para o Experience Manager Forms. Para cada formulário de origem com dois ou mais campos, ele registra os campos em uma definição de formulário, uma planilha salva ao lado da página com uma linha por campo: nome, rótulo, tipo, opções e validação. Em seguida, ele coloca um bloco de formulário na página que se vincula à definição. Os campos e rótulos são conteúdo dessa definição, não dados mantidos em um back-end de formulários. Cada formulário usa o mesmo bloco, chamado form, e sua definição decide o que ele mostra, de modo que o agente não cria variantes do bloco. O complemento salva cada definição na pasta da página, nomeada com base no formulário de origem, e não procura o mesmo formulário em outras páginas. Para manter um formulário que várias páginas são exibidas em um local, peça ao agente para vincular essas páginas a uma única definição.

Se o projeto ainda não tiver um bloco de formulário, o complemento adiciona o bloco de formulário do Experience Manager Forms. Esse bloco envia cada envio para o Serviço de Envio do Forms, que identifica o formulário pelo caminho de sua definição e armazena os dados na planilha vinculada na linha de envio da definição. O complemento não vincula uma planilha e não mantém o endereço ao qual o formulário de origem foi enviado, portanto, conecta um destino antes do formulário entrar em vigor. Consulte Escolher um Destino. O complemento não precisa de licença, mas o bloco de formulário e o Serviço de envio do Forms exigem uma licença do Experience Manager Forms.

Sem o Experience Manager Forms, o inventário de campo do complemento é a parte que ainda ajuda: ele captura os campos, rótulos, tipos, opções e validação de cada formulário. O agente não tem habilidades para outras plataformas de formulário; portanto, ele deve ler a documentação da sua plataforma primeiro, conforme descrito em Trabalhar além do Edge Delivery Services. Em seguida, ele pode criar um bloco de formulário que lê as mesmas definições e envia para a plataforma ou incorporar o formulário que a plataforma hospeda.

O complemento lê cada formulário do HTML que o servidor de origem envia, incluindo formulários de provedores de terceiros quando seus campos estão presentes nesse HTML. Um formulário que um script adiciona no navegador, como um formulário incorporado de uma plataforma de marketing, não está nesse HTML, portanto, o complemento não o importa. Solicite ao agente que recrie esse formulário ou que o incorpore novamente a partir da sua plataforma.

Selecionar um destino form-destination

Os formulários de cliente potencial pertencem onde suas equipes já lidam com clientes potenciais, em uma plataforma de automação de marketing ou em um sistema de gerenciamento de relacionamento com o cliente (CRM), por exemplo:

  • Adobe Marketo Engage
  • Salesforce, por meio da Sales Cloud ou do Engajamento com a conta da Marketing Cloud
  • Microsoft Dynamics 365
  • HubSpot
  • Oracle Eloqua

Quando os envios precisarem atingir vários sistemas, envie-os para uma plataforma de integração, como Adobe Workfront Fusion ou Microsoft Power Automate, ou para sua própria API. Com o Experience Manager Forms, o Serviço de envio do Forms armazena envios em uma planilha ou os envia por email e as ações de envio que são executadas no Experience Manager os encaminham para outros sistemas, como o Marketo Engage, Workfront Fusion, Power Automate ou um terminal REST. Consulte Configurar Ações de Envio.

Muitas dessas plataformas aceitam um envio do navegador em um endpoint de formulário que não precisa de segredo. Se a API da plataforma precisar de uma chave, envie o envio por meio de um serviço do lado do servidor que a mantém, conforme descrito em Segredos acima.

Diga ao agente:

  • Destino: a plataforma e o formulário, lista ou campanha que recebe os dados, com seu ponto de extremidade e documentação, ou a URL do serviço do lado do servidor.
  • Mapeamento de campo: qual campo de formulário vai para qual campo de plataforma, quais campos são necessários e seus formatos.
  • Valores ocultos: valores que os visitantes não inserem, como a origem do lead, a campanha, a URL da página e os parâmetros UTM da visita.
  • Consentimento: as caixas de seleção de aceitação, seus termos aprovados e o link para sua política de privacidade.
  • Proteção contra spam: o método aceito pela sua plataforma, como um CAPTCHA ou um campo de armadilha oculto.
  • Após o envio: a mensagem de confirmação ou a página de agradecimento e quais visitantes verão se o envio falhar.
  • Testando: um formulário de teste ou sandbox e como as entradas de teste são marcadas.

Por exemplo:

Leia primeiro nossa documentação do CRM sobre os envios de formulários em https://developer.example.com/forms. Em seguida, conecte o formulário em /contact ao formulário do CRM contact-us em https://forms.example.com/submit/contact-us. Mapeie nome, sobrenome, email, empresa e país para os campos do CRM FirstName, LastName, Email, Company e Country; email e empresa são obrigatórios. Adicione campos ocultos para a origem de lead “Site”, o URL da página e os parâmetros UTM da visita. Mostrar esta caixa de seleção de consentimento, desmarcada: “Concordo em receber notícias sobre o produto por email”. Depois de um envio bem-sucedido, mostrar “Obrigado, entraremos em contato”. Se falhar, mantenha as entradas do visitante e mostre um erro com uma nova tentativa. Teste com a sandbox do CRM em https://sandbox.example.com. Não carregue, envie nem publique.

Substitua os URLs de exemplo, nomes e textos pelos seus próprios.

O agente atualiza a definição do formulário e o código do bloco de formulário. Ele também pode gravar o código de um serviço do lado do servidor, que sua equipe implanta com o segredo. Na plataforma de recebimento, o administrador configura:

  • O formulário ou endpoint, com os campos esperados e sua validação.
  • Os domínios permitidos para envio: sua visualização e sites ao vivo e seu domínio de produção.
  • Filtros de spam no servidor. As verificações no navegador ajudam os visitantes a preencher o formulário; elas não protegem a plataforma.
  • Como um novo envio é correspondido aos contatos existentes, para que uma pessoa não se torne dois leads.
  • Origem do lead e atribuição, pontuação e roteamento da campanha para a equipe de vendas correta.
  • Emails de confirmação, notificações internas e programas de acompanhamento.
  • Registros de consentimento e onde os dados pessoais são mantidos e por quanto tempo.

Enviar uma entrada de teste do site de visualização. Verifique se ele chegou com cada campo, iniciou o fluxo de trabalho esperado e foi marcado como um teste. Repita a verificação no domínio de produção após o switch.

Páginas do Commerce commerce-pages

O complemento de páginas de comércio estende o fluxo de trabalho de importação de página do Agente de modernização de experiência para vitrines do Adobe Commerce. Ele reconhece páginas de detalhes do produto e páginas de listagem de produtos no site de origem, independentemente da plataforma que o executa, de sinais como dados estruturados do produto, padrões de URL e elementos da página, como um campo de quantidade, uma grade de produto ou filtros. Ele reconstrói cada um como uma página que armazena somente o SKU do produto ou o caminho da categoria, em um bloco comercial, e o conteúdo ao redor, como banners e promoções, em blocos padrão. Os dados do produto não são importados: o bloco de comércio os carrega do catálogo sempre que um visitante abre a página. O agente migra outras páginas com o fluxo de trabalho padrão.

O complemento não grava os blocos de comércio. Ele usa o produto e os blocos de listagem que o projeto já tem e, caso contrário, espera os blocos product-details e product-list-page da matriz da loja de comércio. Inicie o projeto a partir dessa chapa e conecte a loja ao catálogo, para que as páginas importadas mostrem os produtos quando você os marcar. O complemento em si não precisa de licença, mas os componentes integrados da loja exigem uma licença do Adobe Commerce as a Cloud Service ou do Adobe Commerce Optimizer. A Adobe Commerce Optimizer também pode fornecer o catálogo quando outra plataforma de comércio lida com o carrinho, o checkout e os pedidos. Consulte Opções de backend.

Para outra plataforma de comércio sem o Adobe Commerce Optimizer, o complemento não se aplica. O agente cria blocos de produtos e listas que carregam seus dados da API da plataforma, trabalhando a partir da documentação da plataforma, conforme descrito em Trabalhar além da Edge Delivery Services.

O complemento funciona com conteúdo baseado em documento. Para projetos que usam a criação do Experience Manager, o agente usa a migração padrão, que importa o que cada página de produto mostra nesse momento. Decida com sua equipe como essas páginas se conectam ao catálogo.

Validar e entregar validation

Use os comandos lint e test declarados do projeto, além das verificações do navegador no conteúdo real. Peça ao agente para relatar os comandos e os resultados, e não apenas que ele tenha testado.

Verificar:

  • Todas as variantes e casos de borda de conteúdo afetados.
  • Layout de desktop/dispositivo móvel, conteúdo longo e comportamento da imagem.
  • Acesso ao teclado, foco, semântica, rótulos e ordem de leitura.
  • Interações e integrações existentes.
  • Quando os modelos ou o conteúdo são alterados, os autores podem editar, salvar e reabrir o conteúdo em seu editor e visualizá-lo corretamente.
  • Verificações de desempenho relevantes e nenhum novo erro no navegador.

Se uma verificação falhar, retenha o exemplo com falha e corrija a menor camada afetada. Distinguir problemas de visualização/ramificação de código obsoletos de falhas de modelo ou implementação. Execute novamente a verificação com falha e as regressões relevantes.

Revise o diferencial, prepare apenas os arquivos pretendidos e envie por push a política do repositório. Fazer upload do conteúdo de teste ou produção somente quando autorizado; um push de código não o salva. Depois de mesclado em main, o código de bloco se aplica a todas as páginas do site ativo que usam o bloco; consulte Como as Alterações Entram em Vigor.

Para recuperação, reverta o código por meio do Git e restaure o conteúdo remoto alterado separadamente. Mantenha exemplos antigos compatíveis até que qualquer migração de conteúdo necessária seja aceita.

Use a transferência de projeto para reter arquivos, modelos, exemplos, resultados de validação, riscos restantes e a abordagem de recuperação alterados para a próxima pessoa ou agente.

recommendation-more-help
experience-manager-cloud-service-help-main-toc