Mucha gente se lleva las manos a la cabeza cuando instala WordPress por primera vez: ¿Cómo es posible que el CMS más usado del mundo no permita crear un formulario de contacto sin instalar un plugin?
Es la eterna pregunta en podcast, eventos y foros de debate y una de las barreras de entrada para los neófitos. Sin embargo, no es un descuido. Es una decisión de diseño arquitectónico.
En este episodio de Un Billete a Chattanooga destripamos las razones por las que el core de WordPress se mantiene limpio de funcionalidades que muchos consideran básicas, centrándonos en el caso paradigmático de los formularios.
El desarrollo de WordPress se rige por un principio fundamental: el software debe funcionar de serie para la gran mayoría de los usuarios, sin abrumarlos con configuraciones innecesarias. Introducir un constructor de formularios nativo implicaría tomar cientos de decisiones por el usuario: ¿Cómo se guardan los datos? ¿Qué motor de envío se usa? ¿Cómo se gestiona el spam?
Si el core incluyera un sistema de formularios, tendría que ser lo suficientemente robusto para todos, lo que engordaría el código base para quienes no lo necesitan (por ejemplo, sitios que solo usan WordPress como API o para intranets cerradas).
Uno de los puntos técnicos más críticos es la infraestructura de envío. Por defecto, WordPress utiliza la función wp_mail(), que se apoya en phpmail. Esto es una pesadilla de entregabilidad:
- Spam: La mayoría de los correos enviados desde servidores web sin configurar acaban en la carpeta de correo no deseado.
- Seguridad: Gestionar entradas de usuario (inputs) directamente en el core requiere una auditoría constante para evitar inyecciones de código y vulnerabilidades XSS.
- Logs y base de datos: ¿Debería WordPress guardar los mensajes en la base de datos? Si lo hace, ¿cómo gestionamos el cumplimiento del RGPD de forma nativa para cada país?
Delegar esto en plugins permite que cada usuario elija su nivel de complejidad.
Con la llegada de la edición completa del sitio (FSE), el debate ha vuelto a la mesa. Ya existen bloques de formulario en patrones experimentales, pero siguen siendo estructuras visuales que requieren un backend para procesar la información.
En este episodio analizamos:
- La diferencia entre funcionalidad core y funcionalidad de plugin.
- Por qué el mantenimiento de un sistema de formularios es una carga que el equipo de seguridad de WordPress no quiere (ni debe) asumir.
Si alguna vez te has quejado de tener que instalar 20 plugins para que tu web funcione, este programa te dará la perspectiva técnica necesaria para entender por qué, a veces, menos es más.
El principio de un núcleo ligero
A primera vista puede parecer extraño que WordPress no incluya un formulario de contacto de manera nativa. Al fin y al cabo, casi cualquier web necesita una forma de que los usuarios puedan escribir. Sin embargo, esta ausencia responde a varias decisiones de diseño bastante deliberadas.
En primer lugar, WordPress sigue desde sus inicios el principio de mantener el núcleo lo más ligero posible. El core incluye solo las funcionalidades que prácticamente cualquier sitio necesita: crear contenidos, gestionarlos, publicarlos y administrarlos. Todo lo demás se deja fuera deliberadamente para evitar que el sistema se vuelva pesado o complejo de mantener.
Los formularios pueden ser muy diferentes
Además, los formularios no son una funcionalidad tan simple como parece. Bajo la etiqueta de “formulario” pueden esconderse necesidades muy distintas: desde un contacto básico hasta formularios de registro, encuestas, reservas, pagos o integraciones con CRM. Si WordPress incluyera uno en el núcleo, probablemente sería demasiado básico para muchos casos… o demasiado complejo para formar parte del core.
El papel del ecosistema de plugins
Por eso WordPress apuesta por su ecosistema de plugins. Existen decenas de soluciones especializadas —como Contact Form 7, Gravity Forms o WPForms— que permiten elegir el nivel de complejidad adecuado para cada proyecto. Este enfoque mantiene el núcleo más limpio y, al mismo tiempo, fomenta la innovación dentro de la comunidad.
Seguridad, spam y mantenimiento
También hay un factor importante de seguridad y mantenimiento. Los formularios implican envío de correos, validación de datos y protección contra spam. Gestionar todo eso dentro del core ampliaría la superficie de ataque y obligaría a WordPress a mantener continuamente sistemas antispam, validaciones y compatibilidades con múltiples configuraciones de servidor.
Una razón también histórica
Por último, hay una razón histórica. WordPress nació en 2003 como una herramienta de blogging, donde la interacción principal se producía a través de los comentarios en los artículos. Los formularios de contacto llegaron después como una necesidad habitual, y desde el principio se resolvieron mediante plugins.
En resumen, WordPress no tiene formularios nativos no porque sean poco importantes, sino porque su filosofía es otra: un núcleo pequeño, estable y universal, ampliado mediante plugins según las necesidades de cada sitio.
Si prefieres la versión en audio del programa:
Podcast: Reproducir en una nueva ventana | Descargar
Suscríbete: RSS
David Pérez dice:
Buenas Pablo,
Respecto a lo que comentas del Contributor, hay equipos que es difícil contribuir. En el equipo de Plugins, no podemos dar acceso a los que van a la WC a la zona de plugins por motivos sobrados relativos a seguridad, etc.
Hay algunos contributors que han sido más productivos y han contribuido incluso al Plugin Check Plugin.
Dicho esto, aún así creo que la labor que hacemos ayuda a que desarrolladores puedan subir sus plugins, que sean más seguros y que se puedan aprobar fácilmente. De hecho hubo varios que se animaron a publicar sus plugins. Creo que esto también es una forma de contribuir a WordPress.
Un abrazo y nos vemos!
12 de marzo de 2026 — 8:40 pm
Pablo Moratinos dice:
Y me parece perfecto, David. Pero para la mesa de plugins hace ya años (antes de que la llevarais vosotros) que se explicaba «que no se enseñaba a hacer plugins» porque eso no es contribuir a WP sino aprender a programar mejor.
Es como si en la mesa de soporte nos pusiéramos a resolver las dudas de los que están en el Contributor, en lugar de enseñarles a ayudar. O como si en la de WPtv enseñáramos a grabar vídeos, en lugar de explicar cómo es el proceso de moderación y subida.
Desde mi punto de vista el objetivo de la mesa de plugins debería ser el de enseñar a futuros voluntarios cómo es el trabajo del equipo de plugins, no el del desarrollador de plugins.
Desde siempre el foco del Contributor ha sido enseñar a contribuir, no enseñar WordPress. Al menos ese el mensaje que me han transmitido a mi. Aunque no quiere decir que todo el mundo lo tenga que ver igual, claro 🙂
La consecuencia, en cualquier caso, es que cada vez se contribuye menos en las WordCamps. Tristemente. Incluso cuando va mucha gente, se aporta poco.
Un abrazo grande, titán.
12 de marzo de 2026 — 11:05 pm