Usar lógica condicional para los campos de Product Add-Ons

La lógica condicional cambia si un campo de Product Add-On está visible o disponible según los valores introducidos en otros campos del mismo grupo o definición local del producto. Úsala para mostrar preguntas de seguimiento, habilitar una mejora de pago solo después de una selección válida, u ocultar campos que no correspondan.

Antes de empezar

• Crea los campos de origen y de destino en el mismo grupo de Product Add-Ons o definición local del producto.
• Asigna etiquetas claras a las opciones de elección para que el editor de reglas sea fácil de revisar.
• Guarda un borrador y usa la vista previa de impacto antes de publicar un cambio en un grupo compartido.
• Una condición no puede leer un campo de otro grupo. Esto mantiene cada definición portable y su coste de evaluación acotado.

Crear una regla

1. Abre Products → Product Add-Ons → Groups y edita un grupo, o edita un producto y abre Product data → Add-Ons.
2. Abre el campo que debe cambiar y localiza Conditional logic.
3. Selecciona Enable conditional logic.
4. Elige un Effect:
   • Show when rules match oculta el destino hasta que las reglas coinciden.
   • Hide when rules match oculta el destino mientras las reglas coinciden.
   • Enable when rules match mantiene el destino visible pero no disponible hasta que las reglas coinciden.
   • Disable when rules match mantiene el destino visible pero lo hace no disponible mientras las reglas coinciden.
5. Elige si All rules must match (AND) o Any rule may match (OR).
6. Selecciona Add rule y elige el campo de origen, el operador y el valor esperado. Los campos de elección muestran las etiquetas de sus opciones mientras almacenan identidades estables.
7. Elige la Inactive value policy. Preserve conserva el valor del navegador para que pueda volver durante la sesión actual del formulario; Clear lo elimina en cuanto el campo queda inactivo.
8. Guarda el borrador, revisa el impacto y publícalo cuando esté listo.

El editor rechaza las autorreferencias, las referencias a encabezados, los campos u opciones que faltan, las dependencias circulares y las cadenas que superan la profundidad admitida. Si se eliminó un campo u opción referenciado, el editor marca la referencia rota en lugar de vincular silenciosamente otro elemento con la misma etiqueta.

Entender los valores inactivos

Un campo inactivo nunca es obligatorio, nunca añade un precio y no se almacena en el carrito ni en la instantánea del pedido. Esta regla del servidor se aplica incluso si un visitante modifica el JavaScript de la página o envía el campo inactivo manualmente.

La política Preserve solo controla el formulario actual del navegador. Es útil cuando un comprador cambia brevemente una respuesta anterior y luego la restaura. No persiste el valor inactivo en WooCommerce. Clear es preferible cuando conservar el valor anterior del navegador podría confundir al comprador.

Los pedidos existentes conservan sus instantáneas históricas inmutables hasta que un usuario autorizado edita explícitamente la línea. Editar o repetir una compra utiliza la definición publicada actual y vuelve a evaluar sus condiciones.

Operadores y valores

El editor de reglas solo admite comparaciones explícitas; no ejecuta fórmulas ni código personalizado.

Los campos de archivo solo admiten Is empty y Is not empty. Los encabezados se pueden mostrar u ocultar, pero no se pueden habilitar, deshabilitar ni usar como origen.

Límites y rendimiento

Cada campo acepta hasta 10 reglas, cada definición acepta hasta 100 reglas y una cadena de dependencias puede tener hasta 8 niveles de profundidad por defecto. El filtro público de límites operativos puede reducir o aumentar estos valores dentro de techos de seguridad fijos. POM compila la definición en un orden de evaluación topológico cuando se prepara el modelo público, y luego vuelve a evaluar solo esa definición; no busca en productos, grupos ni en el catálogo mientras un comprador cambia un valor.

La respuesta REST del producto POM y la extensión Product Add-Ons de la WooCommerce Store API exponen la versión 2 del esquema. Cada campo contiene su condition versionado, y cada contexto contiene conditional_logic.evaluation_order, dependents, max_depth y rule_count. Por lo tanto, los clientes headless pueden reproducir la misma interfaz determinista, pero el servidor sigue siendo la autoridad para la validación y el precio.

Verificar el resultado

1. Prueba con un valor que no coincida y otro que sí en un producto simple.
2. Confirma que un campo obligatorio oculto no impide Añadir al carrito.
3. Confirma que un campo obligatorio activo sí impide Añadir al carrito hasta completarlo.
4. Asigna un precio al campo de destino y verifica que aparece solo mientras el destino está activo.
5. Repite con una variación y en un flujo de Cart o Checkout Block.
6. Cambia el idioma y confirma que las etiquetas traducidas cambian mientras la regla sigue a las mismas identidades de campo y opción.
7. Si se usa la edición de líneas de pedido, abre WooCommerce → Orders, edita los add-ons y confirma que los mismos campos quedan visibles o no disponibles.

Solución de problemas

• Si al guardar se informa de un ciclo de dependencias, elimina una regla de la cadena circular. Reordenar los campos no elimina un ciclo.
• Si una regla informa de una referencia que falta, selecciona un campo u opción existente. POM nunca vuelve a enlazar por etiqueta.
• Si un campo permanece inactivo, comprueba todas las reglas AND y recuerda que un origen inactivo aporta un valor vacío a las reglas posteriores.
• Si una interfaz headless personalizada muestra un estado diferente, compara su versión de esquema y su orden de evaluación con la respuesta actual del producto, y confía en el rechazo del servidor en lugar de en un precio calculado por el cliente.

Relacionado: Crear grupos y opciones reutilizables, Campos y precios de la tienda y Store API y Blocks.