Aumentar el tamaño máximo de subida de archivos en WordPress

Tres ajustes controlan el límite de subida de WordPress, y los tres tienen que coincidir. El límite real es el menor de upload_max_filesize, post_max_size y el tope de peticiones de tu servidor web. Si subes uno y dejas los otros dos bajos, no cambia nada — y por eso la mayoría de la gente concluye que su solución “no funcionó”. Comprueba primero tus valores actuales con la herramienta de tamaño máximo de subida de WordPress; lee los mismos valores que reporta WordPress y te muestra cuál te está frenando.

Por qué existe el límite y dónde vive

WordPress no fija el límite de subida. Solo lo reporta. Cuando ves “The uploaded file exceeds the upload_max_filesize directive in php.ini”, ese mensaje viene directamente de PHP.

Tres valores distintos condicionan una subida, y el techo real es el más bajo de todos:

• upload_max_filesize (PHP) — el archivo individual más grande que PHP aceptará.
• post_max_size (PHP) — el cuerpo POST total más grande. Tu archivo viaja dentro de la petición POST junto con otros campos del formulario, así que este valor debe ser mayor que upload_max_filesize.
• El límite de cuerpo del servidor web — client_max_body_size en Nginx, o LimitRequestBody en Apache. Este vive completamente fuera de PHP, y por eso las soluciones que tocan solo PHP fallan en silencio detrás de Nginx.

Un cuarto valor, max_execution_time, no limita el tamaño, pero abortará una subida grande y lenta a mitad de transferencia si la conexión es mala. Es un síntoma aparte, no forma parte del techo de tamaño.

La trampa: pones upload_max_filesize = 256M, recargas, y sigues sin poder subir un archivo de 100 MB — porque post_max_size sigue en 8M. PHP rechaza la petición por el cuerpo total antes de siquiera inspeccionar el archivo. El límite no te ignoró. Otro límite lo atrapó primero.

Cómo arreglarlo, por orden

Ve de lo que tiene más probabilidad de funcionar hasta el último recurso.

1. Edita php.ini (el lugar correcto). Encuentra el archivo que tu sitio carga realmente — ejecuta una página con <?php phpinfo(); y lee “Loaded Configuration File”, o pregunta a tu hosting. Fija ambos valores de PHP, y mantén post_max_size mayor que upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Reinicia PHP-FPM (sudo systemctl restart php8.2-fpm) o Apache. Los cambios no hacen nada hasta que el proceso de PHP se reinicia.

2. ¿Sin acceso a php.ini? Usa .htaccess (solo Apache + mod_php). Añade esto al .htaccess en la raíz de tu WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Esto solo funciona cuando PHP corre como módulo de Apache. Bajo PHP-FPM, CGI o FastCGI, php_value lanza un error 500 — ese fallo significa que vas por mal camino, no que el número esté mal. Cambia a .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Sube el límite del servidor web — el paso que todo el mundo olvida. En Nginx, PHP ni siquiera llega a ver una petición demasiado grande; Nginx devuelve 413 Request Entity Too Large primero. En tu bloque de servidor:

client_max_body_size 256M;

Recarga con sudo nginx -t && sudo systemctl reload nginx. Si estás en Nginx y tus cambios en PHP “no hicieron nada”, casi siempre es por esto.

Después de cualquier cambio, vuelve a comprobar los valores reportados. La herramienta de tamaño máximo de subida te dirá el nuevo techo real y generará el fragmento exacto para tu configuración, para que no andes adivinando cuál de los tres sigue bajo.

Qué no hacer

No edites wp-config.php esperando que suba el límite. La línea que todo el mundo copia no hace lo que afirman los artículos de blog:

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize es PHP_INI_PERDIR. No se puede cambiar desde PHP en tiempo de ejecución con ini_set(). Solo acepta valores nuevos desde php.ini, .htaccess o .user.ini — nunca desde el código de la aplicación. La línea se ejecuta sin error y no hace nada, lo que la convierte en uno de los consejos equivocados que más se repiten con seguridad en WordPress.

Tampoco pegues @ini_set('post_max_size', ...) — misma restricción, mismo no-op silencioso.

No pongas WP_MEMORY_LIMIT pensando que es el límite de subida. Eso controla el techo de memoria de PHP para ejecutar código. No tiene nada que ver con el tamaño de archivo que acepta el servidor.

No te quedes en un solo archivo. El fallo más común con diferencia es cambiar solo upload_max_filesize y declarar que la solución no sirve. Cambia los tres, y mantén post_max_size por encima de upload_max_filesize.

No pongas límites absurdamente altos “por si acaso”. Un límite de 2 GB invita a problemas de agotamiento de recursos y no ayuda — si de verdad necesitas archivos de varios gigabytes, súbelos fuera del navegador (SFTP, o un plugin de subida por fragmentos) en vez de forzarlos por un único POST de PHP.

¿Sigues atascado?

Si los tres valores están subidos y aún así te topas con un muro, la petición se está limitando en algún punto aguas arriba de tu servidor: un CDN o proxy (el panel de Cloudflare limita por su cuenta el tamaño del cuerpo de subida), el límite de plataforma de un hosting gestionado que ignora tu php.ini, o un .user.ini que aún no se ha refrescado — respeta el user_ini.cache_ttl de PHP, así que puede tardar unos minutos en aplicarse tras guardar. Confirma lo que el servidor reporta realmente, no lo que escribiste en un archivo, y arregla la capa que sigue baja. Cuando el número reportado por fin coincida con tu objetivo, la subida funciona.