Genera un plugin de formularios con lógica condicional
La lógica condicional es donde los builders de formulario se ponen caros. Gravity, WPForms, Formidable la cobran, y sus motores de reglas son potentes pero a menudo más de lo que necesitas.
Si tu lógica es "si Q1 = Sí, mostrar Q3 y Q4", un plugin generado con un fichero de reglas pequeño es más simple, más rápido y valida en servidor para que un visitante motivado no pueda saltarse las reglas por DevTools.
¿Por qué generarlo en vez de instalar un plugin existente?
Gravity trae lógica condicional en el plan base (bien) pero las reglas viven en una UI que nadie audita. WPForms la mete en Pro (199€+/año). Formidable la bundlea. Ninguna valida server-side de forma estricta — la regla se aplica en navegador y el servidor solo comprueba presencia de campos.
Un plugin custom declara reglas en código o JSON. El front oculta/muestra para UX, el backend reevalúa cada regla antes de guardar. Si un visitante envía un campo que debía estar oculto, rechazamos con 422.
Hace el formulario a la vez más amable y más difícil de abusar. Útil para encuestas donde importa el camino, para cualificación de leads, para ruteo de contacto multi-rama.
Prompt de ejemplo
Este es el tipo de descripción que genera este plugin. Puedes partir de aquí y ajustar lo que necesites antes de generar.
Nombre del plugin: Acme Smart Form
Campos:
1. are_you_business (radio: yes/no) — requerido
2. company_name (text) — solo si are_you_business == yes
3. personal_use_case (textarea) — solo si no
4. email — siempre requerido
5. volume (select) — solo si yes AND company_name no vacío
Reglas como array JSON en una constante PHP.
Front: JS simple recorre reglas en onchange y toggle visibilidad.
Back: /wp-json/acme/v1/smart-form POST.
- Reevalúa reglas sobre POST.
- Campo que debía estar oculto con valor → 422.
- Required-when-visible ausente → 422 con errores por campo.
Errores inline bajo cada campo.
Guardar aceptados en wp_acme_smartform.Qué suele incluir el plugin generado
- Reglas declaradas como JSON en una constante PHP
- Evaluador compartido entre front y back
- Respuestas con errores por campo desde endpoint REST
- Toggle de visibilidad sin re-render
- Modo estricto: rechaza payloads imposibles
- Admin con envíos mostrando el camino tomado
Lenguaje de reglas tan rico como describas. Igualdad y booleanos cubren casi todo; si necesitas regex o matemáticas, inclúyelo en el prompt.
Preguntas frecuentes
¿Por qué reevaluar en servidor?
Porque un navegador puede mentir. Servidor estricto rechaza payloads donde un campo supuestamente oculto llega con valor — cierra un vector de gaming clásico en encuestas.
¿Las reglas pueden referenciar envíos previos?
Sí si el visitante está logueado. Describe la regla cross-envío y el plugin carga historial antes de evaluar.