Tecnología ·
Por

PHP 8.4: rendimiento y nuevas funciones para tus aplicaciones web

Qué trae PHP 8.4, cuánto gana de verdad en WordPress, qué deprecaciones pueden romper plugins y cómo actualizar en Hosting del Sur con MultiPHP.

PHP 8.4 salió el 21 de noviembre de 2024. No es un salto de marketing: trae features que cambian cómo se escribe código, limpia APIs viejas y mantiene el rendimiento en la línea de 8.3. Si tu sitio corre en hosting compartido o en un plan de Hosting del Sur, la pregunta práctica es otra: ¿conviene pasarlo ya, y con qué cuidados?

En este artículo repasamos las novedades reales del release, los números de benchmarks públicos, las deprecaciones que suelen romper plugins, el estado de WordPress a mediados de 2026 y un plan de upgrade usable.

Qué trae PHP 8.4 de verdad

El anuncio oficial lo resume bien: property hooks, asymmetric visibility, API DOM actualizada, mejoras de rendimiento, fixes y limpieza general (php.net/releases/8.4).

Property hooks

Antes, una propiedad «calculada» pedía getters, setters y a veces docblocks desactualizados. En 8.4 podés definir get y set sobre la propiedad misma. Los IDEs y los analizadores estáticos entienden el contrato sin magia extra. El RFC está en la wiki de PHP y el ejemplo oficial aparece en la página del release.

Asymmetric visibility

Podés exponer una propiedad como lectura pública y escritura privada (o protected) en una sola declaración: public private(set) string $version. Menos boilerplate de getters solo para «mostrar sin dejar tocar».

Atributo #[\Deprecated]

Hasta ahora la deprecación de APIs propias era convención de docblock. Con #[\Deprecated(message: "...", since: "8.4")] PHP emite el aviso de deprecación de verdad, igual que con APIs del core. Útil si mantenés plugins o librerías propias.

DOM con soporte HTML5

Nace el namespace Dom con Dom\HTMLDocument y Dom\XMLDocument, parseo HTML5 alineado al estándar y selectores al estilo querySelector. La API vieja de DOMDocument sigue, pero el camino nuevo es más predecible para scrapers, importadores y builders de contenido.

BCMath orientado a objetos

BcMath\Number permite trabajar con precisión arbitraria con operadores (+, >, etc.) en lugar de solo funciones bc*. Los objetos son inmutables e implementan Stringable.

Nuevas funciones de arrays

array_find(), array_find_key(), array_any() y array_all() cubren patrones que antes resolvías con foreach + break. Menos código repetido, misma intención legible.

Subclases PDO por driver

PDO::connect() puede devolver Pdo\MySql, Pdo\Sqlite, Pdo\Pgsql y otras. Cada subclase expone métodos del driver sin castear a ciegas.

Hay más (lazy objects, JIT basado en IR Framework, optimizaciones puntuales). El listado completo y los RFCs viven en php.net/releases/8.4 y en wiki.php.net.

Performance: ¿cuánto más rápido que PHP 8.3?

Acá hay que ser honestos con los datos.

WordPress y apps reales: diferencia chica entre 8.3 y 8.4

Tideways midió Symfony, Laravel y WordPress en 8.2, 8.3 y 8.4. Su conclusión: el rendimiento entre esas tres versiones no se mueve mucho en demos de aplicación. En WordPress, pasar de 8.3 a 8.4 no mostró cambio significativo en tiempos de respuesta; sí se ve un plus leve al comparar la familia 8.x contra 7.4 (alrededor de un 5% menos de requests/segundo en 7.4 en su setup) (Tideways, mayo 2025).

Kinsta publicó benchmarks de 13 CMS/frameworks con WordPress 6.8.0 sin plugins ni caché de página (concurrency 15, 1000 requests por corrida). Resultados en req/s para la home:

PHP WordPress 6.8 (req/s)
7.4 139.06
8.2 146.09
8.3 142.75
8.4 148.22
8.5 148.30

