Olete seadistanud teema, lisanud tosin pistikprogrammi, konfigureerinud kohandatud välju ja seejärel lõpetab WordPress menüü seadete salvestamise. Klõpsate nupul „Salvesta", kuid mõned menüüelemendid lihtsalt kaovad.

See ei ole administraatori paneeli tõrge ega pistikprogrammi probleem. Serveris olev PHP on tabanud max_input_vars sisendmuutujate limiiti ja kärbib vormilt tulevaid andmeid vaikselt. Vaikimisi on limiit 1000, mis on tänapäevase paari raske pistikprogrammiga WordPressi seadistuse jaoks selgelt ebapiisav.

Allpool on kolm viisi limiidi suurendamiseks: alates kiirest.htaccess-i muutmisest kuni majutuse paneeli seadeteni. Kõiki meetodeid on testitud Apache ja PHP-FPM-iga ning need töötavad PHP versioonidest 7.4 kuni 8.4.

Mis on max_input_vars ja kuidas viga avaldub

max_input_vars on PHP direktiiv, mis piirab GET, POST ja COOKIE päringutest vastuvõetavate muutujate arvu. Piirang kehtib igale superglobaalsele massiivile eraldi: POST muutujaid loendatakse GET ja COOKIE muutujatest sõltumatult.

Väikese visiitkaardi veebisaidi jaoks on tuhandest muutujast enam kui küll. Kuid WordPressi administraatori paneel genereerib iga olemi kohta kümneid välju: menüüelemendid, vidinad, kohandaja valikud, pistikprogrammide metakastid. Kui menüüvorm sisaldab 80 elementi, millest igaüks edastab 12-15 muutujat, ületatakse limiit märkamatult ja osa andmetest läheb salvestamise ajal kaotsi.

Sümptomid, mis viitavad just sellele probleemile:

• Menüüelemendid ei salvestu või salvestuvad ainult osaliselt.
• Vidinad lähtestuvad iseeneslikult mitteaktiivseks.
• Mõni pistikprogramm (nt SEO pistikprogramm või lehe koostaja) kaotab pärast salvestamist osa seadeid.
• Saidi tervises (Tööriistad → Saidi tervis → Info → Server) on PHP max input variables väärtus 1000 või vähem.

WordPressi kogukonna standardne soovitus on tõsta limiit 3000-ni. See on enamiku seadistuste jaoks piisav. Eriti raskete administraatori paneelidega saidid (mitmetasandilised menüüd 100+ elemendiga, Mega Menu, kümned ACF väljad) võivad julgelt määrata 5000 või isegi 10000, kuna sellel pole serveri jõudlusele praktiliselt mingit mõju.

💡 Kiirülevaade:

• Kontrolli praegust limiiti: phpinfo() või saidi tervis WordPressi administraatoris.
• 1. meetod: lisa php_value max_input_vars 3000 oma.htaccess faili, töötab Apache'iga, kasutades mod_php-d.
• 2. meetod: lisa max_input_vars = 3000 faili php.ini või.user.ini, sobib PHP-FPM-ile.
• 3. meetod: muuda väärtust majutuse paneeli kaudu, valik neile, kellel puudub otsene juurdepääs serverifailidele.

1. Meetod:.htaccess-i muutmine

See meetod töötab, kui PHP töötab Apache moodulina (mod_php). Seda saate kindlaks teha jaotises Tööriistad → Saidi tervis → Info → Server: real Server architecture on kirjas Apache ja PHP käsitleja on loetletud moodulina, mitte FPM/FastCGI-na.

Enne muutmist tehke.htaccess-ist varukoopia: laadige fail FTP või majutuse failihalduri kaudu oma arvutisse alla. Selle faili muudatused on süntaksitundlikud; lisatühik või reavahetus võib saidi 500 veaga maha võtta.

Avage.htaccess (asub saidi juurkataloogis, faili wp-config.php kõrval) ja lisage rida:

1
php_value max_input_vars 3000

Kui serverisse on paigaldatud Suhosini laiendus (2026. aastal haruldane, kuid vanematel jagatud majutustel siiski leidub), siis ühest reast ei piisa. Lisage kolm direktiivi:

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 püüab muutujad kinni enne PHP-d ja kärbib neid max_input_vars-ist sõltumatult, sellest ka täiendav ridade komplekt.

