Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando intentas subir un tema, un plugin o un backup grande en tu WordPress local y ves el error de tamaño, lo primero que buscas es XAMPP aumentar upload_max_filesize. Y casi siempre lo editas, reinicias Apache y… sigue igual. Ese es el punto donde mucha gente se atasca, porque el php.ini que tocaron no era el que PHP estaba leyendo.
En XAMPP conviven varias copias de php.ini según el módulo que uses: Apache, CGI/FastCGI o incluso el que carga el propio panel de control. Si cambias la equivocada, el límite sigue anclado en el valor por defecto. Antes de tocar nada, abre http://localhost/dashboard/phpinfo.php (lo creas con una línea de <?php phpinfo(); ?>) y busca «Loaded Configuration File». Esa ruta es la única que importa.
Las dos directivas que casi nadie ajusta a la vez
Subir solo upload_max_filesize no suele servir. post_max_size debe ser igual o mayor, porque engloba todo el cuerpo del POST. Un ejemplo típico: pones 128M en upload y dejas 8M en post_max_size; el archivo de 40 MB seguirá rebotando sin mensaje claro. También conviene revisar memory_limit y max_execution_time, sobre todo si el archivo es grande y la máquina va justa.
Un ajuste coherente para un XAMPP de desarrollo podría ser:
upload_max_filesize = 256M
post_max_size = 256M
memory_limit = 512M
max_execution_time = 300
No hace falta ir más allá salvo que trabajes con volcados de base de datos enormes. En local el riesgo es bajo, pero recuerda que estos valores no son recomendables en producción.
Por qué el cambio no se aplica aunque guardes
Hay tres causas frecuentes que he visto en proyectos reales. La primera: editar el php.ini de C:xamppphpphp.ini pero tener Apache configurado para leer otro en C:xamppapachebinphp.ini. La segunda: reiniciar el servicio desde el panel con el botón de Stop/Start sin detener Apache por completo; algunos procesos mantienen el archivo bloqueado. La tercera: tener una directiva php_value upload_max_filesize en un .htaccess que sobrescribe lo del php.ini.
Si tras reiniciar phpinfo sigue mostrando el valor antiguo, sospecha de un override. Busca en tu .htaccess y en la configuración del VirtualHost cualquier línea que empiece por php_value o php_admin_value.
El caso que no funciona: subidas por PHP-CLI
Esto no funciona para scripts que corren desde la terminal. PHP-CLI lee su propio php.ini (a menudo en C:xamppphpphp.ini pero con directivas distintas) y además muchas veces no tiene límite de subida porque no procesa peticiones HTTP. Si tu problema es un importador de WordPress lanzado por WP-CLI, el límite que te frena probablemente sea el del propio plugin o el de la base de datos, no el de Apache.
Alternativa rápida sin tocar php.ini
Si solo necesitas un archivo puntual y no quieres reiniciar Apache, puedes añadir al inicio de tu script:
ini_set(‘upload_max_filesize’, ’64M’);
ini_set(‘post_max_size’, ’64M’);
Funciona en muchos entornos locales, pero no siempre: upload_max_filesize es PHP_INI_PERDIR en algunos SAPIs, así que el ini_set puede ser ignorado. Pruébalo y verifica con phpinfo() antes de confiar en él. Si no cambia, vuelve al php.ini correcto.
Comprobación final antes de dar por cerrado el tema
Después de reiniciar Apache, abre phpinfo y confirma tres cosas: la ruta del archivo cargado, el valor de upload_max_filesize y el de post_max_size. Si los tres coinciden con lo que escribiste, el cambio está activo. Si no, el problema no es XAMPP sino la ruta o un override. Documenta la ruta del php.ini en un comentario del propio archivo para no repetir la búsqueda la próxima vez.
La documentación oficial de PHP sobre upload_max_filesize y el manual de Apache sobre php_value son las fuentes que conviene consultar cuando algo no cuadra. No hay atajo mágico: el 90% de los casos se resuelve identificando el php.ini correcto y ajustando las dos directivas en pareja.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
