Kom under WordPress gräns för bilduppladdning

Komprimera bilden så att den hamnar under gränsen istället för att höja gränsen, eftersom en mindre fil löser både uppladdningsfelet och sidhastighetsproblemet i ett steg. WordPress ärver sitt tak från PHP, vanligtvis 2 MB eller 8 MB beroende på webbhotell, och på ett hanterat eller delat webbhotell kan du ofta inte ändra det.

Nästintill alla artiklar om det här ämnet uppmanar dig att redigera php.ini, .htaccess eller wp-config.php. De instruktionerna förutsätter en serveråtkomst som de flesta webbplatsägare saknar, och även om åtkomsten finns är det värt att fråga sig om det är rätt väg att höja taket.

Varifrån gränsen kommer

Taket ställs in av 3 PHP-värden, och det minsta av de 3 gäller. WordPress visar den slutgiltiga siffran under uppladdningsrutan, vilket är anledningen till att siffran ofta skiljer sig från vad webbhotellet marknadsför.

• upload_max_filesize styr den största enskilda filen som PHP accepterar.
• post_max_size styr den totala storleken för ett formulär eller en uppladdning, så den måste överstiga filstorleken.
• memory_limit styr hur mycket minne ändringen av bildstorlek får använda när miniatyrbilder skapas.
• max_execution_time kan också orsaka misslyckanden, eftersom en stor bild kan tajma ut innan bearbetningen är klar.

Det tredje värdet orsakar de mest förvirrande felen. En fil som laddas upp utan problem kan ändå misslyckas när WordPress skapar sina miniatyrstorlekar, vilket leder till en trasig bild i mediebiblioteket istället för ett uppladdningsfel.

Varför komprimering är bättre än att höja gränsen

Ett fotografi på 6 MB på en webbsida är ett problem oavsett om servern accepterar det eller inte. Att höja gränsen tar bort felmeddelandet men lämnar den bakomliggande tyngden intakt.

WordPress skapar flera miniatyrstorlekar av varje uppladdning, så ett tungt original mangedubblas till tunga avläggare och förbrukar lagringsutrymme över hela mediebiblioteket. Att komprimera till några hundra kilobyte före uppladdningen löser felet, minskar de genererade storlekarna, förkortar säkerhetskopieringstiderna och kräver ingen serveråtkomst alls.

Hur du kommer under gränsen

Följ dessa 5 steg för att ladda upp utan problem och utan att röra serverinställningarna.

1. Läs gränsen som visas under uppladdningsrutan i WordPress, som rapporterar den verkliga siffran för ditt webbhotell.
2. Ändra storlek på bilden till dess visningsbredd, fördubblad för högupplösta skärmar, eftersom ett fotografi på 4000 pixlar i en kolumn på 800 pixlar slösar bort det mesta av sin data.
3. Konvertera till WebP för fotografier och grafik som bara ska visas på webbplatsen.
4. Komprimera till ett mål på 200 KB till 400 KB, vilket passar nästan alla bilder i artiklar.
5. Ladda upp och kontrollera sedan att bilden visas korrekt i full bredd på både dator och mobil.

Att arbeta i den ordningen ger vanligtvis en fil som är 90 procent mindre än kameraoriginalet, utan någon synlig skillnad på skärmen. Att uppladdningsfelet försvinner blir en sidoeffekt snarare än själva huvudmålet.

Rekommenderade storlekar för WordPress-innehåll

Anpassa bildbredden till det bredaste utrymmet den någonsin kommer att ta upp i ditt tema, och dubbla sedan det för högupplösta skärmar. De flesta innehållsområden är långt smalare än vad webbplatsägare tror.

När höjning av gränsen är rätt svar

Höj gränsen när du laddar upp genuint stora filer som måste förbli stora, till exempel fotografier i tryckupplösning, video eller temapaket. De fallen är verkliga, men det är inte de vanliga fallen.

En fotograf som levererar högupplösta gallerier, en butik som importerar ett stort tillägg eller en webbplats som är värd för nedladdningsbara PDF-dokument behöver alla marginaler. En bloggare vars semesterbild ska visas 700 pixlar bred behöver det inte. Fråga vad filen ska användas till innan du ändrar en serverinställning, för svaret pekar oftast tillbaka på komprimering.

Hur du höjer gränsen om du måste

Fråga webbhotellet först, eftersom de flesta hanterade leverantörer ändrar värdet på begäran inom några minuter. Supportärenden löser detta snabbare än konfigurationsfiler på alla webbhotell som begränsar filåtkomst.