Pärast.htaccess-i salvestamist avage WordPressi administraator → Tööriistad → Saidi tervis → Info → Server ja veenduge, et PHP max input variables näitab uut väärtust. Kui see pole muutunud, lugege allpool olevat jaotist „Mida teha, kui limiit ikka ei muutu".

2. Meetod: php.ini või.user.ini muutmine

Kaasaegsetes serverites töötab PHP kõige sagedamini PHP-FPM-i kaudu ja php_value direktiive.htaccess-is ignoreeritakse. Töötav tööriist on siin php.ini või.user.ini.

.user.ini töötleb PHP-FPM kataloogipõhiselt: fail paigutatakse saidi juurkataloogi ja seda rakendatakse rekursiivselt kõigile alamkataloogidele. Erinevalt .htaccess-ist, mida Apache loeb igal päringul, on see PHP standardmehhanism, mida toetatakse alates versioonist 5.3.

Looge (või muutke olemasolevat) .user.ini faili saidi juurkataloogis ja lisage:

1
max_input_vars = 3000

Kui teil on juurdepääs globaalsele php.ini-le (VPS / pühendatud server), muutke väärtust ka seal. Täpse tee php.ini-ni leiate phpinfo() kaudu: otsige rida Loaded Configuration File. Pärast php.ini muutmist on vajalik PHP-FPM-i taaskäivitamine:

1
sudo systemctl restart php8.2-fpm

Asendage käsus olev versiooninumber enda omaga (8.1, 8.2, 8.3, 8.4). Kontrollige uut väärtust saidi tervise kaudu; see peaks kohe uuenema.

Kui .user.ini faili ei eksisteeri, looge see lihtsalt tekstiredaktoris. Nimi algab punktiga, nii et võib-olla peate oma majutuse failihalduris lubama peidetud failide kuvamise.

3. Meetod: limiidi muutmine majutuse paneeli kaudu

Jagatud majutuse (cPanel, ISPmanager, DirectAdmin) puhul on lihtsaim viis muuta väärtust graafilise liidese kaudu, ilma faile käsitsi puudutamata.

cPanel: minge jaotisesse Select PHP Version → lülituge vahekaardile Options. Leidke rida max_input_vars, muutke väärtus 1000-lt 3000-le ja klõpsake Save. Muudatus rakendub koheselt; taaskäivitust pole vaja.

ISPmanager: PHP jaotis → seaded → lisaparameetrid → max_input_vars.

DirectAdmin: PHP Settings → leidke direktiiv loendist → muutke → salvestage.

Kui paneelil pole max_input_vars välja, kasutab majutus kõvakodeeritud php.ini ilma muutmisõiguseta. Sel juhul aitab ainult toe poole pöördumine: esitage pilet, milles palute tõsta max_input_vars 3000-ni (või mis tahes konkreetsele vajalikule väärtusele). Enamik majutusteenuseid muudab limiiti esimese taotluse peale; see on rutiinne toiming.

Mida teha, kui limiit ikka ei muutu

Olukord: read.htaccess-is ja.user.ini-s on paigas, majutuse paneel näitab uut väärtust, kuid saidi tervis näitab visalt 1000. Põhjused ja nende lahendused:

Vale muutmise meetod. max_input_vars kuulub PHP_INI_PERDIR režiimi: direktiivi saab muuta ainult failides php.ini,.htaccess,.user.ini või httpd.conf. Funktsioonil ini_set() failis wp-config.php pole sellele mingit mõju; kood @ini_set('max_input_vars', 3000) täidab toimingu, kuid PHP ignoreerib seda vaikselt. Ärge raisake sellele meetodile aega.

PHP konfiguratsiooni vahemälu. Mõned paneelid (eriti cPanel koos PHP-FPM-iga) salvestavad ini-failid vahemällu. Pärast.user.ini muutmist oodake 5 minutit; nii kaua hoiab PHP-FPM vaikimisi konkreetse kataloogi konfiguratsiooni vahemälu. Protsessi saate kiirendada, taaskäivitades PHP-FPM-i majutuse paneelist.

Kaks php.ini faili. Jagatud majutusel on sageli globaalne php.ini ühes kaustas ja lokaalne teises. PHP haarab käivitamisel esimese leitud faili. Kontrollige phpinfo() kaudu teed Loaded Configuration File juurde ja muutke just seda konkreetset faili. Täiendav Scan this directory for additional .ini files võib samuti limiiti sisaldada; kontrollige ka seda kausta.

