Crear, actualizar y refactorizar bloques block-development
Utilice Experience Modernization Agent para el desarrollo y la migración continuos de Edge Delivery Services. Comience con la necesidad del autor y el contenido real, y luego elija la implementación más pequeña que los admita.
El agente sigue el desarrollo impulsado por contenido (CDD) para este trabajo. Comienza a partir del contenido real y de cómo lo crearán los autores, y escribe código después de eso. Esto mantiene los modelos de contenido fáciles de usar para los autores y evita bloques que solo los desarrolladores pueden rellenar.
Conecte el repositorio y la rama deseados, confirme los permisos de modificación e identifique dónde se almacena el contenido. Conservar una línea de base antes de cambiar el código compartido o los modelos de contenido.
Componer antes de crear un bloque composition
Los elementos HTML son las unidades de creación básicas, o átomos: encabezados, párrafos, vínculos, listas e imágenes. Los autores deben utilizar el contenido predeterminado, el contenido fuera de los bloques, para estos siempre que sea posible. Los estilos globales y las propiedades personalizadas de CSS, o los tokens de diseño, definen la tipografía, los colores, el espaciado y la presentación de vínculos o botones compartidos.
Un bloque permite a los autores marcar qué contenido forma un componente, como un conjunto de tarjetas o un carrusel, en el que el código no pudo distinguirlo del contenido predeterminado circundante. En HTML del sitio, un bloque es un div con el nombre del bloque como clase. blocks/<name>/<name>.js y blocks/<name>/<name>.css del proyecto lo decoran en el explorador. Cuando el código puede reconocer un patrón en el contenido predeterminado, puede crear el propio bloque, que aem.live llama a bloqueo automático: la plantilla de AEM, por ejemplo, convierte un vínculo a una página /widgets/ en un bloque de widgets. Mantenga un bloque ligero y centrado. Una diferencia visual por sí sola no necesita un nuevo bloque: CSS y JavaScript pueden aplicar estilo al contenido predeterminado, y una variante o un estilo de sección pueden ser los que marquen la diferencia.
David’s Model recopila las reglas aem.live para el contenido que los autores pueden crear fácilmente: prefiere el contenido predeterminado, evita bloques dentro de bloques, mantiene el número de bloques y variantes pequeño y deja que los botones tomen su estilo del bloque o la sección en que se encuentran. Cuando un bloque hace el mismo trabajo que uno en la Colección de bloques, reutiliza el modelo de contenido de ese bloque.
Compruebe las convenciones del proyecto antes de generar el código:
Edge Delivery Services no tiene control integrado de grupos de botones o notas al pie. Cada una es una convención por la que el código del proyecto se aplica al contenido creado, de modo que compruebe cómo lo implementa el proyecto y pruebe el resultado procesado.
Ejemplo: Un Teaser Flexible Sin Bloques Atómicos composition-example
Los proyectos de Adobe Experience Manager basados en componentes suelen proporcionar un componente teaser o componentes de encabezado, imagen, texto y botón independientes para que los autores puedan combinarlos. La página de inicio del sitio de muestra WKND, por ejemplo, promociona cada viaje con un teaser de componentes principales. Con Edge Delivery Services, los autores escriben los mismos elementos directamente como contenido predeterminado, ya sea en una sección o en una celda de bloque:
[Image]
## Downhill Skiing Wyoming
A skier's paradise far from crowds and close to nature.
**[View trip](/adventures/downhill-skiing-wyoming)**
_[All adventures](/adventures)_
En la actual plantilla de AEM, un vínculo que se encuentra solo en su párrafo se convierte en un botón cuando tiene formato: negrita para un botón principal, cursiva para un botón secundario y negrita más cursiva para un botón con acento. Un vínculo sin formato, o un vínculo dentro de una frase, sigue siendo un vínculo. Los estilos globales dan a estos botones el mismo aspecto en el contenido predeterminado y dentro de los bloques.
Los autores pueden agregar, quitar o reordenar el encabezado, el texto, la imagen y los vínculos sin componentes nuevos. Un bloque de teaser o héroe solo es necesario cuando los autores deben marcar qué elementos pertenecen juntos; CSS y JavaScript también pueden colocar la imagen junto al texto en el contenido predeterminado. Los proyectos pueden cambiar estas convenciones, por lo que pídale al agente que compruebe los scripts y estilos del proyecto antes de depender de ellos.
Solicitar un bloque block-prompts
Puede comenzar con un breve mensaje, como “Crear un bloque de testimonios”. Añada un contexto en el que ayude al agente a hacer coincidir algo específico:
Una página de referencia o captura de pantalla muestra la apariencia del objetivo. No define lo que editan los autores, así que dilo también.
Reutilizar bloques existentes reuse-blocks
Antes de que el agente cree un bloque, busca uno para reutilizarlo o adaptarlo: en la carpeta blocks de su proyecto, y en la Colección de bloques y la Parte de bloques para el código de referencia. Durante la migración, también comprueba su biblioteca de bloques, si es que la tiene.
- Para reutilizar bloques de otro repositorio, agréguelos primero a la carpeta
blocksde este proyecto, por ejemplo, insertándolos en la rama y luego extrayendo el código en la consola. - Registre sus convenciones de nomenclatura, variante y contenido en los archivos de instrucciones de proyecto, para que los sigan los nuevos bloques.
Generar bloques de uno en uno iterate-blocks
Cuando necesite varios bloques, no los pida todos en un solo mensaje. Cree uno o dos bloques representativos primero y compruebe su modelo de contenido, estilo y creación. A continuación, continúe con las demás, de modo que las decisiones que ha tomado, como nombres, variantes y espaciado, se mantengan. En una migración, genere y valide los bloques de una plantilla representativa antes que el resto; consulte Flujo de trabajo de importación en lotes.
Definir el comportamiento del bloque antes de una migración block-instructions
La migración genera bloques a partir del contenido que encuentra en las páginas de origen. Para dirigir cómo se crea un bloque antes de que el agente lo genere:
- Descríbalo en el mensaje de migración, por ejemplo qué secciones de origen se convierten en un bloque con variantes, qué partes editan los autores o si una lista debe cargar sus elementos dinámicamente.
- Escriba convenciones duraderas en los archivos de instrucciones de proyecto antes de comenzar.
- En la vista de Planning, corrija los tipos de bloques y las variantes antes antes de generar el código. Para describir el comportamiento de un bloque, selecciónelo, elija Agregar al chat y escriba su solicitud.
El modo automático no toma instrucciones durante una ejecución. Refine sus bloques en la consola posteriormente.
Crear un bloque create
Proporcione la tarea de creación, el contenido de ejemplo, el comportamiento y el diseño que desee, dónde se almacena el contenido y una página de prueba.
- Pida al agente que inspeccione los bloques existentes y las implementaciones de referencia adecuadas. Prefiera reutilizar o una variante en lugar de un duplicado.
- Defina un modelo de contenido que los autores puedan comprender. Utilice encabezados, vínculos, imágenes y contenido agrupado de forma natural en lugar de exponer CSS o detalles de implementación como campos.
- Cree primero contenido representativo. Incluya texto largo, valores opcionales que faltan, varios elementos y vínculos o imágenes significativos.
- Implemente únicamente la decoración de HTML, CSS y JavaScript necesarios. Reutilice tokens de proyecto y utilidades compartidas.
- Para la creación de Experience Manager, actualice la configuración de componentes/modelos de origen y vuelva a generar los acumulados a través del flujo de trabajo del proyecto. El modelo de un bloque define los campos que los autores editan en el editor universal; el editor lee el modelo, no una tabla en un documento, de modo que el bloque se puede editar allí solo una vez que su modelo define esos campos. Compruebe las sugerencias de conversión y creación.
- Validar y, a continuación, documentar un ejemplo que los autores pueden editar y las variantes permitidas.
Por ejemplo:
Cree un bloque de testimonios para nuestras páginas basadas en documentos. Comience desde estos ejemplos de contenido real:
/abouty/customers. Compruebe primero los bloques existentes. Los autores deben editar el presupuesto, la atribución y la imagen opcional sin configurar el diseño. Utilice nuestros tokens. Incluya texto largo y ejemplos sin imagen. No cargue, inserte ni publique.
Reemplace las rutas de ejemplo por las suyas.
El resultado es un código reutilizable, un modelo en el que los autores necesitan uno y contenido de ejemplo que los autores pueden editar.
Qué proporciona el agente con un bloque block-deliverables
- Documentación del bloque: Cuando la migración crea un bloque, genera el bloque a partir del modelo de contenido que se encuentra en las páginas y agrega un archivo LÉAME para desarrolladores y una guía de creación para autores. Revise ambos, manténgalos actualizados cuando cambie el bloque y haga referencia a ellos desde los archivos de instrucciones del proyecto para que las conversaciones posteriores sigan las convenciones del bloque.
- Contenido de muestra: El agente genera contenido de muestra para bloques de modo que pueda previsualizarlos con contenido realista. En el catálogo del sitio, use Ver muestra para abrir la página de muestra de un bloque.
- Biblioteca de bloques: La biblioteca de bloques permite a los autores encontrar los bloques personalizados e insertarlos en páginas, con contenido de ejemplo que muestra cómo debe usarse cada bloque. Para configurarlo, pídale al agente que genere una biblioteca de bloques, que incluya contenido de muestra y la configuración de la biblioteca, para Experience Workspace (que sustituye a la creación de documentos) o para la creación de Experience Manager. La configuración de la biblioteca de bloqueados es una capacidad opcional que ofrece para activarla en su proyecto. Compruebe el resultado en la experiencia de creación. Establezca Library URL en Settings en el archivo
library.jsonde la biblioteca, que enumera los bloques disponibles, sus variaciones y contenido de ejemplo.
Actualizar un bloque existente update
Proporcione el nombre del bloque, los ejemplos/variantes actuales, el cambio solicitado y los requisitos de compatibilidad.
- Identifique las páginas mediante el bloque, los estilos/utilidades compartidos y las pruebas existentes.
- Indique lo que debe permanecer sin cambios, incluidas las estructuras de contenido e interacciones existentes.
- Haga el cambio. Un cambio de presentación es solo CSS o JavaScript, por lo que no afecta a los modelos de contenido ni requiere la reimportación de contenido.
- Pruebe el comportamiento modificado y las variantes no afectadas en el contenido representativo.
- Si es necesario un cambio de modelo incompatible, acuerde cómo se migrará el contenido existente y quién acepta el impacto de creación antes de aplicarlo.
Por ejemplo:
Actualice
cardspara que la variante del vínculo secundario aprobada funcione en/productsy/blog. Conservar las variantes predeterminadas y de imagen existentes y su contenido creado. Compruebe la interacción del teclado y el ajuste móvil. No reescriba otras páginas ni cargue contenido.
Reemplace las rutas de ejemplo por las suyas.
Entregue el comportamiento cambiado, las variantes afectadas, las instrucciones del autor y cualquier cambio de contenido requerido.
Refactorizar sin cambiar el resultado refactor
La refactorización mejora la implementación y conserva el comportamiento acordado. No es lo mismo que reagrupar un catálogo, rediseñar un bloque o migrar su modelo de contenido.
- Asigne un nombre al código para mejorar y al motivo, como la lógica de decoración duplicada.
- Registre lo que no debe cambiar: el modelo de contenido, la apariencia, el comportamiento adaptable, la accesibilidad, los selectores y las API en los que se basa otro código y las integraciones.
- Establezca ejemplos de línea de base y pruebas existentes. Compruebe los usos del código y los estilos compartidos antes de consolidarlos.
- Pida el refactor más pequeño que cumpla el objetivo. Mantenga cualquier cambio de comportamiento/modelo necesario explícito e independiente.
- Compare antes y después en las páginas y variantes afectadas, ejecute las comprobaciones del proyecto e inspeccione la comparación de diferencias.
Por ejemplo:
Refactorizar la lógica de decoración de tarjetas duplicada en
blocks/cards/cards.jsyblocks/teaser/teaser.js. Conservar los modelos creados, la semántica de salida, la apariencia, el comportamiento de los vínculos, el acceso al teclado y los vínculos de análisis. Use/productsy/blogcomo ejemplos de regresión. Informe de riesgos de compatibilidad y resultados de pruebas. No migre el contenido ni los cambios push.
Reemplace las rutas de ejemplo por las suyas.
No hay un comando de refactorización independiente: se pregunta en el chat y el agente cambia el código como lo haría un desarrollador, dentro de los límites establecidos.
Crear un bloque dinámico dynamic-blocks
Un bloque dinámico carga o calcula su contenido en el explorador, en lugar de mostrar solo lo que escriben los autores. Algunos ejemplos son una lista de los artículos más recientes, resultados de búsqueda o una lista filtrada. Pida al agente que cree uno después de la migración como cualquier otro bloque, o que cambie un bloque migrado para que funcione de esta manera. Describir:
- El origen de datos, como el índice de consulta del sitio, una hoja de cálculo enviada como JSON o una API.
- Qué controlan los autores, como el número de elementos, la carpeta que se va a enumerar o el criterio de ordenación. El agente modela estos ajustes como un bloque de configuración: una tabla de dos columnas de claves y valores. Utilícelo solo para ajustes que cambien lo que carga o muestra el bloque y utilice variantes para diferencias de estilo.
- Lo que muestra cada elemento, y lo que muestra el bloque cuando no hay resultados o los datos no se pueden cargar.
Por ejemplo:
Cree un bloque de lista de artículos que muestre los seis artículos más recientes del índice de consultas del sitio, con imagen, título y fecha. Los autores establecen el número de artículos y la carpeta para enumerarlos en una tabla de clave-valor. Mostrar un mensaje corto cuando no haya artículos. Pruébelo en /news. No cargue, inserte ni publique.
El índice de consulta incluye solo las páginas publicadas y solo las propiedades que extrae su configuración, por lo que debe comprobar ambas antes de realizar la prueba. Validar los estados vacío y de error, así como el resultado normal.
Conectar servicios y aplicaciones integrations
El agente escribe el código que conecta su sitio con otros sistemas, incluidos los sistemas que sus complementos no cubren. Trabajar más allá de Edge Delivery Services explica cómo usar una integración con él. Esta sección explica dónde se ejecuta ese código.
Las páginas de Edge Delivery Services ejecutan este código en el explorador del visitante, por lo que cada conexión forma parte de un bloque, un widget o los scripts del proyecto. Si el agente debe llamar a una API que necesita una clave mientras funciona, agréguela en Settings, no en el chat.
- Aplicaciones: Un formulario, una página de búsqueda, un localizador de tiendas o un área de cuentas tiene poco contenido creado. Créelo como un widget: una aplicación independiente en la carpeta
/widgets/del repositorio, que los autores colocan en una página insertando su vínculo. Una aplicación existente, como una creada con React, se puede adaptar del mismo modo. - API: Un bloque o widget llama a una API desde el explorador. La API debe aceptar solicitudes de los dominios del sitio, incluidas la vista previa y los sitios activos. Si otros sitios deben leer los recursos del sitio, configure encabezados personalizados para las rutas que necesitan, nunca para todos los orígenes.
- Secretos: Todo lo que hay en el repositorio se envía al explorador, por lo que no puede contener claves ni tokens de API. Cuando una API necesita un secreto, llámele a través de un servicio del lado del servidor que lo mantenga, como Adobe App Builder o API Mesh, y permita que el bloque llame a ese servicio.
- Mapas, vídeo y otros servicios incrustados: Algunos servicios emiten claves pensadas para el explorador, como muchos servicios de mapas, y usted restringe cada clave a los dominios del sitio, incluida la vista previa y los sitios activos. Esa restricción protege la clave, ya que todos los visitantes pueden leerla. Cargue el servicio cuando el visitante llegue a él, no con el resto de la página, para que no ralentice la página.
- Commerce: Commerce Pages cubre el complemento para tiendas Adobe Commerce y la ruta para otras plataformas de comercio.
- Forms: Envíos de formularios cubre el complemento para Adobe Experience Manager Forms y cómo conectar un formulario a cualquier destino.
- Analytics, administración de etiquetas y consentimiento: Cargue estos scripts después de que se haya representado la página para que no la ralenticen. Ver Mantener tu puntuación de Lighthouse en 100. Con las integraciones con Include del modo automático, el agente agrega la configuración admitida, que se desactiva hasta que se activa.
Los complementos son funciones opcionales que el agente ofrece para activarse cuando una tarea lo necesita. Los sistemas que se conectan, quién los posee y quién acepta el resultado son decisiones de proyecto. Ver Lo Que Queda De Trabajo En El Proyecto.
Envío de formularios form-submissions
Edge Delivery Services entrega un formulario, pero no almacena los envíos ni ejecuta lo que les sigue. En el sitio de origen, un servidor administra cada envío y la importación de páginas no puede ver ese servidor. La conexión a un destino es el mismo trabajo en cualquier sitio de Edge Delivery Services, haya migrado o no, y como el agente es un agente de codificación de uso general, puede solicitarlo en cualquier momento.
Qué hace el complemento de Forms forms-add-on
El complemento de formularios está diseñado para organizaciones que obtienen licencias de Adobe Experience Manager Forms. Prepara formularios para Edge Delivery Services para Experience Manager Forms. Para cada formulario de origen con dos o más campos, registra los campos en una definición de formulario, una hoja guardada junto a la página con una fila por campo: su nombre, etiqueta, tipo, opciones y validación. A continuación, coloca un bloque de formulario en la página que se vincula a la definición. Los campos y las etiquetas tienen contenido en esa definición, no en los datos contenidos en un servidor de formularios. Cada formulario utiliza el mismo bloque, denominado form, y su definición decide lo que muestra, de modo que el agente no crea variantes del bloque. El complemento guarda cada definición en la carpeta de la página, con el nombre del formulario de origen, y no busca el mismo formulario en otras páginas. Para mantener un formulario que varias páginas muestren en un solo lugar, pídale al agente que vincule esas páginas a una sola definición.
Si el proyecto aún no tiene ningún bloque de formulario, el complemento agrega el bloque de formulario de Experience Manager Forms. Ese bloque envía cada envío al Servicio de envío de Forms, que identifica el formulario por la ruta de su definición y almacena los datos en la hoja de cálculo vinculada en la fila de envío de la definición. El complemento no vincula una hoja de cálculo y no conserva la dirección a la que se envió el formulario de origen, por lo que debe conectar un destino antes de que el formulario se active. Ver Elegir un destino. El complemento en sí no necesita ninguna licencia, pero el bloque de formulario y el servicio de envío de Forms requieren una licencia de Experience Manager Forms.
Sin Experience Manager Forms, el inventario de campos del complemento es la parte que aún ayuda: captura los campos, las etiquetas, los tipos, las opciones y la validación de cada formulario. El agente no tiene habilidades para otras plataformas de formulario, así que primero lee la documentación de tu plataforma, tal como se describe en Trabajar más allá de Edge Delivery Services. A continuación, puede crear un bloque de formulario que lea las mismas definiciones y se envíe a la plataforma, o incrustar el formulario que aloja la plataforma.
El complemento lee todos los formularios de HTML que envía el servidor de origen, incluidos los formularios de proveedores externos, cuando sus campos están presentes en ese HTML. Un formulario que una secuencia de comandos agrega en el explorador, como un formulario incrustado desde una plataforma de marketing, no está en esa HTML, por lo que el complemento no lo importa. Pida al agente que reconstruya ese formulario o que lo vuelva a incrustar desde su plataforma.
Elegir un destino form-destination
Los formularios de posibles clientes pertenecen a un lugar en el que los equipos ya administran posibles clientes, en una plataforma de automatización de marketing o en un sistema de administración de la relación con los clientes (CRM), por ejemplo:
- Adobe Marketo Engage
- Salesforce, mediante Sales Cloud o Marketing Cloud Account Engagement
- Microsoft Dynamics 365
- HubSpot
- Oracle Eloqua
Cuando los envíos deban llegar a varios sistemas, envíelos a una plataforma de integración, como Adobe Workfront Fusion o Microsoft Power Automate, o a su propia API. Con Experience Manager Forms, el servicio de envío de Forms almacena los envíos en una hoja de cálculo o los envía por correo electrónico, y las acciones de envío que se ejecutan en Experience Manager los reenvían a otros sistemas, como Marketo Engage, Workfront Fusion, Power Automate o un extremo REST. Consulte Configurar acciones de envío.
Muchas de estas plataformas aceptan un envío desde el explorador a un extremo de formulario que no necesita secreto. Si la API de la plataforma necesita una clave, envíe el envío a través de un servicio del lado del servidor que la mantenga, tal como se describe en Secretos más arriba.
Dígale al agente:
- Destino: la plataforma y el formulario, lista o campaña que recibe los datos, con su punto final y documentación, o la dirección URL del servicio del lado del servidor.
- Asignación de campos: qué campo de formulario va a qué campo de plataforma, qué campos son obligatorios y sus formatos.
- Valores ocultos: valores que los visitantes no especifican, como el origen del posible cliente, la campaña, la dirección URL de la página y los parámetros de UTM de la visita.
- Consentimiento: las casillas de verificación de inclusión, su redacción aprobada y el vínculo a su política de privacidad.
- Protección contra correo no deseado: el método que admite su plataforma, como un CAPTCHA o un campo de honeypot oculto.
- Después de enviar: el mensaje de confirmación o la página de agradecimiento, y lo que los visitantes verán si falla el envío.
- Pruebas: un formulario o zona protegida de prueba y cómo se marcan las entradas de prueba.
Por ejemplo:
Primero lea la documentación de CRM sobre los envíos de formularios en
https://developer.example.com/forms. A continuación, conecte el formulario de/contactal formulario CRMcontact-usenhttps://forms.example.com/submit/contact-us. Asigne el nombre, apellidos, correo electrónico, empresa y país a los campos CRMFirstName,LastName,CompanyyCountry; se requiere el correo electrónico y la empresa. Añada campos ocultos para el origen del posible cliente “Sitio web”, la dirección URL de la página y los parámetros de UTM de la visita. Mostrar esta casilla de verificación de consentimiento sin marcar: “Acepto recibir noticias de productos por correo electrónico”. Después de un envío correcto, mostrar “Gracias, nos pondremos en contacto”. Si falla, mantenga las entradas del visitante y muestre un error con un reintento. Realizar pruebas en la zona protegida de CRM enhttps://sandbox.example.com. No cargue, inserte ni publique.
Reemplace las direcciones URL, los nombres y las palabras de ejemplo por los suyos propios.
El agente actualiza la definición del formulario y el código del bloque del formulario. También puede escribir el código de un servicio del lado del servidor, que su equipo implementa con el secreto. En la plataforma de recepción, su administrador configura:
- El formulario o extremo, con los campos que espera y su validación.
- Los dominios a los que se permite enviar: la vista previa y los sitios activos, y el dominio de producción.
- Filtrado de spam en el servidor. Las comprobaciones en el explorador ayudan a los visitantes a rellenar el formulario; no protegen la plataforma.
- Cómo se relaciona un nuevo envío con los contactos existentes, de modo que una persona no se convierta en dos posibles clientes.
- Atribución, puntuación y enrutamiento de origen y campaña del posible cliente al equipo de ventas correcto.
- Correos electrónicos de confirmación, notificaciones internas y programas de seguimiento.
- Registros de consentimiento, dónde se guardan los datos personales y durante cuánto tiempo.
Envíe una entrada de prueba desde el sitio de vista previa. Compruebe que llegó con todos los campos, inició el flujo de trabajo esperado y se marcó como una prueba. Repita la comprobación en el dominio de producción después del cambio.
Páginas del comercio commerce-pages
El complemento de las páginas de comercio amplía el flujo de trabajo de importación de páginas del agente de modernización de experiencias para las tiendas de Adobe Commerce. Reconoce páginas de detalles de productos y páginas de listas de productos en el sitio de origen, independientemente de la plataforma que lo ejecute, a partir de señales como datos estructurados de productos, patrones de URL y elementos de página como un campo de cantidad, una cuadrícula de productos o filtros. Reconstruye cada uno como una página que contiene únicamente el SKU del producto o la ruta de la categoría en un bloque comercial y el contenido circundante, como titulares y promociones, en bloques estándar. Los datos del producto no se importan: el bloque de comercio los carga desde el catálogo cada vez que un visitante abre la página. El agente migra otras páginas con el flujo de trabajo estándar.
El complemento no escribe los bloques de comercio. Utiliza los bloques de productos y listados que el proyecto ya tiene y, de lo contrario, espera los bloques product-details y product-list-page de la plantilla de tienda de comercio. Inicie el proyecto desde esa plantilla y conecte la tienda al catálogo para que las páginas importadas muestren los productos cuando los compruebe. El complemento en sí no necesita licencia, pero los componentes desplegables de la tienda requieren una licencia de Adobe Commerce as a Cloud Service o Adobe Commerce Optimizer. Adobe Commerce Optimizer también puede proporcionar el catálogo cuando otra plataforma de comercio gestione el carro de compras, el cierre de compra y los pedidos. Consulte Opciones de servidor.
Para otra plataforma de comercio sin Adobe Commerce Optimizer, el complemento no se aplica. El agente crea bloques de productos y listados que cargan sus datos desde la API de la plataforma, trabajando desde la documentación de la plataforma como se describe en Trabajar más allá de Edge Delivery Services.
El complemento funciona con contenido basado en documentos. Para los proyectos que usan Experience Manager authoring, el agente usa la migración estándar, que importa lo que muestra cada página de producto en ese momento. Decida con su equipo cómo se conectan esas páginas al catálogo.
Validar y enviar validation
Utilice los comandos de pelusa y prueba declarados del proyecto, además de las comprobaciones del explorador del contenido real. Pida al agente que informe de los comandos y resultados, no simplemente de que ha probado.
Marque:
- Todas las variantes afectadas y los casos extremos de contenido.
- Diseño para escritorio/móvil, contenido largo y comportamiento de imagen.
- Acceso mediante teclado, enfoque, semántica, etiquetas y orden de lectura.
- Interacciones e integraciones existentes.
- Cuando cambian los modelos o el contenido, los autores pueden editar, guardar y volver a abrir el contenido en su editor y previsualizarlo correctamente.
- Comprobaciones de rendimiento relevantes y sin nuevos errores en el explorador.
Si una comprobación falla, mantenga el ejemplo que falla y corrija la capa más pequeña afectada. Distingue los problemas de la rama de código/vista previa obsoletos de los errores de modelo o implementación. Vuelva a ejecutar la comprobación de errores y las regresiones relevantes.
Revise la comparación de diferencias, almacene en zona intermedia los archivos deseados y inserte la directiva del repositorio. Cargar contenido de prueba o producción solo cuando está autorizado; una inserción de código no la guarda. Una vez combinado en main, el código de bloque se aplica a todas las páginas del sitio activo que usa el bloque; consulte Cómo se activan los cambios.
Para la recuperación, revierta el código a través de Git y restaure por separado el contenido remoto modificado. Mantenga ejemplos antiguos compatibles hasta que se acepte cualquier migración de contenido requerida.
Use la transferencia de proyecto para conservar los archivos modificados, modelos, ejemplos, resultados de validación, riesgos restantes y el método de recuperación de la siguiente persona o agente.