sg_forms para TYPO3

Tres sistemas de formularios en TYPO3 generan más confusión que oferta

Los proyectos TYPO3 se encuentran ante un lujo poco habitual a la hora de implementar formularios: existen tres opciones serias. El Form Framework nativo de TYPO3 (ext:form), powermail de in2code y sg_forms de SGalinski. Cada solución tiene sus propias fortalezas y sus propios límites. sg_forms se posiciona como un punto intermedio: más ligero que powermail, pero con mayor comodidad en el backend que ext:form. La extensión procede del proveedor TYPO3 SGalinski y se usa activamente en sus proyectos con clientes.

Quien ya utiliza otras extensiones de SGalinski (sgalinski_base, sg_cookie_optin) encuentra en sg_forms una solución que encaja sin fricciones en el ecosistema SGalinski.

Los escenarios típicos son formularios de contacto, peticiones y formularios de candidatura sencillos

El escenario estándar es el formulario de contacto en un sitio web corporativo. Nombre, correo electrónico, asunto, mensaje, casilla de RGPD, enviar. sg_forms entrega este setup como plantilla preconfigurada que los redactores pueden activar y ajustar desde el backend. Se pueden añadir, eliminar y reordenar campos, marcar campos obligatorios y definir validaciones. El correo electrónico llega a una o varias direcciones de destinatarios configurables.

Un segundo escenario son los formularios de solicitud multipágina. Un taller de reformas pregunta en la página 1 los datos de contacto, en la página 2 el tipo de servicio (desplegable) y en la página 3 fotos del objeto (carga de archivos). sg_forms soporta formularios multipaso con indicador de progreso y navegación hacia atrás. Los datos se guardan tras el envío como correo electrónico y, opcionalmente, como registro en la base de datos.

Tercer escenario: formularios de candidatura sencillos. Una pyme con tres vacantes no necesita un sistema de gestión de candidatos, pero sí un formulario que acepte currículum y carta de presentación como PDF y los remita al departamento de recursos humanos. sg_forms ofrece para ello la carga de archivos con validación de tipo y tamaño, combinada con un correo de confirmación al candidato.

La arquitectura técnica se basa en Extbase con definición de formularios en YAML

sg_forms registra un plugin Extbase que renderiza formularios a partir de una configuración. La definición del formulario se crea desde el backend mediante una interfaz gráfica o, alternativamente, se define como archivo YAML. Cada campo tiene un tipo (texto, correo, área de texto, selector, radio, casilla, archivo, oculto), reglas de validación y condiciones opcionales.

La arquitectura de finalizadores sigue el mismo patrón que powermail: tras el envío se ejecutan acciones sucesivas. Los finalizadores estándar son envío de correo, guardado en base de datos y redirección a una página de agradecimiento. Los finalizadores personalizados se implementan como clases PHP, por ejemplo para integraciones CRM o llamadas a webhooks.

El renderizado en el frontend se realiza mediante plantillas Fluid que pueden sobrescribirse por SiteSet o TypoScript. La extensión incluye una plantilla por defecto que funciona sin ajustes, aunque para sitios en producción suele adaptarse a la identidad corporativa. La protección anti-spam está disponible mediante campos honeypot e integración opcional de CAPTCHA.

Los problemas habituales afectan a la delimitación frente a powermail y a la licencia de SGalinski

La pregunta más frecuente es: ¿sg_forms o powermail? La respuesta depende del tamaño del proyecto. powermail tiene la comunidad más grande, más documentación, más finalizadores de terceros y una paleta de funciones más amplia (exportación a PDF, lógica multipaso de cualquier complejidad). sg_forms es más ligero, tiene menos sobrecarga y es el estándar en proyectos SGalinski. Para la mayoría de sitios web corporativos, powermail es la opción más segura. Para clientes de SGalinski que ya están dentro del ecosistema, sg_forms es la más coherente.

Segundo tema: la licencia. sg_forms no está disponible como extensión gratuita en el TER (TYPO3 Extension Repository), sino que se entrega a través de proyectos de SGalinski. Esto significa que los equipos que quieran usar la extensión sin una relación con SGalinski deben aclarar directamente con SGalinski su disponibilidad y las condiciones de licencia.

Tercer problema: la migración. Quien cambia de powermail a sg_forms (o al revés) tiene que recrear todas las definiciones de formulario existentes, porque las estructuras de datos son incompatibles. Las entradas de formulario almacenadas en la base de datos no pueden migrarse automáticamente.

TYPO3 v12 está soportado, v13 sigue el ciclo de lanzamientos de SGalinski

SGalinski mantiene sg_forms en su propio ciclo de lanzamientos, acoplado a las versiones LTS de TYPO3. TYPO3 v12 está soportado activamente. Para v13 cabe esperar una actualización en cuanto SGalinski actualice su propia suite de extensiones. Gosign recomienda, a la hora de elegir sistema de formularios, sopesar el mantenimiento a largo plazo y el tamaño de la comunidad como factores de decisión: powermail, con más de 500.000 instalaciones, tiene una base más amplia que sg_forms, lo que en los upgrades de TYPO3 se traduce en menores tiempos de espera hasta disponer de versiones compatibles.