Skip to content

Alt om WordPress, webutvikling — og mer til

Grensen for filopplasting i WordPress: hvor mye og hvor du endrer den

Oppgi hvor store filer du trenger å laste opp — verktøyet regner ut et sammenhengende sett med verdier og viser hvilken måte som virker på nettopp din servertype. Alt beregnes i nettleseren, ingenting sendes noe sted.

Hvor stor den største filen du planlegger å laste opp skal være.
WordPress-mediebiblioteket sender filene én om gangen. Egendefinerte skjemaer med flere felter sender dem i én enkelt forespørsel.
Vet du ikke — se i phpinfo(), linjen Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DirektivHvorfor akkurat denne verdienVerdi
 


    

      
    

  


  

  

  

  

  

    Hvorfor det ikke virket: sjekkliste
    Verdiene er skrevet, men grensen står som før — nesten alltid er det ett av de ni punktene nedenfor.
    

      
Hard grense hos webhotellet. En verdi over det abonnementet tillater kuttes stille: 512M i filen, 64M i phpinfo(). Løses bare ved å kontakte support.

      
Du redigerte feil php.ini. Den aktive filen står i phpinfo() på linjen Loaded Configuration File; ved siden av står Additional .ini files parsed — også disse leses og kan overstyre verdiene dine.

      
LimitRequestBody i Apache. Webserverens egen grense, i byte, i vhost eller .htaccess. Den kutter forespørselskroppen før PHP — brukeren ser 413, mens PHP-loggene er tomme.

      
PHP-prosessen er ikke startet på nytt. php.ini leses én gang ved oppstart. For PHP-FPM må du starte selve FPM på nytt — en omstart av nginx eller Apache leser ikke puljen på nytt.

      
.user.ini tas ikke i bruk umiddelbart. PHP mellomlagrer den i user_ini.cache_ttl sekunder (300 som standard). Vent 5 minutter eller start FPM på nytt.

      
OPcache. Selve php.ini mellomlagres ikke, men wp-config.php med @ini_set gjør det. Etter endringen: opcache_reset() eller omstart av prosessen.

      
En proxy foran. Cloudflare kutter opplastinger ved 100 MB på gratisplanen; en lastbalanserer, Engintron eller nginx foran Apache har sin egen client_max_body_size.

      
En grense fra WordPress sin side. Multisite: Nettverk → Innstillinger → Maksimal filstørrelse (i KB). I tillegg filteret upload_size_limit, som enkelte temaer og sikkerhetsutvidelser setter.

      
Midlertidig mappe. Hvis upload_tmp_dir ikke er skrivbar eller partisjonen er full, kommer ikke filen fram, uten noen tydelig feilmelding. Sjekk sys_get_temp_dir() og ledig plass.

    

  


  
Beregningen skjer i nettleseren din — ingen opplysninger om serveren sendes noe sted.


Hvorfor det nesten aldri holder å bare endre upload_max_filesize
Opplastingsstørrelsen begrenses av minst fire uavhengige verdier, og den minste av dem gjelder.

upload_max_filesize — størrelsen på én fil.
post_max_size — størrelsen på hele POST-forespørselen. Må være større enn upload_max_filesize, ellers kuttes filen allerede før den første grensen sjekkes.
memory_limit — må romme hele forespørselen; for WordPress minst 256M.
client_max_body_size — grensen i nginx. Den glemmes oftest: PHP tillater allerede alt, men nginx svarer 413 Request Entity Too Large.

Metoden er en felle for seg. php_value-direktiver i .htaccess virker BARE når PHP kjøres som Apache-modul (mod_php). På moderne webhotell kjører PHP nesten alltid som FPM, og da blir en slik linje enten stille ignorert eller gir 500 Internal Server Error. Nettopp derfor spør verktøyet om servertype og viser hvilken blokk som faktisk hjelper deg.
Vanlige spørsmål