Den ultimata guiden för att lösa 500 interna servernfel och tomma vita sidor i WordPress

Den ultimata guiden för att lösa 500 interna servernfel och tomma vita sidor i WordPress / Wordpress & Webbutveckling

500 Internal Server Error är den mest ohjälpliga och obehagliga banan av webbutvecklare överallt. Det är ett catch-all felmeddelande som bokstavligen kan betyda något. Ibland ger din WordPress-webbplats inget fel alls och visar bara en tom sida. Hur på jorden ska du räkna ut vad som är fel??

Det händer med det bästa av oss, men vi behöver inte panik. Här är min egen debug-process, i sannolikhet och med lösningar.

plugins

Om du just har installerat ett nytt plugin eller om din webbplats visar 500 fel efter en grundläggande WordPress-uppgradering, är den mest troliga orsaken ett inkompatibelt plugin. Det finns många anledningar till att plugin är “bruten”:

  • WordPress kan ha tagit bort några kärnfunktioner som plugin använder.
  • Plugin kan ha kodats för en gammal version av PHP, och inte uppdaterad.
  • Det kan bara kodas felaktigt, genom att referera till standard databasnamn istället för att använda prefix.

Identifiering av plugin är lätt om du bara har installerat en och felet har uppstått, men hur kan du inaktivera pluginet om det har tagits ner wp-admin område på din webbplats också? Du behöver FTP-åtkomst, det korta svaret, men den webbaserade filhanteraren från CPanel eller Plesk kommer också att fungera bra.

Lösning:

Allt du behöver göra är att byta namn på wp-content / plugins / mapp. Placera a _ framför plugins mappen, så det heter _plugins, och du ska nu kunna logga in igen till ditt WordPress-administrativa område. Genom att byta namn på mappen avaktiveras de varje plugin - du borde få en massa felmeddelanden från WordPress “X-plugin avaktiverades eftersom filen Y.php inte kan hittas”. Oroa dig inte, du kommer inte att ha förlorat några inställningar - de lagras i databasen, och alla anständiga plugin ska hitta dem igen vid omaktivering.

Byt namn på mappen igen, avlägsna _. Uppdatera WordPress-pluginsna och de kommer alla att listas igen, men i ett deaktiverat tillstånd. Du kan nu återaktivera dem en efter en tills du hittar den skyldige; gör sedan allt igen, självklart lämnar den dåliga plugin den här gången.

Det är olyckligt när det händer, men chansen är att det finns en bättre plugin där ute som är kompatibel. Hitta det.

Oförenlig Tema

Inaktiverade plugins hjälpte inte? Det är förmodligen något i ditt tema då. Precis som plugins kan du tvinga det aktiva temat att bryta genom att bara byta namn på det. Gå tillbaka till WordPress admin-området (om du självklart kan - om du inte kan det är det förmodligen inget att göra med ditt tema) och WordPress kommer att varna dig om att det har fallit tillbaka till standardtemat. Kontrollera webbplatsen igen. Naturligtvis hjälper det inte verkligen om du är engagerad i ett visst tema, så kanske vill du aktivera det och gå vidare till avsnittet om Aktivera PHP Debug; eller bara gå och hitta ett nyare, kompatibelt tema.

Dålig .htaccess

Om deaktivera dina plugins inte uppnådde något och det är inte ditt tema, är det möjligt att din .htaccess filen blev skadad på något sätt. Vanligtvis när det här händer kan du fortfarande komma åt administratörsområdet på webbplatsen. De .htaccess filhanterar omskrivningsregler och cache-inställningar, men ibland redigerar du den här filen direkt för att manuellt koda i saker som 301 omdirigeringar.

Lösning:

Byt namn på .htaccess filen i roten till din WordPress installationsmapp till något liknande .htaccess_old. Om du inte kan se filen där måste du aktivera visning av dolda filer - Den exakta metoden att göra det varierar beroende på din FTP-klient. De “.” i början av filnamnet är ett sätt att säga “göm det här” i Linux och andra UNIX-liknande system.

