Den ultimata guiden för att lösa 500 interna serverfel och tomma vita sidor i WordPress
Annons
500-internserverfelet är det mest användbara fältet för WordPress-användare överallt. Det är ett catch-all-felmeddelande som betyder exakt: någonting gick fel. Ännu värre kan din WordPress-webbplats inte visa några fel alls och bara visa en tom vit sida.
Så hur kan du ta reda på exakt vad som är fel och fixa det?
Först: panikera inte, för det är vanligtvis en enkel fix! Sedan: följ denna felsökningsprocess så kommer ditt WordPress Internal Server Error att åtgärdas på nolltid.
Orsakar WordPress-plugins fel 500?
Om du just har installerat ett nytt plugin eller om din webbplats visar ett 500-fel efter en kärn WordPress-uppgradering, är den mest troliga orsaken en inkompatibel plugin. Det finns många skäl till att ett plugin kan brytas:
- WordPress kan ha tagit bort vissa kärnfunktioner som pluginprogrammet använder.
- Det kan ha kodats för en gammal version av PHP och inte uppdaterats på flera år.
- Det kan bara kodas fel, till exempel att hänvisa till standarddatabasnamn snarare än att använda prefix. Vi är alla skyldiga till lat kodning ibland!
Det är enkelt att identifiera plugin om du just har installerat en och felet just har uppstått. Men hur kan du inaktivera plugin om administratörsområdet är otillgängligt? Och vad händer om du inte ens vet vilken plugin som orsakade felet? Du behöver FTP-åtkomst i båda fallen, men en webbaserad filhanterare från CPanel eller Plesk fungerar också bra.
Lösning:
Vet du exakt vilket plugin som går sönder? Hitta plugin och ta bort den från wp-content / plugins / mappen. Du bör nu kunna logga in igen. Hitta ett alternativ för vilken funktionalitet du ville ha.
Om du inte är säker på vilket plugin som orsakade felet bör du byta namn på hela wp-content / plugins / mappen själv. Placera en understruk (“ _ ”) framför så att den heter _plugins .
Genom att byta namn på mappen aktiverar du effektivt varje plugin på en gång. Du borde nu kunna logga in igen, men kommer att hälsas av en lista med felmeddelanden från WordPress som säger "Plugin iets.php har inaktiverats på grund av ett fel: Plugin-filen finns inte."
Oroa dig inte, du har inte tappat några inställningar. Plugin-inställningar lagras i databasen, och de flesta plugins hittar dem igen efter återaktivering.
Därefter byter du tillbaka mappen igen, genom att ta bort understrecket. De kommer alla att visas på din plugins-sida, men i ett inaktiverat tillstånd. Du kan nu aktivera dem en efter en tills du hittar den skyldige.
När webbplatsen kraschar igen, upprepa processen, men den här gången aktiverar inte den trasiga plugin igen!
500 Internt serverfel: Inkompatibelt tema
Inaktivering av plugins hjälpte inte? Det kan vara något att göra med ditt tema då. Precis som plugins kan du tvinga inaktivera det aktiva temat genom att helt enkelt byta namn på dess mapp, som du hittar i wp-innehåll / teman / katalogen.
Om du fortfarande inte kan komma åt adminområdet efter att du försökt byta namn på både plugins och ditt aktuella tema, bör du fortsätta med ytterligare steg. Om du kan logga in, kommer WordPress att varna dig om att det går tillbaka till ett standardtema. För närvarande kan du antingen hitta ett nytt tema, kontakta temautvecklaren för hjälp eller försöka fixa det själv.
För att fixa det själv, eller för att ge ytterligare förklaring till utvecklaren, se avsnittet senare om Aktivera WordPress Debug Mode .
500 Internt serverfel: Dålig .htaccess-fil
Om avaktivering av dina plugins och teman inte uppnådde någonting, är det möjligt att din .htaccess- fil skadades på något sätt. Detta är vanligtvis fallet om du fortfarande kan komma åt administratörsområdet på webbplatsen, men gränsen fungerar inte korrekt.
.Htaccess-filen hanterar konverteringen av permalänk (vackra versioner av en URL som / min-blogg-inlägg ), till WordPress 'interna fula URL-schema (den du får som standard, som ser ut som /? P = 12345). Det är en kritisk del av WordPress, men plugins kan ibland röra det.
Lösning:
Återigen, gå över till din FTP-klient eller filhanterare. Byt namn på .htaccess- filen i roten till din WordPress-installationskatalog till något liknande .htaccess_old . Om du faktiskt inte kan se filen där måste du aktivera visning av dolda filer - den exakta metoden att göra som kommer att variera beroende på din FTP-klient.
Perioden i början av filnamnet är ett sätt att säga ”dölj den här filen” i Linux och andra UNIX-liknande system.
När du har bytt namn på den nuvarande .htaccess, gå tillbaka till administrationsområdet för WordPress, gå sedan till Inställningar> Permalänk och, utan att göra några ändringar, tryck på spara. Detta genererar automatiskt en ny fungerande version av filen.
Om du gjort några ändringar i filen manuellt kommer de att gå förlorade (men du bör ändå inte redigera filen för hand).
Aktivera WordPress-felsökningsläge för att spåra fel
Vi kan aktivera en felsökningslogg från WordPress-konfigurering, vilket kan ge en ledtråd om det exakta problemet, men just nu är du själv. Du måste ta reda på hur du fixar det, vilket kräver kodningskunskaper.
För att aktivera felsökningsloggen öppnar du wp-config.php, som du hittar i rotkatalogen för din WordPress-installation. Var mycket noggrann med att redigera den här filen: det kan vara en bra idé att först göra en kopia som du kan återställa i fall oavsiktliga förändringar.
Hitta raden som säger:
define('WP_DEBUG', false); Om din webbplats inte besöks ofta och inte har något emot felmeddelandena som visas för alla, ändra bara ordet falskt till sant . Felmeddelanden visas nu när du laddar webbplatsen.
Om du hellre vill hålla felmeddelandena privata, kommentera den raden genom att skriva // i början och klistra in följande under den:
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); Detta kommer att börja mata ut fel till en fil i wp-innehållsmappen kallad error.log . Om du uppdaterar FTP-klienten och ser ingenting efter en minut eller så är det möjligt att WordPress inte har behörighet att skapa filen. Skapa manuellt en ny error.log-fil och ge den tillstånd 666.
Varning: den här filen kommer att fortsätta att bli större tills du tar bort de raderna från din config. Glöm inte att ta bort den ursprungliga linjen också. Läs filen i valfri textredigerare och kontrollera om det finns kritiska PHP-fel.
I exemplet ser jag en hel del PHP-meddelanden om föråldrad kod, men dessa kommer faktiskt inte att bryta en webbplats.
500 Internt serverfel: Serverfelskonfiguration
Att köra din egen virtuella privata server är inte lätt. En gång stod jag inför ett mystiskt fall av ungefär hälften av alla sidbelastningar som visar ett 500-fel, men utan märkbart mönster och inga ledtrådar i serverfelloggarna. Att aktivera WordPress-felsökningsloggar visade inte heller något uppenbart: massor av PHP-meddelanden och avskrivningar, men inget kritiskt.
Slutligen insåg jag att jag hade installerat APC-caching på servern helgen innan för att använda W3 Total Cache för att påskynda webbplatsen. Avinstallering som raderade de 500 felen helt.
Min poäng är att 500-felet helt enkelt kan vara en kombination av serverkonfigurer som ger en inkompatibilitet. Det är osannolikt om du använder hanterade tjänster, men med din egen virtuella privata server (vad är en virtuell server, och varför du kanske vill ha en vad är en virtuell server, och vad kan du göra med en? Vad är en virtuell server, Och vad kan du göra med en? Virtuella maskiner och virtuella servrar - vad är de och hur skiljer de sig? Läs mer) Du är ansvarig för att allt fungerar tillsammans, och det är svårare än det låter.
Är din webbplats tom för minne?
På en delad värd kan det hända att PHP-minnesgränsen träffas - WooCommerce, forum eller relaterade inläggsplugins kan orsaka detta på grund av deras komplexitet. Om du har tur ser du ett felmeddelande som "Fatal Error: Tillåtet minnestorlek på xxx bytes uttömt" men inte alltid.
Du kanske kan fixa detta genom att lägga till följande rad i din wp-config.php :
define('WP_MEMORY_LIMIT', '64M'); De flesta delade värdar låter dig faktiskt inte öka minnesgränsen - du får det du får. Det kan vara dags att överväga andra former av webbhotell De olika formerna av webbhotell förklarade [Teknologi förklarat] De olika formerna av webbhotell förklarat [Teknisk förklarad] Läs mer.
500 fel fixat? Gör nu säkerhetskopior dagligen!
Det bästa försvaret mot alla slags kritiska WordPress-fel är att upprätthålla dagliga säkerhetskopior samt en manuell säkerhetskopiering före varje betydande åtgärd (som en viktig WordPress-uppdatering). Håll också plugins och teman uppdaterade: nya versioner av WordPress bryter ofta gammal kod.
Det kan vara skrämmande när din webbplats går sönder - särskilt om det är en inkomstkälla för dig och inte bara en hobby. Genom att följa den här guiden och vara metodisk bör du få den tillbaka snart igen.
Överväg att uppgradera till en hanterad WordPress-värdstjänst som hanterar säkerhetskopieringar och optimeringar för dig och gör sådana fel obefintliga. Vi rekommenderar InMotion Hosting (använd den här länken för att få 38% rabatt) och Bluehost (använd den här länken för att få 25% rabatt).
Utforska mer om: Wordpress, Wordpress Plugins.
