Una actualización de WooCommerce puede poner a una tienda en un dilema: aceptar el nuevo email predeterminado y perder el diseño personalizado, o conservar la plantilla modificada anterior sin saber exactamente qué ha cambiado. Lo más práctico es partir de una referencia aprobada en Migma para el mensaje que se quiere transmitir y dejar que el desarrollador de la tienda adapte la plantilla de WooCommerce correspondiente. Una exportación de diseño no puede asumir ese mantenimiento de código por ti.
El objetivo real es contar con una plantilla actualizada que explique el pedido con claridad y mantenga la identidad visual de la tienda. Limpiar el aviso del panel, ver una captura impecable y confirmar que el correo llega a la bandeja de entrada son validaciones distintas. Esta guía plantea un proceso de aceptación común para equipos de marketing y desarrollo.
Publicado por Migma. La información sobre el producto se revisó el 19 de octubre de 2026. El flujo de trabajo que se describe a continuación es una recomendación editorial; no hace referencia a un instalador nativo de Migma para plantillas de WooCommerce.
Identifica qué plantilla está afectada realmente
Pide a quien gestione la tienda que entre en WooCommerce → Estado → Estado del sistema. Como indica la guía oficial sobre plantillas obsoletas, este informe detalla qué archivos han sido sobreescritos por el tema o tema hijo e identifica las versiones desactualizadas.
Apunta el archivo exacto y el aviso que muestra. Modificar una plantilla de correo no implica lo mismo que modificar la ficha de producto, aunque ambos casos aparezcan en el mismo informe. Anota también el tema activo, las extensiones de email que intervengan y la versión de WooCommerce en cuestión. Evita rehacer el diseño basándote únicamente en el texto de la alerta.
Comprueba quién mantiene ese archivo. En algunos casos, el proveedor del tema publicará una actualización; en otros, si se trata de un tema hijo a medida, el desarrollador tendrá que trasladar las modificaciones deliberadas sobre la base oficial actualizada. La propia documentación de WooCommerce contempla ambos escenarios. Sigue los pasos que correspondan según el origen del código en lugar de aplicar soluciones genéricas directamente en producción.
Guarda dos referencias antes de tocar nada
Conserva una copia de seguridad de la plantilla que está funcionando y guarda un correo real representativo ya entregado. El archivo de código recoge los detalles técnicos de la implementación; el email muestra la experiencia real del cliente. Ninguno sustituye al otro.
Prepara un resumen breve con los cambios aplicados a propósito: ubicación del logotipo, jerarquía de lectura, textos de atención al cliente, pie de página y bloques condicionales. Distingue esas decisiones de fallos accidentales heredados; que un diseño antiguo forzara un salto de línea no significa que deba mantenerse.
En Migma, asegúrate de tener una referencia visual aprobada del resultado esperado. Si el diseño original ya está allí, localiza el mensaje exacto. Si no, crea un borrador de revisión con los textos aprobados y los recursos autorizados. Plantea los datos del pedido como ejemplos claros para que nadie confunda un boceto visual con datos reales de una transacción.
Ajusta el código y el diseño por separado
El procedimiento oficial de WooCommerce recomienda localizar las plantillas obsoletas, crear copias de seguridad, partir de la versión predeterminada actual y volver a incorporar las personalizaciones necesarias. El equipo de desarrollo debe revisar las diferencias técnicas y actualizar el archivo siguiendo el flujo habitual de trabajo de la tienda.
No resuelvas la advertencia limitándote a cambiar el número de versión en la cabecera sin revisar el código. Lo importante es comprender e integrar los cambios reales. Del mismo modo, no reemplaces una plantilla PHP por un diseño HTML estático descargado dando por sentado que la tienda conservará los datos dinámicos, los hooks y la lógica condicional.
La documentación de exportación de Migma explica cómo descargar código HTML para utilizarlo en otras plataformas y revisar el resultado en su destino final. Utiliza ese HTML como punto de partida visual siempre que el desarrollador lo considere oportuno. La estructura de plantillas y extensiones de WooCommerce seguirá determinando cómo se insertan los datos del pedido en el mensaje.
Basa la validación en pedidos complejos
Una vista previa con datos perfectos no basta para dar por buena una plantilla. Conviene acordar unos cuantos casos representativos antes de empezar el desarrollo, centrándose en el propósito real de la notificación en lugar de intentar abarcar todas las funciones de la tienda en un solo correo.
| Caso de prueba | Qué debe revisar el equipo |
|---|---|
| Varios artículos con nombres largos | El texto de los productos sigue siendo legible y los importes totales se localizan con facilidad |
| Falta un dato opcional del cliente | No aparecen etiquetas vacías ni fórmulas de saludo extrañas |
| Descuentos y gastos de envío | El mensaje refleja los importes y cálculos reales de la tienda |
| Cambio de estado del pedido relevante | El encabezado y el siguiente paso explican la situación con precisión |
| Pantalla estrecha e imágenes bloqueadas | La información básica del pedido y el acceso a soporte siguen siendo comprensibles |
Estas situaciones sirven como guía de revisión, no como un registro formal de pruebas técnicas. No fuerces los datos reales de un pedido para que el diseño quede más limpio. Si una notificación no incluye determinado campo por defecto, descarta esa prueba en vez de asumir funciones que la plataforma no tiene.
Contrasta el resultado implementado con el diseño aprobado
Pasa Migma Email Preflight sobre el borrador de diseño para comprobar la maquetación, los enlaces, la redacción y los problemas habituales de entrega. Después, inspecciona el mensaje generado por WooCommerce mediante el protocolo de pruebas de tu equipo.
Empieza revisando el contenido: la finalidad del aviso, cómo se muestra el nombre del cliente, el número de pedido, los artículos, los totales y las vías de contacto con soporte. Pasa después a la parte visual: logotipo, márgenes, contraste, jerarquía tipográfica y legibilidad de los botones. Cierta variación decorativa puede ser asumible, pero cualquier discrepancia en las condiciones de pago o plazos de entrega debe resolverla el responsable correspondiente.
Comprueba los correos entregados en bandejas de entrada reales durante las pruebas. La vista previa del navegador no refleja cómo renderiza cada cliente de correo, y Preflight no puede garantizar la entregabilidad final en el buzón. Guarda constancia de la versión aprobada junto con la referencia de código que le corresponde.
Facilita la revisión de las próximas actualizaciones
Guarda el registro de personalizaciones junto con la documentación técnica de la plantilla. Deja claro quién es responsable del código, quién aprueba los textos para los clientes, dónde se encuentra la referencia en Migma y qué casos de prueba se validaron. Evita que el traspaso de información se limite a una captura de pantalla enviada por chat.
Si la nueva plantilla predeterminada de WooCommerce ya cubre las necesidades de la tienda mediante los ajustes nativos, valora si merece la pena mantener la modificación personalizada. Es una decisión técnica que corresponde al propietario de la tienda y al desarrollador, respaldada por los requisitos de diseño acordados.
Para rediseños de mayor alcance, consulta la guía de revisión de emails de pedido en WooCommerce. Para una actualización rutinaria, mantén un enfoque más acotado: concilia la plantilla modificada, preserva las decisiones de marca intencionadas y valida el mensaje definitivo que recibirá el cliente antes de publicarlo.
Preguntas frecuentes
¿Actualiza Migma automáticamente los overrides de WooCommerce?
No. No existe un flujo de actualización automática nativo para este caso. Utiliza Migma para definir la creatividad aprobada y entregar el HTML cuando proceda; el desarrollador de WooCommerce es quien gestiona la plantilla de la tienda y su lógica.
¿Basta con cambiar el número de versión de la plantilla?
No, eso no demuestra que se hayan revisado los cambios en el código. El desarrollador debe cotejar la plantilla actual con las personalizaciones deseadas y probar la notificación resultante.
¿Qué conviene guardar antes de actualizar una plantilla de email?
Guarda una copia de seguridad de la versión en producción, una muestra real del email entregado, un registro de las personalizaciones aplicadas adrede y la referencia creativa aprobada, anotando el responsable y la versión de cada elemento.
¿Es suficiente ver una vista previa correcta en el navegador para aprobar la actualización?
No. Conviene comprobar cómo se comportan los datos y condiciones de pedidos representativos en la notificación implementada y revisar el resultado entregado en bandejas de entrada reales mediante el proceso de pruebas habitual del equipo. El aspecto visual no garantiza que la lógica funcione bien.