Ha configurado su tema, ha añadido una docena de plugins, ha configurado campos personalizados y entonces WordPress deja de guardar los ajustes de los menús. Hace clic en «Guardar», pero algunos elementos del menú simplemente desaparecen.

Esto no es un fallo del panel de administración ni un problema de un plugin. PHP en el servidor ha alcanzado el límite de variables de entrada max_input_vars y trunca silenciosamente los datos que llegan del formulario. Por defecto, el límite es 1000, lo cual es claramente insuficiente para una configuración moderna de WordPress con un par de plugins pesados.

A continuación se presentan tres maneras de aumentar el límite: desde una edición rápida del.htaccess hasta los ajustes del panel de alojamiento. Todos los métodos han sido probados en Apache y PHP-FPM y funcionan desde PHP 7.4 hasta 8.4.

Qué es max_input_vars y cómo se manifiesta el error

max_input_vars es una directiva de PHP que limita el número de variables aceptadas de las peticiones GET, POST y COOKIE. La restricción se aplica a cada array superglobal por separado: las variables POST se cuentan independientemente de GET y COOKIE.

Para un sitio web de tarjeta de visita pequeño, mil variables son más que suficientes. Pero el panel de administración de WordPress genera docenas de campos para cada entidad: elementos de menú, widgets, opciones del personalizador, metaboxes de plugins. Cuando un formulario de menú contiene 80 elementos, cada uno transmitiendo de 12 a 15 variables, el límite se excede de forma invisible y parte de los datos se pierde durante el guardado.

Síntomas que indican este problema específico:

• Los elementos del menú no se guardan o se guardan solo parcialmente.
• Los widgets se restablecen espontáneamente a inactivos.
• Un plugin (como un plugin SEO o un maquetador de páginas) pierde algunos ajustes después de guardar.
• En Salud del sitio (Herramientas → Salud del sitio → Información → Servidor), el valor de PHP max input variables es igual a 1000 o menos.

La recomendación estándar de la comunidad de WordPress es aumentar el límite a 3000. Esto es suficiente para la mayoría de las configuraciones. Los sitios con paneles de administración particularmente pesados (menús multinivel con más de 100 elementos, Mega Menu, docenas de campos ACF) pueden establecer con seguridad 5000 o incluso 10000, ya que esto prácticamente no tiene impacto en el rendimiento del servidor.

💡 Resumen rápido:

• Verifique el límite actual: phpinfo() o Salud del sitio en el administrador de WordPress.
• Método 1: añada php_value max_input_vars 3000 a su archivo.htaccess, funciona con Apache usando mod_php.
• Método 2: añada max_input_vars = 3000 a php.ini o.user.ini, adecuado para PHP-FPM.
• Método 3: cambie el valor a través del panel de alojamiento, una opción para quienes no tienen acceso directo a los archivos del servidor.

Método 1: editar.htaccess

Este método funciona cuando PHP se ejecuta como un módulo de Apache (mod_php). Puede determinarlo en Herramientas → Salud del sitio → Información → Servidor: la línea Server architecture contiene Apache, y el manejador de PHP aparece como un módulo, no como FPM/FastCGI.

Antes de editar, haga una copia de seguridad del.htaccess: descargue el archivo a su ordenador mediante FTP o el gestor de archivos de su alojamiento. Las ediciones en este archivo son sensibles a la sintaxis; un espacio extra o un salto de línea pueden tirar el sitio con un error 500.

Abra el.htaccess (ubicado en la raíz del sitio, junto a wp-config.php) y añada la línea:

1
php_value max_input_vars 3000

Si el servidor tiene instalada la extensión Suhosin (algo raro en 2026 pero que aún se encuentra en alojamientos compartidos antiguos), una línea no es suficiente. Añada tres directivas:

1
php_value suhosin.request.max_vars 3000
2
php_value suhosin.post.max_vars 3000
3
php_value suhosin.get.max_vars 3000

