Saltar al contenido

Cómo cambiar el límite de subida de WordPress

Cinco formas de subir el límite de carga de medios en WordPress. Elige la que encaje con tu entorno de servidor y tu proveedor de hosting.

Límite efectivo = mínimo de todas las capas nginx / Apache (proxy) client_max_body_size php.ini post_max_size whole POST php.ini upload_max_filesize per file WP_MEMORY_LIMIT (wp-config) PHP memory Cada capa se aplica de arriba a abajo. La menor es el límite efectivo.
Diagrama: capas de configuración que determinan el límite de subida en WordPress

Comprueba el límite actual

El panel de WordPress muestra «Tamaño máximo de archivo» en Medios → Añadir nuevo, y la pestaña Información de Salud del sitio lista los valores de PHP subyacentes. De serie, WordPress suele heredar un límite de PHP de entre 2 MB y 10 MB.

El límite efectivo es el menor de estos tres ajustes.

  • upload_max_filesize — el tamaño máximo de un solo archivo
  • post_max_size — el tamaño máximo de toda la petición POST; debe superar a upload_max_filesize
  • memory_limit — el techo de memoria disponible para PHP

Método 1: editar wp-config.php

La opción más rápida: añade esta línea a wp-config.php en la raíz de WordPress.

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

No surte efecto si el hosting ha deshabilitado ini_set; en ese caso prueba otro método. Para algo más fiable también puedes usar define, como se muestra abajo.

define('WP_MEMORY_LIMIT', '256M');

Eso eleva el techo de memoria de WordPress, pero por sí solo no cambia el límite de subida. Combínalo con alguno de los métodos siguientes.

Método 2: editar .htaccess (Apache)

En un servidor Apache que use mod_php, añade lo siguiente al .htaccess de la raíz de WordPress.

php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value memory_limit 256M
php_value max_execution_time 300
php_value max_input_time 300

Aviso: cuando PHP se ejecuta como CGI o FastCGI —lo habitual en hosting compartido—, .htaccess no puede cambiar la configuración de PHP, así que este método no sirve. Si aparece un error 500, elimina las líneas añadidas.

Método 3: editar php.ini o .user.ini

Editar directamente la configuración de PHP es la forma más fiable de cambiar estos valores, siempre que tengas acceso.

En php.ini

upload_max_filesize = 64M
post_max_size = 128M
memory_limit = 256M
max_execution_time = 300
max_input_time = 300

En .user.ini (para hosting compartido)

Si tu hosting no permite editar php.ini directamente, crea un archivo .user.ini en la raíz de WordPress con el mismo contenido. Puede tardar de minutos a horas en aplicarse.

upload_max_filesize = 64M
post_max_size = 128M
memory_limit = 256M

Método 4: añadir un filtro en functions.php

Añade un hook de filtro al functions.php del tema. Sirve cuando no puedes cambiar PHP, pero nunca superará los ajustes de PHP del servidor.

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '128M');
@ini_set('memory_limit', '256M');
@ini_set('max_execution_time', '300');
@ini_set('max_input_time', '300');

También puedes fijar el límite mediante un filtro de WordPress.

add_filter('upload_size_limit', function($size) {
    return 64 * 1024 * 1024; // 64MB
});

Aviso: esto solo cambia el límite del lado de WordPress. Si el upload_max_filesize de PHP es menor, manda PHP.

Método 5: cambiarlo en el panel de control del hosting

La mayoría de los proveedores de hosting japoneses permiten cambiar los ajustes de PHP desde su panel. Es la vía más segura y fiable.

Xserver

  1. Inicia sesión en el panel del servidor
  2. Elige PHP → Ajustes de php.ini
  3. Selecciona el dominio
  4. Abre la pestaña de cambio de ajustes de php.ini
  5. Cambia upload_max_filesize y post_max_size a los valores que quieras
  6. Pasa a la pantalla de confirmación y aplica el cambio

ConoHa WING

  1. Inicia sesión en el panel de control
  2. Gestión del sitio → Ajustes del sitio → Ajustes avanzados
  3. Cambia upload_max_filesize en los ajustes de PHP

Sakura Internet

  1. Inicia sesión en el panel de control
  2. Ajustes de scripts → Ajustes de php.ini
  3. Cambia los valores y guarda

Probar tras el cambio

Una vez cambiada la configuración, sube un archivo realmente grande y comprueba el comportamiento. Los archivos de prueba de umbral de DevLab permiten probar el límite exacto que has configurado.

Caso de prueba Qué comprobar
Un archivo por debajo del límite (63 MB si configuraste 64 MB)Debe subirse sin problemas
Un archivo exactamente en el límite (64 MB)Confirma si tiene éxito o falla
Un archivo por encima del límite (65 MB)Debe mostrarse un mensaje de error claro

Resolución de problemas

  • El cambio no surte efecto: puede que haga falta reiniciar el servidor web (Apache o Nginx) y el proceso de PHP.
  • Aparece un error 500: revisa el .htaccess por erratas o directivas que el servidor no admita.
  • Aparece un error 413: en Nginx, revisa también client_max_body_size, que se define en nginx.conf.
  • Tiempos de espera: las subidas grandes también requieren aumentar max_execution_time y max_input_time.

❓ Preguntas frecuentes

He cambiado el ajuste pero el límite sigue igual.
Si queda un solo valor pequeño, ese valor es el límite efectivo. Comprueba en este orden: upload_max_filesize y post_max_size en php.ini, luego client_max_body_size o LimitRequestBody en el servidor web, y después el techo del panel de tu proveedor. En alojamiento compartido a veces el propio cambio de php.ini está configurado para ignorarse.
¿Mejor functions.php o wp-config.php?
Ninguno garantiza sobrescribir los ajustes ini de PHP; lo que funciona de verdad es la configuración del servidor. functions.php se pierde al cambiar de tema, así que wp-config.php es al menos el más seguro de los dos. En el fondo, sin embargo, esto pertenece a php.ini, .htaccess o al panel del proveedor: trata las líneas del lado de WordPress como último recurso.
¿Cuál es la mejor forma de subir un vídeo grande?
En lugar de subir el límite, la respuesta correcta es no meter vídeo en WordPress. Archivos de varios cientos de MB castigan la memoria y el tiempo de ejecución de PHP y engordan las copias de seguridad. Alojarlo en YouTube, Vimeo o almacenamiento de objetos como S3 e incrustarlo elimina el problema del límite y además sirve más rápido. Si de verdad tiene que vivir en tu servidor, colócalo por FTP o SSH y limítate a registrarlo en la biblioteca de medios.