El plugin werun.Toolkit para WordPress es un producto propio y este sitio no tenía ningún artículo sobre él. Este post es el complemento de notas de versión para ingenieros: cómo está organizado el plugin, cómo documentamos módulos y correcciones, cómo leer sus afirmaciones de compatibilidad y cómo actualizarlo sin poner en riesgo producción.
Una decisión de entrada. No publicamos nombres de módulos, números de versión ni fechas de lanzamiento en un post. Un post queda desactualizado al día siguiente de salir, y un changelog desactualizado es peor que no tener ninguno. La descripción vigente está en la página de producto de werun.Toolkit, y cada versión incluye su propio changelog.
Lo que encuentras aquí es el método: cómo leer una entrada, qué puede romper cada área de un changelog y un procedimiento que empieza en staging y sirve para este plugin y para cualquier otro.
Puntos clave
- werun.Toolkit es un plugin modular de WordPress creado por werun.dev para equipos que mantienen sitios WordPress y WooCommerce.
- Los nombres de módulos, versiones y fechas se publican en el changelog de cada versión y en la página de producto, nunca copiados en un post que se quedará obsoleto.
- La compatibilidad es un rango probado, así que confírmala con tus propias versiones de WordPress, PHP y WooCommerce en staging.
- Toda actualización, de este plugin o de cualquier otro, pasa por copia de seguridad, revisión del changelog y staging antes de llegar a producción.
Qué es el plugin werun.Toolkit para WordPress
werun.Toolkit es un plugin de WordPress que construimos y mantenemos en werun.dev. Está organizado en módulos y pensado para equipos que prefieren operar un único código mantenido antes que una pila de plugins de propósito único.
Un plugin modular, no un paquete de funciones sueltas
Un módulo es una unidad con una tarea definida, sus propias entradas en el changelog y su propia huella en tu sitio: hooks, opciones, pantallas de administración o rutas REST. Ese límite es lo que hace legible una versión. Puedes saber qué parte del plugin cambió y decidir si te afecta.
La razón para consolidar es operativa. Cada plugin extra es otro proveedor, otro ritmo de actualizaciones y otro lugar donde puede haber un conflicto. Ya tratamos ese equilibrio en el problema de los plugins: cómo el ecosistema de WordPress crea potencia y complejidad a la vez.
Para quién está pensado
Escribimos para CTOs, ingenieros y responsables de WordPress que responden por la disponibilidad además de por las funcionalidades.
- Equipos que mantienen varios sitios WordPress y quieren leer un solo changelog en lugar de muchos.
- Tiendas online en WooCommerce, donde una actualización tiene que ser segura en el checkout.
- Agencias que entregan sitios a clientes y necesitan explicar qué cambió.
No es la herramienta adecuada si necesitas una sola función concreta y nada más. Un plugin de propósito único, o un plugin de WordPress a medida, llevará menos código.
Cómo documentamos los módulos de werun.Toolkit
Cada entrada de módulo responde las mismas cinco preguntas. Las escribimos para quien decide si actualizar un viernes por la tarde, no para quien lee texto de marketing.
| Campo | Qué te dice | Por qué lo necesitan los ingenieros |
|---|---|---|
| Qué hace | La tarea del módulo en una frase | Alcance: es una función que necesitas |
| Caso de uso | Un escenario breve y concreto | Encaje: reemplaza algo que ya usas |
| Superficie tocada | Hooks, opciones, rutas REST, pantallas de administración | Riesgo: qué podría chocar con tu código |
| Introducido en | La versión que lo añadió | Registro de auditoría para tu propio changelog |
| Cambios incompatibles | Qué puede romper una actualización | El motivo para leer antes de actualizar |
Seguimos la estructura de Keep a Changelog: versiones en orden cronológico inverso, fechas ISO y entradas agrupadas en Added, Changed, Deprecated, Removed, Fixed y Security. Una entrada tiene este aspecto. Los marcadores son deliberados: es el formato, no una versión real.
## [x.y.z] - YYYY-MM-DD
### Added
- Module: <module name>. What it does in one sentence. Hooks and options it registers.
### Changed
- Area: what changed and what it can affect.
### Fixed
- Area: the bug and the symptom you would have seen.
### Security
- What was addressed and whether you should update immediately.Fuente de verdad
El changelog que acompaña a cada versión y la página de producto son el registro oficial de nombres de módulos, versiones y fechas. Si este post y un changelog se contradicen, el changelog tiene razón.
Elegir qué módulos activar
Sea cual sea lo que permita la pantalla de ajustes en la versión que usas, el objetivo es la menor superficie de código que haga el trabajo. Los interruptores por módulo y sus valores por defecto se describen en los ajustes del plugin y en las notas de versión, así que confírmalos ahí.
Un orden práctico para un sitio que ya tiene plugins instalados:
- Haz una lista de las tareas que cubren tus plugins actuales: formularios, redirecciones, ayudas de SEO, bloques personalizados.
- Relaciona cada tarea con la descripción de un módulo y marca los duplicados.
- Activa un módulo cada vez en staging y elimina el plugin que sustituye solo cuando el flujo esté probado.
Mejoras y correcciones por área
Agrupamos las entradas del changelog por el área del sitio a la que afectan, para que busques primero tu stack. Para cada área, esto es lo que conviene mirar en una entrada.
Administración y ajustes
Busca opciones renombradas, valores por defecto modificados y nuevos requisitos de capacidades. Una opción renombrada es una migración de datos, y un valor por defecto distinto puede cambiar el comportamiento de un sitio que no tocaste. Si una versión cambia quién puede acceder a una pantalla de ajustes, revisa los roles de editor y de gestor de tienda.
Rendimiento y carga
Busca cambios en los scripts y estilos que se cargan en el front end, consultas que se ejecutan en cada petición y opciones con autoload. No te fíes de una nota que diga "más rápido". Mide LCP e INP antes y después en una plantilla que use el plugin. Los umbrales buenos de Google son 2,5 segundos para LCP y 200 milisegundos para INP en el percentil 75, según documenta web.dev.
Seguridad y manejo de datos
Las entradas etiquetadas como Security se leen primero. Mira qué se corrigió (sanitización de entradas, escape de salidas, nonces, comprobaciones de capacidades) y si se puede explotar sin iniciar sesión. El Plugin Handbook de WordPress documenta esas prácticas y es la referencia con la que escribimos. Comprueba también si una versión cambia qué datos se guardan o se envían a terceros.
Experiencia de desarrollo y hooks
Si tu tema o un mu-plugin extiende el plugin mediante actions y filters, busca en tu código cada hook mencionado en Changed, Deprecated o Removed. Un hook deprecated sigue funcionando hasta la versión que lo elimina.
# Set HOOK to a hook named in the changelog's Changed, Deprecated or Removed entries
HOOK="your_hook_name"
grep -rn --include=*.php "$HOOK" wp-content/themes wp-content/mu-plugins wp-content/pluginsLas entradas que añaden hooks son la buena noticia. Son la forma soportada de personalizar el comportamiento sin editar los archivos del plugin.
Compatibilidad con WordPress y WooCommerce
La compatibilidad en un changelog es una declaración de lo que se probó, no una garantía sobre tu sitio. Indicamos las versiones probadas en cada versión y tú las confirmas con tu propio stack.
Versiones probadas de WordPress y PHP
La cabecera del plugin declara hasta qué versión de WordPress se probó y la versión mínima de PHP que requiere. Lee ambas y compáralas con producción, no con tu máquina local. Una diferencia de versión menor de PHP entre staging y producción es una fuente habitual de sorpresas.
| Capa | Qué confirmar | Cómo comprobarlo |
|---|---|---|
| Core de WordPress | La versión está dentro del rango probado | wp core version |
| PHP | La versión cumple el requisito y coincide con producción | wp --info |
| WooCommerce | La versión está dentro del rango probado (solo tiendas) | wp plugin get woocommerce --field=version |
| Tema y otros plugins | Sin funciones duplicadas ni hooks que se solapen | Prueba de humo en staging |
Compatibilidad con WooCommerce
En una tienda, una actualización solo es segura si el checkout es seguro. Tras actualizar en staging, haz un pedido de prueba de principio a fin: añadir al carrito, envío, pago en el modo de prueba de la pasarela, email de confirmación y estado del pedido en el administrador. Comprueba también si la versión declara compatibilidad con el High-Performance Order Storage de WooCommerce, que importa para cualquier código que lea o escriba pedidos.
Nuevas integraciones
Una integración nueva es superficie nueva. Léela como peticiones salientes nuevas, credenciales nuevas y datos nuevos que salen de tu sitio. Mantén las claves de API fuera de la base de datos cuando puedas, en constantes en wp-config.php o en variables de entorno, y limita lo que cada clave puede hacer. Si necesitas una integración que el plugin no cubre, nuestro servicio de integraciones la construye sobre la API REST del otro sistema.
Cómo se entregan las actualizaciones de werun.Toolkit
Cuando un plugin registra una fuente de actualizaciones, WordPress muestra la actualización disponible en la pantalla de Plugins y a través de WP-CLI. Ambas te dan la oportunidad de parar antes de aplicarla. Aprovéchala.
Versionado y formato del changelog
Lee el número de versión junto a las entradas, no en lugar de ellas. Una versión con un salto pequeño y una entrada Changed en los ajustes merece una segunda mirada. Una versión con un salto grande y solo entradas Fixed suele tener menos riesgo del que sugiere el número.
Un changelog es un contrato con las personas que operan tu sitio: cada entrada debe decir qué cambió y qué puede romper.
werun.dev
Dónde leer las notas de versión
Lee el changelog antes de pulsar Actualizar, nunca después. La página de producto describe el plugin tal como está hoy, y el changelog de cada versión registra cómo llegó hasta ahí. Si gestionas sitios de clientes, copia las entradas relevantes en tu propio changelog para que quede constancia del motivo de cada actualización.
Cómo actualizar el plugin werun.Toolkit de WordPress con seguridad
El procedimiento siguiente no es específico de nuestro plugin. Es la forma que usamos para actualizar plugins en sitios bajo mantenimiento, y cabe en una tarde.
Copia de archivos y base de datos
Haz una copia completa y confirma que se puede restaurar.
Lee el changelog
Busca entradas Changed, Deprecated, Removed y Security.
Actualiza en staging
Usa una copia con las mismas versiones y datos que producción.
Ejecuta pruebas de humo
Prueba formularios, login y, en una tienda, un pedido de prueba completo.
Actualiza producción y vigila
Elige una ventana tranquila y revisa los logs durante la primera hora.
Antes de actualizar
Haz la preparación una vez y la actualización en sí se vuelve aburrida. Recorre esta lista antes de tocar nada.
- Copia de seguridad completa hecha y restauración probada
- Staging usa las mismas versiones de PHP y WordPress que producción
- Changelog leído en busca de cambios incompatibles y hooks deprecated
- Carpeta anterior del plugin copiada en un lugar seguro para el rollback
- Ventana de mantenimiento elegida para tiendas con mucho tráfico
Estos comandos exportan la base de datos y guardan una copia de la carpeta actual del plugin. El slug es un ejemplo, así que confirma el tuyo con wp plugin list.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp db export "pre-update-$(date +%F).sql"
cp -r "wp-content/plugins/$PLUGIN" "../$PLUGIN-previous"
wp plugin list --update=availableActualiza primero en staging
Staging debe coincidir con producción: mismas versiones de WordPress, PHP y WooCommerce, y una copia reciente de los datos. Actualiza ahí y ejecuta pruebas de humo en los flujos que generan ingresos o captan leads. Revisa el log de errores de PHP y la consola del navegador, además de lo que se ve en pantalla.
Cuando staging esté limpio, actualiza producción en una ventana de poco tráfico y mantén los logs abiertos.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp plugin update "$PLUGIN" --dry-run
wp plugin update "$PLUGIN"
wp plugin get "$PLUGIN" --field=versionCómo hacer rollback si algo falla
Decide el disparador del rollback antes de empezar: un checkout que falla, un error fatal o un formulario que deja de enviarse. Si se activa, restaura la carpeta del plugin que guardaste. Si la versión cambió datos almacenados, restaura también el volcado de la base de datos, porque una versión anterior puede no leer datos nuevos.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp plugin deactivate "$PLUGIN"
rm -rf "wp-content/plugins/$PLUGIN"
cp -r "../$PLUGIN-previous" "wp-content/plugins/$PLUGIN"
wp plugin activate "$PLUGIN"Qué viene después para el plugin
Compartimos elementos del roadmap cuando el equipo de producto los ha confirmado, y los etiquetamos como planificados, no como comprometidos. Este post no lista ninguno, porque una fecha en un post se convierte en una promesa que nadie puede actualizar.
Lo que sí queremos es feedback técnico. Si necesitas un módulo, una integración o un hook que falta, cuéntanoslo. Las peticiones que van más allá de un módulo se convierten en trabajo de plugin a medida, que tratamos en desarrollo de plugins de WordPress a medida.
Por dónde empezar con werun.Toolkit
Empieza por la página de producto de werun.Toolkit para ver la descripción actual del plugin, y después lee el changelog de la versión que vas a instalar. Aplica el procedimiento de staging descrito arriba antes de que nada llegue a producción.
Si quieres el plugin integrado, ampliado o mantenido dentro de un stack más amplio, consulta nuestro servicio de plataforma WordPress. Para un módulo a medida o un plugin hecho a la medida de tu caso, contacta con el equipo y cuéntanos el problema que necesitas resolver.
Preguntas frecuentes
¿Qué es el plugin werun.Toolkit para WordPress?
Es un plugin modular de WordPress creado y mantenido por werun.dev para equipos que gestionan sitios WordPress y WooCommerce. Su descripción vigente está en la página de producto de werun.Toolkit, y cada versión incluye su propio changelog.
¿werun.Toolkit es compatible con WooCommerce?
La compatibilidad se indica en cada versión como un rango de versiones probadas, así que revisa la versión de WooCommerce que figura en la que vas a instalar. Diga lo que diga, prueba un pedido completo en staging, porque la compatibilidad también depende de tu pasarela de pago, tu tema y otros plugins.
¿Cómo actualizar un plugin de WordPress sin romper el sitio?
Haz una copia de archivos y base de datos, lee el changelog y actualiza una copia de staging que coincida con producción. Prueba tus flujos clave, actualiza producción en una ventana tranquila y ten lista una copia de la versión anterior del plugin para el rollback.
¿Puedo desactivar los módulos de werun.Toolkit que no uso?
Los ajustes por módulo y sus valores por defecto están documentados en los ajustes del plugin y en las notas de versión de la que usas, así que consúltalos primero y prueba cualquier cambio en staging. El objetivo es el conjunto más pequeño de código activo que cubra tus casos de uso.