Suhosin intercepta las variables antes que PHP y las trunca independientemente de max_input_vars, de ahí el conjunto adicional de líneas.

Después de guardar el.htaccess, abra el administrador de WordPress → Herramientas → Salud del sitio → Información → Servidor y verifique que PHP max input variables muestra el nuevo valor. Si no ha cambiado, lea la sección «Qué hacer si el límite sigue sin cambiar» a continuación.

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

En los servidores modernos, PHP se ejecuta con mayor frecuencia a través de PHP-FPM, y las directivas php_value en.htaccess se ignoran. La herramienta adecuada aquí es php.ini o.user.ini.

.user.ini es procesado por PHP-FPM por directorio: el archivo se coloca en la raíz del sitio y se aplica recursivamente a todos los subdirectorios. A diferencia de .htaccess, que Apache lee en cada petición, este es el mecanismo estándar de PHP, soportado desde la versión 5.3.

Cree (o edite un existente) archivo .user.ini en la raíz del sitio y añada:

1
max_input_vars = 3000

Si tiene acceso al php.ini global (VPS/servidor dedicado), cambie el valor allí también. La ruta exacta al php.ini se puede encontrar a través de phpinfo(): busque la línea Loaded Configuration File. Después de editar php.ini, se requiere reiniciar PHP-FPM:

1
sudo systemctl restart php8.2-fpm

Reemplace el número de versión en el comando por el suyo (8.1, 8.2, 8.3, 8.4). Verifique el nuevo valor a través de Salud del sitio; debería actualizarse inmediatamente.

Si el archivo .user.ini no existe, simplemente créelo en un editor de texto. El nombre comienza con un punto, por lo que puede necesitar habilitar la visualización de archivos ocultos en el gestor de archivos de su alojamiento.

Método 3: cambiar el límite a través del panel de alojamiento

Para alojamiento compartido (cPanel, ISPmanager, DirectAdmin), el enfoque más simple es cambiar el valor a través de la interfaz gráfica sin tocar archivos manualmente.

cPanel: vaya a Seleccionar versión de PHP → cambie a la pestaña Opciones. Encuentre la línea max_input_vars, cambie el valor de 1000 a 3000 y haga clic en Guardar. El cambio se aplica instantáneamente; no se requiere reinicio.

ISPmanager: sección PHP → configuración → parámetros adicionales → max_input_vars.

DirectAdmin: Configuración de PHP → encuentre la directiva en la lista → cambie → guarde.

Si el panel no tiene un campo max_input_vars, el alojamiento utiliza un php.ini predefinido sin derechos de edición. En este caso, solo ayudará contactar con el soporte: envíe un ticket solicitando aumentar max_input_vars a 3000 (o el valor específico que necesite). La mayoría de los proveedores cambian el límite a la primera solicitud; esta es una operación rutinaria.

Qué hacer si el límite sigue sin cambiar

Situación: las líneas en.htaccess y.user.ini están en su lugar, el panel de alojamiento muestra el nuevo valor, pero Salud del sitio muestra obstinadamente 1000. Causas y sus soluciones:

Método incorrecto para el cambio. max_input_vars pertenece al modo PHP_INI_PERDIR: la directiva solo se puede cambiar en php.ini,.htaccess,.user.ini o httpd.conf. La función ini_set() en wp-config.php no tiene efecto sobre ella; el código @ini_set('max_input_vars', 3000) ejecuta la operación, pero PHP la ignora silenciosamente. No pierda tiempo con este método.

Caché de configuración de PHP. Algunos paneles (especialmente cPanel con PHP-FPM) almacenan en caché los archivos ini. Después de editar.user.ini, espere 5 minutos; este es el tiempo que PHP-FPM mantiene por defecto la caché de configuración para un directorio específico. Puede acelerar el proceso reiniciando PHP-FPM desde el panel de alojamiento.

Dos archivos php.ini. En el alojamiento compartido, a menudo hay un php.ini global en una carpeta y uno local en otra. PHP toma el primero que encuentra al iniciar. Verifique la ruta a Loaded Configuration File a través de phpinfo() y edite ese archivo específico. El adicional Scan this directory for additional .ini files también puede contener el límite; revise esta carpeta también.

