La raz\u00f3n m\u00e1s habitual que da la gente para no actualizar los plugins de WordPress es el miedo. Miedo a que una actualizaci\u00f3n rompa el sitio, a que el checkout deje de funcionar, a que el formulario de contacto falle en silencio, a que alguna integraci\u00f3n a medida se venga abajo. El miedo es razonable. Las actualizaciones de plugins rompen cosas de vez en cuando. La respuesta no es salt\u00e1rselas. La respuesta es actualizar de una forma que contenga el riesgo.<\/p>\n\n\n\n
Este art\u00edculo repasa la rutina que usamos en cada sitio de WordPress que gestionamos. No es ex\u00f3tica y no requiere herramientas sofisticadas. Requiere la disciplina de hacer los pasos en el orden correcto, siempre.<\/p>\n\n\n\n
Antes de cualquier actualizaci\u00f3n de plugins, haz una copia de seguridad completa. No solo la base de datos, no solo los archivos. Ambos, juntos, con la versi\u00f3n de WordPress y la lista de plugins registradas. La copia debe estar en alg\u00fan lugar externo, no solo en el mismo servidor que est\u00e1s a punto de tocar. Y debe ser la copia m\u00e1s reciente que tengas, no la de anoche.<\/p>\n\n\n\n
Si tu plugin de copias puede generar un archivo completo con un clic, hazlo ahora. Si tu hosting ofrece snapshots bajo demanda, dispara uno. Los cinco minutos que esto lleva son la diferencia entre una reversi\u00f3n de quince minutos si algo se rompe y una reconstrucci\u00f3n de varias horas.<\/p>\n\n\n\n
Todo plugin de confianza publica un changelog con cada versi\u00f3n. \u00c1brelo antes de actualizar. Busca cambios que rompan compatibilidad, funciones obsoletas, saltos de versi\u00f3n mayor y cambios en el esquema de la base de datos. Un plugin que pasa de 4.x a 5.0 merece m\u00e1s precauci\u00f3n que uno que pasa de 4.4.1 a 4.4.2.<\/p>\n\n\n\n
Si el changelog menciona alguna de las funciones de las que dependes, planifica en consecuencia. Si el changelog falta o es vago, eso ya es una se\u00f1al de alarma sobre la calidad de mantenimiento del plugin.<\/p>\n\n\n\n
Para sitios cr\u00edticos de negocio, cada versi\u00f3n mayor de un plugin deber\u00eda probarse en una copia de staging antes de aplicarla a producci\u00f3n. Un entorno de staging no es m\u00e1s que un clon actual de tu sitio en producci\u00f3n. La mayor\u00eda de los buenos hostings de WordPress incluyen staging con un clic en sus planes. Si el tuyo no, usa un plugin como WP Staging o pide a tu desarrollador que levante uno.<\/p>\n\n\n\n
Aplica la actualizaci\u00f3n en staging. Recorre las rutas clave. P\u00e1gina de inicio, una p\u00e1gina de categor\u00eda, una p\u00e1gina de producto, el formulario de contacto, el checkout si lo hay, el panel de administraci\u00f3n, el maquetador si usas uno. Si algo se ve mal, lo descubres sin afectar a ning\u00fan visitante real.<\/p>\n\n\n\n
Para peque\u00f1as actualizaciones de parche en plugins menores, el staging es excesivo. Usa el criterio. Todo lo que toque el checkout, la base de datos, el editor o una dependencia central merece el tratamiento de staging.<\/p>\n\n\n\n
El error m\u00e1s com\u00fan que vemos es pulsar \u00abactualizar\u00bb para treinta plugins de golpe y descubrir despu\u00e9s que el sitio est\u00e1 roto sin saber qu\u00e9 plugin lo caus\u00f3. Rastrear un problema entre una pila de actualizaciones simult\u00e1neas es doloroso.<\/p>\n\n\n\n
Actualiza en lotes peque\u00f1os. De tres a cinco plugins a la vez es un tama\u00f1o razonable. Aplica, haz una prueba r\u00e1pida, contin\u00faa. Si algo se rompe, tienes un conjunto reducido de sospechosos que investigar y tu reversi\u00f3n tiene un alcance claro.<\/p>\n\n\n\n
Una prueba r\u00e1pida (smoke test) es un recorrido veloz por las partes del sitio que m\u00e1s importan. La p\u00e1gina de inicio carga. La cabecera y el pie se renderizan bien. La navegaci\u00f3n principal funciona. Una p\u00e1gina interior representativa carga. El formulario de contacto env\u00eda. El carrito a\u00f1ade y quita art\u00edculos. El panel de administraci\u00f3n se abre. Los registros no muestran errores nuevos.<\/p>\n\n\n\n
Mant\u00e9n una prueba r\u00e1pida escrita para cada sitio que gestiones. Cinco minutos por lote son un seguro barato.<\/p>\n\n\n\n
Cuando una actualizaci\u00f3n rompe algo y no puedes arreglarlo r\u00e1pido, lo correcto es revertir. El plugin que acabas de actualizar ten\u00eda una versi\u00f3n anterior. La mayor\u00eda de los marketplaces de plugins permiten descargar versiones anteriores. Algunos sitios de WordPress tienen instalado un plugin como WP Rollback justo para esto. Algunos hostings te permiten restaurar un \u00fanico plugin desde un snapshot reciente.<\/p>\n\n\n\n
Sea cual sea la v\u00eda que uses, con\u00f3cela antes de empezar. No intentes averiguar el proceso de reversi\u00f3n durante el incidente.<\/p>\n\n\n\n
Incluso con todo lo anterior, aplicar actualizaciones en tu hora punta es un riesgo innecesario. La mayor\u00eda de los negocios australianos tienen una ventana clara de bajo tr\u00e1fico, normalmente a \u00faltima hora de la noche o muy temprano por la ma\u00f1ana. Programa las actualizaciones de rutina en esa ventana. Si operas un ecommerce internacional, elige el periodo realmente m\u00e1s bajo para tu audiencia.<\/p>\n\n\n\n
Ese es tambi\u00e9n el momento de ejecutar migraciones de base de datos, cambios de tema o cualquier otro mantenimiento m\u00e1s pesado. Cuanto menor sea la audiencia que vea un problema temporal, mejor.<\/p>\n\n\n\n
Si un plugin concreto rompe el sitio cada vez que lo actualizas, eso es informaci\u00f3n. O el plugin es fr\u00e1gil, o su proceso de actualizaci\u00f3n es descuidado, o tu personalizaci\u00f3n est\u00e1 entrando en conflicto con \u00e9l. An\u00f3talo. Prueba las actualizaciones de ese plugin con especial cuidado cada vez. Si el patr\u00f3n contin\u00faa, plant\u00e9ate reemplazarlo.<\/p>\n\n\n\n
A la inversa, si un plugin se ha actualizado limpiamente cincuenta veces seguidas, puedes ser menos precavido con \u00e9l. El historial es una se\u00f1al \u00fatil.<\/p>\n\n\n\n
Lo mejor que puedes hacer para que las actualizaciones de plugins sean seguras es no modificar nunca los archivos de los plugins directamente. Cada personalizaci\u00f3n deber\u00eda vivir en un tema hijo, en un plugin espec\u00edfico del sitio o en un gestor de fragmentos de c\u00f3digo. As\u00ed, cuando el plugin se actualice, tus cambios sobrevivir\u00e1n intactos. El n\u00famero de veces que hemos visto una edici\u00f3n a medida borrada por una actualizaci\u00f3n rutinaria es inc\u00f3modamente alto.<\/p>\n\n\n\n
Usa los hooks y filtros del plugin. Si un plugin no ofrece un hook para lo que necesitas, p\u00eddeselo al desarrollador o usa un plugin m\u00e1s flexible. Editar los archivos centrales de un plugin es un atajo a corto plazo con un coste a largo plazo.<\/p>\n\n\n\n