Skip to content

Kõik WordPressist, veebiarendusest — ja mitte ainult

Failide üleslaadimise limiit WordPressis: kui palju ja kust muuta

Märgi, kui suuri faile on vaja üles laadida — tööriist arvutab kooskõlalise väärtuste komplekti ja näitab, milline viis sinu serveritüübil toimib. Kõik arvutatakse brauseris, midagi kuhugi ei saadeta.

Kui suur peab olema kõige suurem fail, mida plaanid üles laadida.
WordPressi meediakogu saadab faile ükshaaval. Kohandatud mitme väljaga vormid saadavad need ühe päringuga.
Kui ei tea, vaata phpinfo() väljundist rida Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DirektiivMiks just selline väärtusVäärtus
 


    

      
    

  


  

  

  

  

  

    Miks ei töötanud: kontrollnimekiri
    Väärtused on kirjas, aga piir jäi vanaks — peaaegu alati on põhjuseks üks üheksast punktist allpool.
    

      
Majutaja jäik piirang. Paketis lubatust suurem väärtus lõigatakse vaikselt maha: failis 512M, aga phpinfo()-s 64M. Aitab ainult toe poole pöördumine.

      
Parandasid vale php.ini faili. Aktiivse faili nimetab phpinfo() real Loaded Configuration File; kõrval on Additional .ini files parsed — ka neid loetakse ja need võivad sinu väärtused üle kirjutada.

      
LimitRequestBody Apache'is. Veebiserveri enda piirang baitides, vhostis või failis .htaccess. See lõikab päringu keha ära enne PHP-d — kasutaja näeb koodi 413, PHP logides on aga tühi.

      
PHP-protsessi ei ole taaskäivitatud. php.ini loetakse käivitamisel üks kord. PHP-FPM puhul tuleb taaskäivitada just FPM — nginxi või Apache'i restart pooli uuesti ei loe.

      
.user.ini ei rakendu kohe. PHP hoiab seda vahemälus user_ini.cache_ttl sekundit (vaikimisi 300). Oota 5 minutit või taaskäivita FPM.

      
OPcache. Faili php.ini ennast ta vahemällu ei pane, küll aga sinu wp-config.php koos @ini_set-iga. Pärast muudatust — opcache_reset() või protsessi taaskäivitus.

      
Ees on proksi. Cloudflare lõikab tasuta paketis üleslaadimise 100 MB peal; koormusjaotur, Engintron või nginx Apache ees on oma client_max_body_size.

      
Piirang WordPressi poolt. Multisite: Võrk → Seaded → Faili maksimaalne suurus (KB-des). Lisaks filter upload_size_limit, mille seavad mõned teemad ja turvapluginad.

      
Ajutine kaust. Kui upload_tmp_dir ei ole kirjutatav või partitsioonil sai ruum otsa, siis fail kohale ei jõua ja selget viga ei kuvata. Kontrolli sys_get_temp_dir() ja vaba ruumi.

    

  


  
Arvutus tehakse sinu brauseris — mitte mingeid serveri andmeid kuhugi ei saadeta.


Miks ainult upload_max_filesize muutmisest peaaegu kunagi ei piisa
Üleslaadimise mahtu piirab vähemalt neli sõltumatut väärtust ja kehtib neist kõige väiksem.

upload_max_filesize — ühe faili suurus.
post_max_size — kogu POST-päringu suurus. Peab olema suurem kui upload_max_filesize, muidu lõigatakse fail ära juba enne esimese piirangu kontrolli.
memory_limit — peab mahutama kogu päringu; WordPressi jaoks vähemalt 256M.
client_max_body_size — nginxi piirang. Just see ununeb kõige sagedamini: PHP lubab juba kõike, aga nginx vastab 413 Request Entity Too Large.

Eraldi lõks on meetod. php_value direktiivid failis .htaccess töötavad AINULT siis, kui PHP on ühendatud Apache moodulina (mod_php). Kaasaegses majutuses töötab PHP peaaegu alati FPM-ina ja siis kas eiratakse sellist rida vaikselt või annab see 500 Internal Server Error. Just sellepärast küsibki tööriist serveri tüüpi ja näitab, milline plokk sind tegelikult aitab.
Korduma kippuvad küsimused