Límite estricto del alojamiento. Algunos proveedores bloquean los cambios a max_input_vars a nivel de contenedor (límites de CloudLinux con PHP Selector). En phpinfo(), la directiva está marcada como no value o no aparece en absoluto. Esto significa que el alojamiento ha establecido un techo por encima de las ediciones del usuario; solo ayudará un ticket de soporte o una actualización del plan.

⁉️🤔 Preguntas frecuentes

¿Cuánto debería establecer exactamente: 3000 o más?

Para la gran mayoría de los sitios de WordPress, 3000 es suficiente. Este valor cubre menús de hasta 120 elementos, paneles de administración con una docena de plugins activos y páginas del personalizador con diez secciones. Establezca 5000 si usa Mega Menu con más de 150 elementos, un maquetador como Elementor con cientos de campos por página o ACF con diseños flexibles. Por encima de 10000, solo si el desarrollador del plugin lo especifica explícitamente en la documentación.

¿Por qué el límite se restableció a 1000 después de una actualización de PHP?

Actualizar la versión de PHP a través del panel de alojamiento a menudo incorpora el php.ini predeterminado. Verifique.user.ini y el panel; lo más probable es que el archivo siga allí, pero el alojamiento cambió el pool a una nueva configuración sin sus ediciones.

¿Puedo establecer el límite a través de wp-config.php?

No. La directiva max_input_vars tiene modo PHP_INI_PERDIR y no se puede cambiar mediante ini_set(); PHP ignorará silenciosamente dicha llamada. Solo funcionan.htaccess (en Apache con mod_php),.user.ini / php.ini y el panel de alojamiento.

¿Cómo puedo saber si el problema es específicamente max_input_vars y no otra cosa?

El indicador más preciso son los registros de PHP. Active WP_DEBUG en wp-config.php: define('WP_DEBUG', true);. Después de un guardado fallido del formulario, verifique /wp-content/debug.log: si hay una entrada Warning: Input variables exceeded 1000, el diagnóstico está confirmado.

¿Qué debo hacer si mi alojamiento no me permite cambiar el límite?

Contacte con el soporte con un número específico (por ejemplo, «aumentar max_input_vars a 3000»). Esta es una solicitud estándar; el soporte la cumple sin costo en la mayoría de los proveedores. Se niegan en dos casos: un plan extremadamente barato con límites estrictamente fijos (entonces solo ayuda una actualización) o un sitio en alojamiento compartido con cientos de vecinos donde los límites individuales no están soportados arquitectónicamente.

Resumen: qué método elegir para su situación

Orden de acciones, de la más simple a la más compleja.

Si está en un alojamiento compartido con cPanel, comience con el método 3 (panel). Requiere tres clics y en la mayoría de los casos el problema se resuelve. Si el valor no cambia en Salud del sitio, pruebe el método 2 mediante.user.ini: el archivo va en la raíz del sitio y es recogido por PHP-FPM automáticamente.

Si tiene un VPS o servidor dedicado con Apache y mod_php, el método 1 (.htaccess) da resultados instantáneos y no requiere reiniciar servicios. Para una configuración de Apache + PHP-FPM, use el método 2 (php.ini o.user.ini).

Si el panel no permite la edición, el soporte no responde y el límite está atascado en 1000, es posible que haya superado su plan actual. Las configuraciones de WordPress se vuelven más pesadas cada año: más campos, más datos, mayores requisitos del entorno del servidor. Cambiar de alojamiento a un plan más flexible resuelve el problema de raíz y también mejora el rendimiento general del sitio.

Comience por verificar Salud del sitio ahora mismo: Herramientas → Salud del sitio → Información → Servidor → PHP max input variables. Si muestra 1000 o menos, cualquiera de las tres soluciones anteriores le devolverá el control sobre el panel de administración en 5 minutos.