Som med alla plattformar, finns det alltid de irriterande fel eller problem som du måste lära dig att arbeta igenom. Lita på oss, vi har sett dem alla! Från dödens vita skärm till databasanslutningsfel har WordPress definitivt sina särdrag. 😉 Men vi älskar det fortfarande! Idag ska vi dyka in i ett av de vanligaste, HTTP-felet. Användare stöter vanligtvis på detta när de försöker ladda upp bilder eller videor till WordPress Mediabibliotek.
Medan HTTP-felet vanligtvis är lätt att fixa kan det vara ganska frustrerande eftersom det vanligtvis stör ditt arbetsflöde. Ingenting är värre än att spendera 20 minuter på att försöka hitta den perfekta bilden till ditt blogginlägg, du går in för ladda upp den, och bam, du stöter på ett mycket vagt fel.
Nedan utforskar vi varför det här felet händer och vad du kan göra för att snabbt lösa det så att du kan komma tillbaka till att ladda upp dina media.
Vad är WordPress HTTP-felet?
WordPress HTTP-felet uppstår när något går fel när du försöker ladda upp bilder eller videoklipp med hjälp av det inbyggda mediebiblioteksverktyget. Till skillnad från webbläsarfel där vi vanligtvis kan referera till en HTTP-statuskod, är WordPress-fel tyvärr ibland lite svårare att felsöka (speciellt om du inte vet hur du aktiverar WordPress felsökningsläge).
Det mycket vaga ”HTTP-felet” hjälper dig definitivt inte att bestämma vad som kan vara fel eller ens var du ska börja leta. Men det beror på att det kan finnas flera orsaker till felet och WordPress vet helt enkelt inte vilket det är, så det spottar ut ett generiskt felmeddelande (som ses nedan).
Så Fixar Du WordPress HTTP-Felet
Från vår erfarenhet kommer WordPress HTTP-felet vanligtvis från två saker: det första är ett fel på klientsidan eller användarfel (din inloggningssession, dåliga tecken i filnamnet etc.), och det andra är ett problem eller inställning på din WordPress-värd (serverproblem, minneslista, tredjepartsplguin, delad hosting som stryper resurser etc.). Så vi dyker in på lite av båda.
Här är några rekommendationer och saker att kontrollera för att åtgärda felet (sorterade i ordning efter de vanligaste orsakerna vi ser):
- Uppdatera sidan
- Krymp eller ändra storlek på filen
- Byt namn på bildfilen
- Inaktivera tillfälligt Plugins och Tema
- Fråga Din WordPress-värd
- Öka PHP-minnesgränsen
- Kontrollera Uppladdningsmappens behörigheter
- Flytta till den senaste versionen av PHP
- Åtgärda prestandaproblem med Imagick och Shared Hosts
- Ta Bort Anpassad Mediabiblioteksväg
- Inaktivera mod_security
- Installera pluginet Add To Server
1. Uppdatera sidan
Det allra första du bör göra när du stöter på WordPress HTTP-felet är att helt enkelt uppdatera sidan i din webbläsare. Låter nästan för lätt eller hur? 😉Det här är faktiskt den vanligaste lösningen vi har sett för detta felet. Det här är varför:
För det första, oavsett anledning, kan din webbläsare tillfälligt ha förlorat anslutningen till WordPress och processen kunde helt enkelt inte slutföras. Detta kan bero på din ISP, en tillfällig glitch med din WordPress-värd, etc. Om du uppdaterar sidan och försöker ladda upp igen kommer felet ibland att lösa sig.
För det andra har vi också sett att ibland efter att ha uppdaterat sidan, eller ha kommit tillbaka till WordPress-redigeraren från en annan flik, kommer sidan plötsligt att sparka ut dig. Detta är sannolikt en indikator på att din WordPress inloggningssession har löpt ut. Du bör se följande meddelande:
Din session har gått ut. Logga in för att fortsätta där du slutade.
Så naturligtvis loggar du in igen och försöker ladda upp dina media igen. HTTP-felet uppstår dock. Detta är en sorts quirk med WordPress. När du loggar in igen måste du faktiskt manuellt uppdatera sidan du är på. Sedan kommer du kunna ladda upp media igen.
2. Krymp eller ändra storlek på filen
Du kan behöva redigera din bildfil, vilket kan innebära att reducera filstorleken (KB eller MB) eller att minska bredden/höjden (pixlar). Vi rekommenderar att du kollar in vårt djupgående inlägg om hur du optimerar bilder för webben. Det finns en hel del tredjeparts bildoptimeringsplugins du kan använda för att automatiskt göra detta för dig (både minska och ändra storlek) när bilden laddas upp till mediabiblioteket.
Vi har använt Imagify på vår Kinsta webbplats i flera år utan ett enda problem. Men det finns många andra bra på marknaden också. Se bara till att vilket plugin du än använder optimerar bilder på sina egna servrar, inte lokalt. Om du massoptimerar bilder lokalt kan detta drastiskt skada webbplatsens prestanda.
Det är OK att ladda upp högupplösta bilder eftersom WordPress stöder responsiva bilder direkt från installation. Faktum är att du förmodligen vill så att bilden ser skarp ut på retina-skärmar. Men om du inte är en fotograf eller ett företag som behöver högupplösta bilder är dock en bra tumregel att hålla din slutliga bildstorlek under 100 KB och inte mer än dubbelt så stor som din webbplats innehållsbredd.
Dessutom kan du behöva leka lite med filtyperna PNG och JPG. Ibland kan den ena vara mycket större än den andra beroende på vilken typ av bild det är.
Beroende på konfigurationen av din WordPress-värd, kanske du också vill undersöka att öka WordPress maximala filuppladdningsstorlek.
3. Byt namn på Bildfilen
Det kan aldrig skada att försöka byta namn på bildfilen. WordPress borde automatiskt lägga till ett nummer i slutet om du försöker ladda upp ett dubblettfilnamn, men om det inte fungerar, försök byta namn på filen. Tyvärr låter WordPress inte dig byta namn på en redan uppladdad bildfil, så du måste byta namn på den lokalt och ladda upp den igen.
När vi laddar upp bilder som redan finns lägger vi vanligtvis till en -1 eller -2 i slutet (exempel: Bild-fil-1.png, bild-fil-2.png). Se till att lägga till bindestrecket, annars kommer Google att läsa det som ett ord och det kan skada din SEO.
För att vara på den säkra sidan bör du också hålla dig borta från att ladda upp en bild med filnamn som innehåller specialtecken. Detta inkluderar internationella språksymboler och tecken som apostrofer. Bindestreck är okej. Du kan se i det här exemplet nedan på Kinstas Japanska webbplats, att vi använder engelska för filnamnen, inte specialtecken. Medan WordPress tekniskt kan stödja dessa, finns det många andra problem som kan dyka upp.
4. Inaktivera tillfälligt Plugins och Teman
Det är alltid en bra idé om du har HTTP-fel att försöka inaktivera dina plugins och även byta WordPress-tema till standard för att se om detta löser problemet. Några plugins som är typiska syndabockar inkluderar bildoptimeringsplugins (de har direkt kontakt med mediabiblioteket) och säkerhetsplugins som WordFence (dessa plugins är ibland alltför restriktiva). Eller så kan du helt enkelt ta bort ditt WordPress-tema.
Om du inte vill påverka din live-webbplats, klona helt enkelt din live-webbplats till en staging-miljö. Om WordPress HTTP-felet också händer på staging, kan du snabbt inaktivera alla dina plugins för att så småningom kunna hitta felet.
Kom ihåg att du inte kommer att förlora några data om du helt enkelt avaktiverar ett plugin. Om du fortfarande kan komma åt din adminpanel, är ett snabbt sätt att göra detta att bläddra till ”Plugins” och välj ”Inaktivera” från bulkåtgärdsmenyn. Detta kommer att inaktivera alla dina plugins.
Om detta åtgärdar problemet måste du hitta den skyldige. Börja aktivera dem ett efter ett och försök ladda upp en bild till mediebiblioteket igen. När du ser HTTP-felet igen har du hittat det skyldiga pluginet. Du kan sedan nå ut till plugin-utvecklaren för hjälp eller skicka en supportbiljett i WordPress-arkivet.
Om du inte kan komma åt din WordPress administratör kan du FTP till din server och byta namn på din pluginmapp till något som plugins_old. Kontrollera sedan din webbplats igen. Om det fungerar måste du testa varje plugin ett efter ett. Byt namn på din pluginmapp tillbaka till plugins och byt sedan namn på varje pluginmapp inuti den, en efter en, tills du hittar den. Du kan också försöka replikera detta på en stagingsajt först.
Detsamma gäller för ditt WordPress-tema. Vanligtvis påverkar inte teman mediebiblioteket, men vi har sett några konstiga konfigurationer. Det skadar aldrig att försöka byta ditt tema till standard Twenty Seventeen-temat för att se om det fixar det. Precis som med plugins behöver du inte oroa dig för att förlora dina nuvarande temainställningar. Allt detta lagras i WordPress-databasen.
5. Fråga Din WordPress-värd
Om du redan har provat stegen ovan och fortfarande får WordPress HTTP-felet rekommenderar vi att du kontaktar din WordPress-värd för hjälp innan du fortsätter. Många av de ytterligare felsökningsstegen är lite mer avancerade och många gånger kan du be din värd att göra eller kontrollera detta för dig.
Kinstas supportteam är tillgängligt dygnet runt från den nedre högra sidan av MyKinsta-panelen.
6. Öka PHP-minnesgränsen
En annan orsak till WordPress HTTP-felet är att din server saknar tillgängligt minne för uppladdningsprocessen i bakgrunden ska kunna genomföras framgångsrikt. Detta är ett mycket vanligt problem med delad WordPress-hosting. För att fixa det måste du öka mängden minne som PHP kan använda. 256 MB rekommenderas.
Standardminnesgränsen för Kinsta-klienter är redan inställd på 256 MB. Om du hostar din WordPress-webbplats på Kinsta borde du inte ha några problem med brist på minne. 👍
Öka PHP minnesgränsen med wp-config.php
Du kan öka PHP-minnesgränsen genom att lägga till följande kod i din wp-config.php-fil. OBS! Detta kan skrivas över av en servernivåregel som din WordPress-värd har satt på plats.
define( 'WP_MEMORY_LIMIT', '256M' );Öka PHP-minnesgränsen i cPanel
Om din värd använder cPanel kan du öka PHP-minnesgränsen i två olika områden.
Den första är under avsnittet Programvara. Klicka på ”Välj PHP-Version.” Klicka på ”Växla till PHP-alternativ.” Du kan sedan klicka på ”memory_limit” för att ändra dess värde.
Det andra området är också under avsnittet Programvara. Klicka på ”MultiPHP INI Editor”-verktyget. Detta gör att du kan ändra php.ini-filen. Bläddra helt enkelt ner till där det står ”memory_limit” och mata in ett högre värde.
Öka PHP-minnesgränsen med php.ini
Om du inte använder cPanel kan du också redigera php.ini-filen direkt om du har åtkomst. För att göra detta, logga in på din webbplats via FTP eller SSH, gå till webbplatsens rotkatalog och öppna eller skapa en php.ini-fil.
Det går inte att ansluta via SSH? Lär dig hur du åtgärdar SSH-anslutningen ”Connection Refused” -felet.
Om filen redan var där, sök efter inställningen ”memory_limit” och ändra den efter behov.
Vissa delade värdar kan också kräva att du lägger till suPHP-direktivet i din .htaccess-fil för att ovanstående php.ini-filinställningar ska fungera. För att göra detta, redigera din .htaccess-fil, som också finns i roten av din webbplats, och lägg till följande kod mot början av filen:
<IfModule mod_suphp.c>
suPHP_ConfigPath /home/yourusername/public_html
</IfModule>Öka PHP-minnesgränsen med .htaccess
.htaccess-fil är en speciell dold fil som innehåller olika inställningar som du kan använda för att ändra serverns beteende, hela vägen ner till en specifik katalog. Om du inte har tillgång till php.ini, föreslår vi att du testar detta härnäst. Först logga in på din webbplats via FTP eller SSH, ta en titt på din rotkatalog och se om det finns en .htaccess-fil där.
Om den finns kan du redigera den filen också och ändra värdet ”php_value memory_limit”.
7. Kontrollera Uppladdningsmappens behörigheter
Vanligtvis när det finns ett mappbehörighetsfel bör du få ett meddelande i WordPress om att det inte kan skriva till katalogen. Det är dock inte alltid fallet. Om en WordPress-webbplats har hackats eller smittats med skadlig kod kan det finnas många problem som händer med behörigheterna.
Tips: Kinsta erbjuder gratis hackningsfixar för alla kunder. 😄
Den mapp du ska ägna dig åt är främst din /wp-content/uploads-mapp, eftersom det är där filer lagras när de laddas upp via mediabiblioteket.
Enligt WordPress Codex bör alla kataloger vara 755 (drwxr-xr-x) eller 750.
Du kan enkelt se dina mappbehörigheter med en FTP-klient (se nedan). Du kan också kontakta din WordPressvärds supportteam och be dem att snabbt få GREP-filbehörigheter på dina mappar och filer för att säkerställa att de är inställda på rätt sätt.
Om du manuellt uppdaterar behörigheterna i den här mappen, se till att du både klickar i alternativet ”Återför till underkataloger” och alternativet ”Tillämpa endast på kataloger”.
8. Flytta till den senaste versionen av PHP
WordPress rekommenderar officiellt PHP 7.3 eller högre. Om du inte använder det, ligger du under de minimikrav som fastställts av utvecklarna av systemet. 😮
Vi rekommenderar alltid att du kör de senaste och stödda versionerna av PHP på grund av att de erbjuder bättre säkerhet och prestanda, inklusive buggfixar och funktioner som måste fasas ut.
Vi har sett äldre versioner av PHP bidra till alla typer av fel, inklusive det ökända WordPress HTTP-felet. På Kinsta kan du enkelt byta till PHP 8.1 med ett enda klick i MyKinsta-panelen.
Om din värd använder cPanel har de troligtvis redan ett alternativ tillgängligt för dig att ändra din version av PHP. Logga helt enkelt in på cPanel och under ”programvara”-kategorin, klicka på ”Välj PHP-Version.”
Du kan sedan välja de PHP-versioner som din värd stöder.
9. Åtgärda prestandaproblem med Imagick och Shared Hosts
Det finns två olika PHP-moduler som WordPress använder för bildbehandling: GD Library och Imagick (ImageMagick). Beroende på vilken som är installerat på din server, kan WordPress kan använda vilken som helst av dem.
Problemet är att delade WordPress värdar har en hel del dold resurs-strypning på gång bakom kulisserna. Det är det enda sättet de kan klämma in så många användare på samma maskin. Ett vanligt problem som människor stöter på är att det finns för få resurser som tilldelas till Imagick (ImageMagick). Värdar kommer att begränsa möjligheten att använda flera trådar, vilket resulterar i WordPress HTTP-felet.
Du kan lägga till följande kod överst av din .htaccess-fil, och ändra tråd-gränsvärdet till något högre.
MAGICK_THREAD_LIMIT 1
Ett annat alternativ är att tala om för WordPress att använda GD Library istället för Imagick. Du kan göra detta genom att helt enkelt lägga till följande kod till temats functions.php-fil.
function wpb_image_editor_default_to_gd( $editors ) {
$gd_editor = 'WP_Image_Editor_GD';
$editors = array_diff( $editors, array( $gd_editor ) );
array_unshift( $editors, $gd_editor );
return $editors;
}
add_filter( 'wp_image_editors', 'wpb_image_editor_default_to_gd' );Vi kommer att vara ärliga här. Om du måste justera saker som detta är det dags att flytta till en ny WordPress-värd. Kinsta har inte galna gränser som dessa på plats och för det mesta är du bara begränsad av dina PHP-arbetare. Du borde inte behöva oroa dig för dessa typer av saker som webbplatsägare.
Vi använder LXD-hanterade värdar och orkestrerade LXC programcontainers för varje webbplats. Vad detta innebär är att varje WordPress medlemskapswebbplats är inrymd i sin egen isolerade container, som har alla programresurser som krävs för att köra den (Linux, Nginx, PHP, MySQL). Resurserna är 100% privata och delas inte med någon annan eller ens dina egna webbplatser.
Läs mer om hur Kinsta är annorlunda än någon annan värd du har testat.
10. Ta Bort Anpassad Mediabiblioteksväg
Det kan mycket väl vara så att din mediabiblioteksväg inte är korrekt inställd. Vi ser vanligtvis detta när användare migrerar sin lokala utvecklingsplats över till produktion. Om du tittar i ”Media” under ”Inställningar” i din WordPress-panel och ser ett filsökvägsvärde listat, ta bort det och klicka på ”Spara ändringar.” Du vill att dina media ska lagras i standardmappen /wp-content/uploads.
Nedan ser du hur det vanligtvis ser ut. Om du inte ser en biblioteksväg, då är allt okej här.
11. Inaktivera mod_security
Mod_security är en öppen källkods-brandvägg som ibland kan orsaka WordPress HTTP-fel. Du kan inaktivera mod_security genom att lägga till följande kod längst upp i din .htaccess file.
<IfModule mod_security.c> SecFilterEngine Off SecFilterScanPOST Off </IfModule>
Om du använder cPanel kan du också inaktivera det genom att klicka på ”ModSecurity” i avsnittet ”Säkerhet”.
Växla sedan statusen från ”På” till ”Av” bredvid den domän du vill inaktivera den på.
Vi rekommenderar alltid att du använder en företagsklassad och ändå prisvärd WAF som Sucuri eller CloudFlare istället. Du kan läsa vår rekommendation om de bästa WAF-inställningarna här.
12. Installera pluginet Add From Server
Sist men inte minst, om inget annat verka fungera, kan du installera det kostnadsfria pluginet Add From Server. Kanske väntar du på ett svar från din WordPress-värd eller en utvecklare om hur du löser WordPress HTTP-felet.
Pluginet Add From Server kommer vanligtvis att ta dig runt felet och kan vara en bra temporärt fix, särskilt om du är mitt uppe i något viktigt. Det utvecklades ursprungligen så att du kan lägga till mycket stora filer via SFTP. Viktigt: detta plugin får inte längre underhåll eller support. Använd det på egen risk.
Sammanfattning
Som du kan se finns det en hel del olika sätt att åtgärda WordPress HTTP-felet. Förhoppningsvis fungerade en av lösningarna ovan för dig och du är redan tillbaka på rätt spår och kan ladda upp dina media. Om du fortsätter att få detta fel gång på gång, kan det vara dags att överväga att uppgradera till en bättre WordPress-värd. Många av lösningarna ovan är saker du inte behöver oroa dig för på Kinsta.
Om du hittade en lösning som inte finns i vår lista, vänligen lämna en kommentar nedan så lägger vi till den.
Brian har stor passion för WordPress och har använt det i över ett årtionde, han har till och med utvecklat ett par premium-plugins. Brian gillar att blogga, kolla filmer och hiking. Ta kontakt med Brian via Twitter.
Lämna ett svar