Actualizar WordPress, el tema y los plugins el mismo martes, en la tienda, a las 11 de la mañana, es cómo se arma el ticket de «todo en blanco». El núcleo, un page builder y WooCommerce no se prueban en el cliente. El orden que menos duele: copia → clon → actualizar ahí → producción. Si algo falla, restauras. No «desinstalas a ver».

El escenario es un sitio elástico con cPanel, JetBackup y Softaculous. PHP tiene que aguantar la versión a la que subes: versión de PHP y el por qué actualizar PHP.

Qué vas a tener al terminar

Producción en la misma versión que el staging ya probó: escritorio, un formulario y, si hay tienda, un checkout de prueba. Una fecha de JetBackup de antes de tocar producción.

1. Copia de hoy

JetBackup: full account o, como mínimo, Home Directory más la base. Si el plan trae copias rotativas, igual dispara una tuya ahora. Un restore de «ayer» no sirve si llevas tres horas editando páginas.

2. Staging

Clona a un subdominio. Actualiza allá. El subdominio protegido, sin pasarela real, sin indexar. Si el clon no es posible (instalación a mano, disco justo), al menos JetBackup y una ventana de mantenimiento corta; no es lo mismo, pero es menos ciego que pulsar «actualizar todo».

3. Orden en el staging

  1. Mira el registro de PHP. Si vas a subir el núcleo a una rama que pide 8.1 y sigues en 7.4, primero PHP en un momento controlado, o elige no subir el núcleo todavía.
  2. Plugins: los de seguridad y los que el propio WordPress marca como incompatibles, uno a uno. Recarga el home y /wp-admin.
  3. Temas: el activo y el hijo. Un child con functions.php viejo es la pantalla blanca clásica.
  4. Núcleo de WordPress.
  5. Traducciones.

Si un plugin no tiene versión para ese núcleo, no lo actualices «a ver». Déjalo, busca reemplazo en el clon, o no subas el núcleo.

Autoactualizaciones: en una tienda, desactiva las del núcleo y de WooCommerce si quieres el control. Un parche menor de seguridad del núcleo, en un blog, puede quedarse automático. En checkout, tú decides el día.

4. Qué probar en el clon (no solo el home)

  • Login, una entrada, una página del constructor.
  • Formulario de contacto (correo de verdad a una bandeja tuya).
  • WooCommerce: añadir al carrito, checkout hasta el final en sandbox. La caché no debe mezclar carritos: LiteSpeed Cache.
  • Cron: un pedido o una suscripción que dependa de WP-Cron. Si en producción tienes cron de cPanel, el clon no debe disparar los mismos correos a clientes: tareas cron y WP-Cron.

5. Producción

Cuando el clon está bien: JetBackup otra vez (sí, otra). Luego en producción el mismo orden, o replica los zips que ya viste que funcionan. Vacía caché: vaciar la caché.

Si producción queda en 500 o en error crítico: no sigas actualizando. Restaura JetBackup a la copia de este apartado. Si el administrador no abre, desactiva plugins por FTP como en el error 500. Después, ticket con «restauré, el fallo se reproduce en staging» si aún tienes el clon roto para enseñarlo.

6. El 500 de después

Un plugin de caché, un ionCube, un mu-plugin en wp-content/mu-plugins que no sale en la lista: la receta está en error 500 y en error crítico. Permisos y 403: error 403.

Si no sale

Restaura primero si el sitio está caído. Luego ticket de soporte técnico: dominio, si ya restauraste, qué se actualizó (núcleo, lista de plugins), PHP actual. No pidas «actualícenme todo» sin backup: el clic es tuyo, la copia también. Guía del formulario: cómo crear un ticket.

Cloud Web Hosting · JetBackup · Ticket