Una subida que falla es casi siempre uno de tres límites, y subir el que usted conoce deja los otros dos de por medio. Los tres tienen que ser al menos tan grandes como el archivo.

Los tres

  • upload_max_filesize (PHP): el mayor archivo suelto.
  • post_max_size (PHP): la petición entera, así que tiene que ser MAYOR que el archivo: los campos del formulario también cuentan.
  • client_max_body_size (Nginx): el servidor web rechaza antes de que se llegue siquiera a PHP.
; php.ini
upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
# nginx
client_max_body_size 72M;

Cuál de ellos rechazó

  • 413 Request Entity Too Large: Nginx. PHP no lo llegó a ver.
  • Un mensaje de PHP sobre el tamaño: upload_max_filesize.
  • Un $_POST vacío y sin error alguno: post_max_size. PHP tira la petición entera en silencio, y por eso este es tan desconcertante.

Confirme que el cambio ha surtido efecto

php -i | grep -E "upload_max_filesize|post_max_size"
Eso lee la configuración de la línea de órdenes, que a menudo es un archivo distinto del que usa el servidor web. Fíese de una página phpinfo() antes que de la terminal: es la única que enseña con qué corre su sitio de verdad.
WordPress muestra el límite efectivo en la página de medios. Si tras un cambio sigue apareciendo el número viejo, es que no se recargó PHP-FPM: systemctl reload php8.3-fpm.