• Hanterade WordPress-webbhotell visar vanligtvis inställningen i en kontrollpanel eller justerar den på begäran.
• cPanel-hosting innehåller ofta en MultiPHP INI Editor där de 3 värdena kan ställas in direkt.
• Virtuella privata servrar (VPS) tillåter redigering av php.ini, varpå PHP-tjänsten måste startas om.
• .htaccess-redigeringar fungerar på vissa Apache-installationer och orsakar ett serverfel på andra, så spara en säkerhetskopia.
• Tillägg som hävdar att de höjer gränsen kan inte överskrida vad servern tillåter, oavsett vad beskrivningen säger.

HTTP-felet som inte handlar om storlek

Ett allmänt HTTP-fel under uppladdning innebär oftast att minnet eller exekveringstiden tog slut när WordPress skapade miniatyrbilder, inte att filen avvisades på grund av storlek. Skillnaden är viktig eftersom komprimering av bilden löser båda orsakerna.

Stora dimensioner snarare än stor filstorlek driver minnesanvändningen, eftersom servern måste hålla varje pixel i minnet medan storleken ändras. En bild på 6000 gånger 4000 pixlar kräver långt mer minne än vad dess filstorlek antyder. Att minska dimensionerna före uppladdningen tar bort felet även när filen redan låg under storlekstaket.

Miniatyrstorlekarna som WordPress skapar

WordPress skapar minst 4 extra kopior av varje uppladdning, och teman samt tillägg lägger vanligen till flera till. Ett enda fotografi kan bli 8 eller 10 filer på disken utan att webbplatsägaren någonsin ser dem.

Standardinställningarna är miniatyrbild på 150 pixlars kvadrat, medium på 300 pixlar, medium stor på 768 pixlar och stor på 1024 pixlar, tillsammans med den skakade version WordPress skapar för mycket stora uppladdningar. Sidbyggare och galleritillägg registrerar sina egna storlekar utöver dessa. Att ladda upp ett mindre original innebär att varje avledd fil också blir mindre, vilket är anledningen till att komprimering före uppladdning ger en sammansatt effekt över hela biblioteket.

WebP-stöd i WordPress

WordPress har accepterat WebP-uppladdningar sedan version 5.8, och alla aktuella webbläsare visar formatet. Att ladda upp WebP direkt gör att du slipper konverteringstillägg som många webbplatser installerar för samma ändamål.

Två varningar gäller. Vissa äldre teman och sidbyggare förutsätter JPG eller PNG och kanske inte skapar WebP-miniatyrer korrekt, så kontrollera en provuppladdning innan du konverterar ett helt bibliotek. Bilder som är avsedda för nedladdning av besökare, till exempel presskit eller utskrivbara guider, bör förbli JPG, eftersom WebP fortfarande är krångligt utanför webbläsare.

Kontrollera bildtyngd på en levande sida

Öppna utvecklarverktygen med F12, växla till fliken Nätverk (Network), filtrera på bilder och läs in sidan igen. Panelen listar varje bild med dess verkliga överförda storlek, sorterad med den största först.

Den vyn svarar direkt på frågan istället för genom gissningar. Leta efter enskilda bilder på över 500 KB och sidor där bilderna totalt överstiger 2 MB. Den största filen är nästan alltid den som är värd att åtgärda först, och det är oftast en sidhuvudsbild eller det första fotografiet i ett inlägg. Att åtgärda 2 eller 3 bilder tar ofta bort det mesta av den överflödiga tyngden på en sida.

Fixa ett mediebibliotek som redan är tungt

Komprimera det befintliga biblioteket istället för bara de nya uppladdningarna, eftersom äldre inlägg står för den mesta tyngden på en etablerad webbplats. En blogg som har varit igång i 5 år kan innehålla tusentals okomprimerade bilder.

Ladda ner mappen med uppladdningar (uploads), bearbeta den som en enda körning och ersätt filerna med behållna namn så att befintliga inlägg fortsätter att fungera. Genom att återskapa miniatyrbilder efteråt byggs de avledda storlekarna om från de mindre originalen. Ta en säkerhetskopia innan du ersätter något, eftersom detta är en av få bilduppgifter som skriver över filer direkt.

Bearbeta en hel uppladdningsmapp

Släpp in mappen som ett ZIP-arkiv så extraheras, ändras storleken på och komprimeras varje bild som stöds i en enda omgång. Upp till 500 filer körs per omgång, vilket täcker de flesta små och medelstora webbplatser på några få vändor.

Allt sker i din webbläsare på din egen processor, så kundwebbplatser, opublicerade utkast och privata gallerier når aldrig en server. Det är viktigt för webbureauer som arbetar under avtal, där uppladdning av en kunds mediebibliotek till en okänd komprimeringstjänst skulle bryta mot avtalet även om ingenting gick fel.