När du har bytt namn till den aktuella .htaccess, gå tillbaka till WordPress admin-området och gå sedan vidare till inställningar -> permalänkar och, utan några ändringar, slår spara. Detta skapar automatiskt en ny arbetsversion av filen, men ändringar som du gjort manuellt kommer att gå vilse.

Aktivera PHP-debugging

Vi kan aktivera en debug-logg från WordPress config, vilket kan ge en aning om det exakta problemet - men nu är du själv. Du måste ta reda på hur du fixar det, vilket kommer att kräva kodningsförmåga.

För att aktivera felsökningsloggen öppnar du wp-config.php i roten till din WordPress-installation. Hitta raden som säger:

 define ('WP_DEBUG', false); 

Kommentera det med hjälp av // i början och klistra sedan in följande:

 definiera ('WP_DEBUG', true); definiera ('WP_DEBUG_LOG', true); define ('WP_DEBUG_DISPLAY', false); @ini_set ( 'display_errors', 0); 

Detta kommer att börja skriva ut fel i en fil i wp-innehållsmappen som heter error.log. Om du uppdaterar din FTP och ser ingenting efter en minut eller så är det möjligt att det inte är tillåtet att skapa filen. Skapa manuellt en ny error.log-fil och ge den tillstånd 666.

Varnas: den här filen fortsätter att växa till du tar bort de här raderna från din config. Glöm inte att kommentera originallinjen också. Läs filen i vilken textredigerare som helst, och kontrollera eventuella kritiska PHP-fel. I det här exemplet ser jag en hel del PHP-meddelanden om utdaterad kod, men de kommer inte att bryta en webbplats.

Serverkonfiguration

Jag har nyligen haft ett fall där ungefär hälften av alla sidladdningar kom upp som 500, men utan något mönster och absolut ingenting användbart i felloggarna. Att aktivera WordPress-felsökningsloggar visade inget 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 med W3 Total Cache. Avinstallation som helt eliminerade 500 fel.

Min punkt: 500-felet kan helt enkelt vara en kombination av serverkonfigurer som uppvisar en inkompatibilitet. Det här är osannolikt om du använder hanterade tjänster, men med din egen virtuella privata server (varför ska du använda en VPS istället för delad hosting? Varför ska du använda en VPS istället för Shared Hosting för WordPress Varför ska du använda en VPS istället för Shared Hosting For WordPress Read More) du är ansvarig för att se till att allting fungerar tillsammans, och det här är svårare än det låter.

På en gemensam värd kan du hitta PHP-minnesgräns slås på - särskilt komplexa plugins kan orsaka detta. Om du har tur får du ett felmeddelande också i linje med “Fatal Error: Tillåtet minnesstorlek av xxx bytes utmattad”, men inte alltid. Du kanske kan fixa det här genom att lägga till följande rad i din wp-config.php:

definiera ('WP_MEMORY_LIMIT', '64M');

Jag säger Maj, eftersom de flesta delade värdarna inte kommer att låta dig öka minnesgränsen - du tar vad du får. Kanske är det dags att överväga andra former av hosting De olika formerna för webbhotell förklarade [Teknologi förklaras] De olika formerna för webbhotell förklaras [Teknologi förklaras] Läs mer ?

Självklart, om du hade tagit säkerhetskopior innan du körde några uppgraderingar. Så säkerhetskopierar du och återställer din WordPress-webbplats enkelt med UpdraftPlus. Så här säkerhetskopierar du och återställer din WordPress-webbplats enkelt med UpdraftPlus Läs mer du skulle ha en enkel väg till återhämtning. Det är hemskt när din webbplats går ner - speciellt om det är en inkomstkälla för dig och inte bara en hobby - men genom att följa den här guiden och vara metodisk bör du få tillbaka den igen snart.

Har du någonsin haft ett 500 Intern Serverfel eller en tom sida som inte lösts av någon av dessa? Låt oss veta vad ditt problem var och hur du fixade det.

Utforska mer om: Wordpress, Wordpress-plugins.