Majutuse jäik limiit. Mõned teenusepakkujad blokeerivad max_input_vars muutmise konteineri tasemel (CloudLinux koos PHP Selectori piirangutega). phpinfo()-s on direktiiv märgitud kui no value või ei ilmu üldse. See tähendab, et majutus on seadnud kasutaja muudatustest kõrgema ülempiiri; aitab ainult tugipilet või paketi uuendamine.

⁉️🤔 Korduma kippuvad küsimused

Kui palju täpselt peaksin määrama: 3000 või rohkem?

Valdavale enamusele WordPressi saitidest piisab 3000-st. See väärtus katab kuni 120 elemendiga menüüd, tosina aktiivse pistikprogrammiga administraatori paneelid ja kümne jaotisega kohandaja lehed. Määrake 5000, kui kasutate Mega Menu'd 150+ elemendiga, sellist koostajat nagu Elementor, millel on sadu välju lehe kohta, või ACF-i paindlike paigutustega. Üle 10000 ainult siis, kui pistikprogrammi arendaja seda dokumentatsioonis selgesõnaliselt täpsustab.

Miks lähtestus limiit pärast PHP uuendamist 1000-le?

PHP versiooni uuendamine majutuse paneeli kaudu toob sageli kaasa vaikimisi php.ini. Kontrollige.user.ini ja paneeli; tõenäoliselt on fail endiselt alles, kuid majutus lülitas fondi uuele konfiguratsioonile ilma teie muudatusteta.

Kas ma saan limiidi määrata wp-config.php kaudu?

Ei. max_input_vars direktiivil on PHP_INI_PERDIR režiim ja seda ei saa ini_set() kaudu muuta; PHP ignoreerib sellist kutset vaikselt. Töötavad ainult.htaccess (Apache'il koos mod_php-ga),.user.ini / php.ini ja majutuse paneel.

Kuidas ma saan aru, kas probleem on just nimelt max_input_vars ja mitte milleski muus?

Kõige täpsem indikaator on PHP logid. Lubage WP_DEBUG failis wp-config.php: define('WP_DEBUG', true);. Pärast ebaõnnestunud vormi salvestamist kontrollige faili /wp-content/debug.log: kui seal on kirje Warning: Input variables exceeded 1000, on diagnoos kinnitatud.

Mida ma peaksin tegema, kui minu majutus ei luba mul limiiti muuta?

Võtke ühendust toega, esitades konkreetse numbri (näiteks „tõstke max_input_vars 3000-ni"). See on tavapärane taotlus; tugi täidab selle enamiku teenusepakkujate juures tasuta. Nad keelduvad kahel juhul: äärmiselt odav pakett rangelt fikseeritud limiitidega (siis aitab ainult paketi uuendamine) või sait jagatud majutusel koos sadade naabritega, kus individuaalsed limiidid pole arhitektuuriliselt toetatud.

Kokkuvõte: millist meetodit oma olukorras valida

Toimingute järjekord, lihtsamast keerulisemani.

Kui olete jagatud majutusel cPaneliga, alustage 3. meetodist (paneel). See võtab kolm klõpsu ja enamikul juhtudel on probleem lahendatud. Kui väärtus saidi tervises ei muutu, proovige 2. meetodit.user.ini kaudu: fail läheb saidi juurkataloogi ja PHP-FPM haarab selle automaatselt.

Kui teil on VPS või pühendatud server Apache ja mod_php-ga, annab 1. meetod (.htaccess) kohese tulemuse ega vaja teenuste taaskäivitamist. Apache + PHP-FPM seadistuse korral kasutage 2. meetodit (php.ini või.user.ini).

Kui paneel ei võimalda muutmist, tugi ei vasta ja limiit on takerdunud 1000 peale, võite olla oma praegusest paketist välja kasvanud. WordPressi seadistused muutuvad iga aastaga raskemaks: rohkem välju, rohkem andmeid, kõrgemad nõuded serverikeskkonnale. Majutuse vahetamine paindlikuma paketi vastu lahendab probleemi radikaalselt ja parandab ka saidi üldist jõudlust.

Alustage saidi tervise kontrollimisest kohe: Tööriistad → Saidi tervis → Info → Server → PHP max input variables. Kui see näitab 1000 või vähem, taastab ükskõik milline ülaltoodud kolmest lahendusest teie kontrolli administraatori paneeli üle 5 minutiga.