Fuente: Kinsta PHP benchmarks. El salto gordo no es 8.3 → 8.4; es salir de 7.4. Entre 8.2 y 8.5 la curva es chata. WooCommerce en el mismo estudio se mantiene estable en 8.2–8.4 y recién pega un salto visible en 8.5 (con la salvedad de que el tamaño de respuesta del test también cambió en esa corrida).

Phoronix y benches sintéticos

Michael Larabel cubrió el release de 8.4 en Phoronix y señaló un JIT nuevo basado en IR Framework más mejoras varias (Phoronix, 21 nov 2024). Los números de OpenBenchmarking/PHPBench son útiles para el motor en vacío, no para «mi WordPress con Woo y Elementor». No uses un score sintético como promesa de TTFB en producción.

Lectura práctica

  • Si estás en 7.4 / 8.0 / 8.1: el upgrade a 8.3 u 8.4 suele dar más por seguridad y por el stack moderno que por un 2–3% de CPU.
  • Si ya estás en 8.2 o 8.3: no esperes un milagro de velocidad solo por el número de versión. El cuello de botella casi siempre es base de datos, plugins, imágenes y caché.
  • El mayor retorno de performance en un sitio real sigue siendo: menos plugins basura, object cache, página cache, queries sanas y un plan de hosting con recursos suficientes (planes HDS).

Deprecaciones que pueden romper código legacy

PHP 8.4 no «rompe todo» de un día para el otro, pero sí enciende avisos que en logs ruidosos se sienten como rotura. Guía oficial: migration84.deprecated.

Parámetros implícitamente nullable (la más frecuente)

Esto era válido y confuso:

function foo(string $a = null) {}

En 8.4 emite deprecación. Hay que ser explícito:

function foo(?string $a = null) {}
// o
function foo(string|null $a = null) {}

RFC: Deprecate implicitly nullable parameter types. En plugins abandonados desde 2019 esto aparece a montones. PHP-CS-Fixer y Rector lo corrigen en bloque si tenés el repo.

Extensiones que salieron del core

IMAP, OCI8, PDO_OCI y pspell dejaron de venir empaquetadas con PHP y pasaron a PECL. Si un formulario o un bridge viejo usa funciones imap_* y el host no instaló la extensión PECL, el sitio tira fatal error al cargar, no un warning suave.

Otras deprecaciones a tener en el radar

  • Usar _ como nombre de clase.
  • 0 elevado a potencia negativa (** / pow()).
  • Varias APIs de mysqli (ping, kill, refresh) y constantes asociadas.
  • Cambios de comportamiento en exit / die y firmas que ahora devuelven tipos más estrictos.

¿Qué plugins se rompen?

No hay una lista mágica universal. Se rompen (o llenan el log de deprecations) sobre todo:

  1. Plugins sin actualización en 2+ años.
  2. «Nulled», forks pirata o copias de marketplace dudoso.
  3. Código custom del theme hijo copiado de tutorials de PHP 5/7.
  4. Integraciones que asumen IMAP embebido u otras extensiones unbundled.

Core de WordPress y plugins del directorio oficial con mantenimiento activo suelen estar al día o muy cerca. El riesgo está en la cola larga del ecosistema, no en el core en sí.

WordPress y PHP 8.4 (estado a 2026)

Según los requisitos oficiales de WordPress.org (actualizados en 2026):

  • Recomendado: PHP 8.3 o mayor.
  • Mínimo que todavía corre: PHP 7.4+, con el aviso fuerte de que 7.4 ya está en End of Life y expone el sitio a vulnerabilidades sin parche del lenguaje.

La tabla de compatibilidad del handbook de Core (actualizada 22 may 2026) documenta soporte pleno de PHP 8.4 en WordPress 6.8+ y también en 6.9 / 7.0, junto con 8.5 en las versiones más nuevas (PHP Compatibility and WordPress Versions). En mayo 2026 el proyecto retiró la etiqueta de «beta support» para dar más claridad a hosts y usuarios.

Traducción al dueño del sitio:

Tu PHP hoy Prioridad Motivo
7.4 Urgente EOL del lenguaje; WordPress todavía lo tolera, pero el riesgo es tuyo
8.0 / 8.1 Alta Sin soporte de seguridad de PHP
8.2 Media Security support hasta el 31 dic 2026 (php.net/supported-versions)
8.3 Baja–media Bien parado; podés subir a 8.4 cuando el stack de plugins esté verde
8.4 OK Active support del lenguaje hasta fin de 2026; security hasta 2028

Cómo lo manejamos en Hosting del Sur

En los planes de HDS tenés selector MultiPHP de cPanel. No hace falta migrar de servidor ni reescribir el sitio para probar otra versión: elegís 8.x por dominio (o por directorio, según el caso) y listo.

Flujo que recomendamos:

  1. Backup completo (archivos + base) antes de tocar la versión.
  2. Staging o subdominio de prueba con la misma copia del sitio.
  3. En staging, pasar a PHP 8.4 desde MultiPHP Manager.
  4. Recorrer home, checkout, formularios, wp-admin, cron y endpoints que uses de verdad.
  5. Revisar error_log y el log de PHP-FPM buscando Deprecated y fatals.
  6. Actualizar plugins/themes problemáticos o reemplazarlos.
  7. Recién ahí, repetir el cambio en producción en un horario de bajo tráfico.

Si no querés pelearte con logs y plugins huérfanos, el servicio de mantenimiento WordPress cubre actualizaciones controladas, monitoreo y ese tipo de upgrades de runtime.

Detalle de planes y recursos: /planes/.

Plan de upgrade recomendado (dueños de sitio)

1. Inventario (30 minutos)

  • Versión actual de PHP (en cPanel o con un phpinfo temporal).
  • Versión de WordPress, theme padre/hijo y lista de plugins con fecha de última actualización.
  • ¿Hay código custom en el child theme o must-use plugins?

2. Limpieza previa

Desactivá o reemplazá plugins sin commits hace años. Menos superficie = menos sorpresas al subir de versión.

3. Subí de a un escalón si venís de muy atrás

Si estás en 7.4, no saltes a ciegas a 8.4 en producción el viernes a las 18. Camino sano:

  1. 7.4 → 8.1 o 8.2 en staging (corregí fatales duros).
  2. 8.2 → 8.3.
  3. 8.3 → 8.4.

Si ya estás en 8.2+, el salto directo a 8.4 en staging suele alcanzar.

4. Checklist de humo post-cambio

  • Home y 3–5 URLs clave (producto, contacto, blog).
  • Login wp-admin y editor de una entrada.
  • Carrito y checkout si hay WooCommerce.
  • Formularios (Contact Form, Gravity, etc.).
  • Cron: una entrada programada o un job conocido.
  • Mail saliente de prueba (pedido, reset de clave).

5. Dejá WP_DEBUG off en producción

En staging, WP_DEBUG + log te ayudan. En producción, no muestres errores al visitante; mirá el log del servidor.

6. No persigas el microbenchmark

Si el sitio ya está en 8.3 y los plugins están al día, pasar a 8.4 es buena higiene (soporte del lenguaje, features nuevas para desarrollo, alineación con lo que recomienda WordPress). No lo vendas internamente como «va a cargar 40% más rápido». Los datos públicos no respaldan ese discurso.

Resumen

PHP 8.4 es un release sólido: property hooks, asymmetric visibility, DOM HTML5, BCMath OO, helpers de arrays y deprecaciones que empujan código más claro. En WordPress, los benches de Tideways y Kinsta muestran ganancias chicas o nulas entre 8.3 y 8.4, y el salto que importa de verdad es abandonar 7.4 y las 8.0/8.1 sin soporte.

WordPress 6.8+ documenta compatibilidad con 8.4; el proyecto recomienda 8.3 o mayor. En HDS lo activás con MultiPHP, lo probás en staging y lo llevás a producción cuando el log esté limpio.

Si querés que lo hagamos nosotros —backup, staging, prueba de plugins y corte a 8.4— escribinos o mirá el mantenimiento WordPress. Si estás armando sitio nuevo, partí directo en 8.3 u 8.4 desde el plan que elijas.