Skip to content

Todo para WordPress, el desarrollo web — y mucho más

El límite de subida de archivos en WordPress: cuánto y dónde cambiarlo

Indique de qué tamaño son los ficheros que necesita subir: la herramienta calculará un conjunto coherente de valores y mostrará qué método funcionará en su tipo de servidor. Todo se calcula en el navegador, no se envía nada a ningún sitio.

Cuánto debe pesar el archivo más grande que piensa subir.
La biblioteca de medios de WordPress envía los ficheros de uno en uno. Los formularios personalizados con varios campos los envían en una sola petición.
Si no lo sabe, mire phpinfo(), la línea Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DirectivaPor qué precisamente este valorValor
 


    

      
    

  


  

  

  

  

  

    Por qué no funcionó: lista de comprobación
    Los valores están escritos, pero el límite ha seguido igual: casi siempre es uno de los nueve puntos de abajo.
    

      
Límite estricto del alojamiento. Un valor superior al que permite el plan se recorta en silencio: en el archivo 512M, en phpinfo() — 64M. Solo se soluciona contactando con el soporte.

      
Ha editado el php.ini equivocado. El archivo activo se indica en phpinfo() en la línea Loaded Configuration File; junto a ella está Additional .ini files parsed: esos también se leen y pueden redefinir sus valores.

      
LimitRequestBody en Apache. El límite del propio servidor web, en bytes, en el vhost o en .htaccess. Corta el cuerpo de la petición antes que PHP: el usuario ve 413 y los registros de PHP quedan vacíos.

      
El proceso de PHP no se ha reiniciado. php.ini se lee una sola vez al arrancar. Con PHP-FPM hay que reiniciar el propio FPM: reiniciar nginx o Apache no vuelve a leer el pool.

      
.user.ini no se aplica al instante. PHP lo mantiene en caché durante user_ini.cache_ttl segundos (300 por defecto). Espere 5 minutos o reinicie FPM.

      
OPcache. No almacena en caché el propio php.ini, pero sí su wp-config.php con @ini_set. Tras la edición: opcache_reset() o reinicio del proceso.

      
Un proxy delante. Cloudflare, en el plan gratuito, corta las subidas en 100 MB; un balanceador, Engintron o nginx delante de Apache tiene su propio client_max_body_size.

      
Un límite del propio WordPress. Multisitio: Red → Ajustes → Tamaño máximo de archivo (en KB). Además del filtro upload_size_limit, que aplican algunos temas y plugins de seguridad.

      
Carpeta temporal. Si upload_tmp_dir no admite escritura o la partición se ha quedado sin espacio, el archivo no llega y no hay un error claro. Compruebe sys_get_temp_dir() y el espacio libre.

    

  


  
El cálculo se realiza en su navegador: no se envía a ningún sitio ningún dato sobre el servidor.


Por qué cambiar solo upload_max_filesize casi nunca basta
El tamaño de subida lo limitan al menos cuatro valores independientes, y se aplica el menor de todos.

upload_max_filesize — el tamaño de un solo archivo.
post_max_size — el tamaño de toda la petición POST. Debe ser mayor que upload_max_filesize; si no, el archivo se corta antes incluso de comprobar el primer límite.
memory_limit — tiene que dar cabida a toda la petición; para WordPress, 256M como mínimo.
client_max_body_size — el límite de nginx. Es el que más se olvida: PHP ya lo permite todo, pero nginx devuelve 413 Request Entity Too Large.

El método es una trampa aparte. Las directivas php_value en .htaccess funcionan SOLO cuando PHP está cargado como módulo de Apache (mod_php). En los alojamientos modernos PHP casi siempre funciona como FPM, y entonces esa línea o se ignora en silencio o provoca un 500 Internal Server Error. Justo por eso la herramienta pregunta el tipo de servidor y muestra qué bloque le va a servir de verdad.
Preguntas frecuentes