Por qué los snippets de functions.php son una bomba de tiempo en tu WordPress
Pegar snippets en functions.php se rompe al cambiar de tema, no tiene historial, y un typo tira la web entera. Por qué pasa y qué hacer en su lugar.
Si tu web de WordPress tiene más de cinco snippets personalizados en functions.php, tienes una bomba de mantenimiento esperando a explotar. Las actualizaciones de tema, las migraciones a temas hijo y los traspasos entre developers son los momentos típicos de detonación. Aquí va por qué pasa y qué hacer en su lugar.
El ciclo de vida de un snippet típico
Buscas en Google "cómo redirigir el checkout de WooCommerce para usuarios no logueados" en 2022. El primer resultado tiene un snippet de 12 líneas. Lo pegas en el functions.php de tu tema hijo. Funciona. Pasas página.
Dos años después cambias de tema. El nuevo no incluye tu functions.php personalizado. La redirección se rompe. Los clientes llegan al checkout en estado roto durante dos días hasta que alguien lo nota. Vuelves a buscar el snippet. Lo pegas en el tema nuevo. Todo "bien" otra vez. Hasta la próxima.
Cada snippet en functions.php tiene este ciclo. Cada uno es una pequeña dependencia invisible entre tu tema y tu lógica de negocio. WordPress tiene una separación limpia entre contenido, presentación y funcionalidad — y pegar lógica de negocio en el tema rompe esa separación deliberadamente.
Cinco riesgos reales del enfoque functions.php
1. Cambiar de tema los borra. La causa más común de "la web se ha vuelto rara" tras un rediseño. El nuevo diseñador no sabe de tus snippets porque están enterrados en un tema viejo.
2. Sin historial de versiones. Cuando el snippet tiene un bug, no hay log de commits que te diga quién lo añadió, cuándo y por qué. ¿Esa meta query era para SEO o para una campaña puntual que terminó el trimestre pasado? No puedes saberlo.
3. Los errores tiran toda la web. Un typo en functions.php produce un fatal que rompe a la vez front y admin. Un typo en un plugin solo rompe ese plugin (y solo si está activo).
4. Los conflictos entre plugins son difíciles de depurar. WordPress te deja desactivar plugins de uno en uno para aislar conflictos. No hay equivalente para snippets: tienes que comentarlos a mano, guardar, refrescar y volver a poner.
5. No se reutilizan. Si tienes diez sitios de cliente que necesitan el mismo snippet de redirección, lo copy-pasteas en diez functions.php. El día que un cliente pide cambiar el comportamiento, tienes que rastrear las diez copias. La mayoría de agencias tiene al menos un snippet misteriosamente distinto en tres sitios porque alguien lo actualizó una vez y olvidó los otros siete.
La forma correcta: convierte cada snippet en un plugin
Cada snippet es una pequeña funcionalidad. La funcionalidad va en plugins. La regla mental es: si lo copiarías entre sitios, debería ser un plugin.
El motivo por el que esto era impráctico antes es que montar un plugin desde cero (boilerplate, hooks de activación, página de opciones si hace falta, internacionalización, uninstall) llevaba 20-30 minutos por snippet. Con la generación de plugins por IA en 2026, describes el comportamiento del snippet en dos frases y obtienes un plugin formal en dos minutos. El coste es 1-3 € de créditos por plugin, mucho menos que el tiempo que ibas a invertir.
Cómo se ve esto en la práctica
El snippet de redirección de 12 líneas del ejemplo se convierte en un plugin de 60 líneas (con ciclo de hook correcto, un toggle admin para desactivarlo sin desinstalar y un handler de uninstall que limpia sus opciones). La conversión lleva 2-4 minutos. El plugin pasa a vivir en /wp-content/plugins, sobrevive cambios de tema, tiene su propio repo en GitHub o ZIP en tu caja de herramientas, y se instala en todos los sitios cliente en segundos.
El camino de migración
Abre tu functions.php actual. Coge un snippet a la vez. Genera un plugin a partir de una descripción de un párrafo. Activa el nuevo plugin en staging. Si funciona, borra el snippet del functions.php. Repite hasta que tu functions.php solo contenga código de tema real (enqueue de fuentes, filtros de body class, registro de tamaños de imagen). En una web típica esto lleva una o dos horas en total y elimina toda una clase permanente de riesgo de tu operación.
La excepción: arreglos temporales
Si necesitas un snippet durante 24 horas para depurar algo, pégalo en functions.php. Bórralo al día siguiente. La regla contra los snippets es para los que llevan más de una semana ahí. El código temporal está bien — pero muy pocos snippets se van cuando su autor planeó retirarlos.