Skip to content

Kaikki WordPressistä, web-kehityksestä — ja paljon muuta

Tiedostojen latausraja WordPressissä: paljonko ja mistä muutetaan

Kerro, minkä kokoisia tiedostoja pitää ladata — työkalu laskee yhtenäisen arvojoukon ja näyttää, mikä tapa toimii juuri sinun palvelintyypilläsi. Kaikki lasketaan selaimessa, mitään ei lähetetä minnekään.

Kuinka suuri saa olla suurin tiedosto, jonka aiot ladata.
WordPressin mediakirjasto lähettää tiedostot yksi kerrallaan. Mukautetut monikenttäiset lomakkeet lähettävät ne yhdellä pyynnöllä.
Jos et tiedä, katso phpinfo()-tulosteen riviä Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DirektiiviMiksi juuri tämä arvoArvo
 


    

      
    

  


  

  

  

  

  

    Miksi se ei toiminut: tarkistuslista
    Arvot on kirjoitettu, mutta raja pysyi vanhana — lähes aina kyse on jostakin alla olevasta yhdeksästä kohdasta.
    

      
Palveluntarjoajan kova raja. Pakettia suurempi arvo leikataan hiljaisesti: tiedostossa 512M, phpinfo():ssa 64M. Auttaa vain yhteydenotto tukeen.

      
Muokkasit väärää php.ini-tiedostoa. Aktiivinen tiedosto näkyy phpinfo()-tulosteessa rivillä Loaded Configuration File; sen vieressä on Additional .ini files parsed — nekin luetaan ja ne voivat ohittaa arvosi.

      
LimitRequestBody Apachessa. Verkkopalvelimen oma raja tavuina, vhostissa tai .htaccess-tiedostossa. Se katkaisee pyynnön rungon ennen PHP:tä — käyttäjä näkee koodin 413, mutta PHP:n lokit ovat tyhjät.

      
PHP-prosessia ei ole käynnistetty uudelleen. php.ini luetaan kerran käynnistyksessä. PHP-FPM:ssä on käynnistettävä uudelleen juuri FPM — nginxin tai Apachen uudelleenkäynnistys ei lue poolia uudelleen.

      
.user.ini ei tule voimaan heti. PHP pitää sitä välimuistissa user_ini.cache_ttl sekuntia (oletuksena 300). Odota 5 minuuttia tai käynnistä FPM uudelleen.

      
OPcache. Itse php.ini-tiedostoa se ei tallenna välimuistiin, mutta wp-config.php:n ja sen @ini_set-rivit kyllä. Muokkauksen jälkeen: opcache_reset() tai prosessin uudelleenkäynnistys.

      
Edessä on välityspalvelin. Cloudflare katkaisee ilmaisella tasolla latauksen 100 megatavuun; kuormantasaajalla, Engintronilla tai Apachen edessä olevalla nginxillä on oma client_max_body_size.

      
WordPressin puolelta tuleva rajoitus. Multisite: Verkko → Asetukset → Tiedoston enimmäiskoko (kilotavuina). Lisäksi suodatin upload_size_limit, jonka jotkin teemat ja tietoturvalisäosat asettavat.

      
Väliaikaiskansio. Jos upload_tmp_dir ei ole kirjoitettavissa tai osiolta loppui tila, tiedosto ei tule perille eikä selkeää virhettä näy. Tarkista sys_get_temp_dir() ja vapaa tila.

    

  


  
Laskenta tehdään selaimessasi — mitään palvelinta koskevia tietoja ei lähetetä minnekään.


Miksi pelkän upload_max_filesizen muuttaminen ei lähes koskaan riitä
Latauksen kokoa rajoittaa vähintään neljä toisistaan riippumatonta arvoa, ja niistä pienin ratkaisee.

upload_max_filesize — yhden tiedoston koko.
post_max_size — koko POST-pyynnön koko. Sen pitää olla suurempi kuin upload_max_filesize, muuten tiedosto katkeaa jo ennen ensimmäisen rajan tarkistusta.
memory_limit — sen pitää mahduttaa koko pyyntö; WordPressille vähintään 256M.
client_max_body_size — nginxin raja. Se unohtuu useimmin: PHP sallii jo kaiken, mutta nginx palauttaa 413 Request Entity Too Large.

Oma ansansa on menetelmä. php_value-direktiivit .htaccess-tiedostossa toimivat VAIN silloin, kun PHP on liitetty Apachen moduulina (mod_php). Nykyisissä palveluissa PHP toimii lähes aina FPM:nä, ja silloin tällainen rivi joko ohitetaan hiljaisesti tai se antaa 500 Internal Server Error -virheen. Juuri siksi työkalu kysyy palvelintyypin ja näyttää, mikä lohko todella auttaa sinua.
Usein kysytyt kysymykset