De ultieme gids voor het oplossen van 500 interne serverfouten en lege witte pagina's in WordPress

De ultieme gids voor het oplossen van 500 interne serverfouten en lege witte pagina's in WordPress / Wordpress en webontwikkeling

De 500 Internal Server Error is de meest onbehulpzame en onopvallende vloek van webontwikkelaars overal. Het is een catch-all foutmelding die letterlijk kan betekenen iets. Soms geeft je WordPress-site helemaal geen fouten en wordt er gewoon een lege pagina weergegeven. Hoe moet je in vredesnaam uitzoeken wat er mis is?

Het overkomt de besten van ons, maar geen reden tot paniek. Hier is mijn eigen debug-proces, in volgorde van waarschijnlijkheid en met oplossingen.

plugins

Als u zojuist een nieuwe plug-in hebt geïnstalleerd of als uw site na een kernupdate met WordPress 500 fouten vertoont, is de meest waarschijnlijke oorzaak een incompatibele plug-in. Er zijn veel redenen voor een plug-in “gebroken”:

  • WordPress heeft mogelijk enkele kernfuncties verwijderd die de plug-in gebruikt.
  • De plug-in is mogelijk gecodeerd voor een oude versie van PHP en is niet bijgewerkt.
  • Het kan gewoon verkeerd worden gecodeerd, door te verwijzen naar standaard databasenamen in plaats van het gebruik van voorvoegsels, bijvoorbeeld.

Het identificeren van de plug-in is eenvoudig als u er zojuist een hebt geïnstalleerd en de fout is opgetreden, maar hoe kunt u de plug-in uitschakelen als deze is verwijderd? wp-admin gedeelte van uw site? U hebt FTP-toegang nodig, is het korte antwoord, hoewel de webgebaseerde bestandsbeheerder van CPanel of Plesk ook goed werkt.

Oplossing:

Het enige dat u hoeft te doen is de naam wijzigen wp-content / plugins / map. Plaats een _ voor de map met plug-ins, dus het heeft een naam _plugins, en u zou nu opnieuw moeten kunnen inloggen op uw WordPress-beheergebied. Door de map te hernoemen, heb je elke plug-in feitelijk gedeactiveerd - je zou een aantal foutmeldingen van WordPress moeten krijgen “X plugin was gedeactiveerd omdat het bestand Y.php niet kan worden gevonden”. Maak je geen zorgen, je zult geen instellingen verloren hebben - die zijn opgeslagen in de database, en elke goede plugin zou ze opnieuw moeten vinden bij opnieuw activeren.

Hernoem de map opnieuw terug, de _ verwijderen. Vernieuw de WordPress-plug-ins en ze worden allemaal opnieuw vermeld, maar in een gedeactiveerde staat. Je kunt ze nu één voor één opnieuw activeren tot je de schuldige vindt; doe het dan allemaal opnieuw, uiteraard zonder de slechte plugin deze keer weg te laten.

Het is jammer wanneer dit gebeurt, maar de kans is groot dat er een betere plug-in is die compatibel is. Vind het.

Incompatibel thema

Het uitschakelen van plug-ins heeft niet geholpen? Het is waarschijnlijk iets in je thema. Net als bij plug-ins, kunt u het actieve thema afbreken door het alleen maar te hernoemen. Ga terug naar het WordPress-beheergebied (als je kunt, natuurlijk - als je het niet kunt, heeft het waarschijnlijk niets te maken met je thema) en WordPress waarschuwt u dat het terugvalt naar het standaardthema. Controleer de site opnieuw. Dit helpt natuurlijk niet echt als je toegewijd bent aan een bepaald thema, dus misschien wil je het opnieuw inschakelen en ga je naar het gedeelte over PHP Debug inschakelen; of ga gewoon op zoek naar een nieuwer, compatibel thema.

Slechte .htaccess

Als het deactiveren van uw plug-ins niets oplevert en het ook niet uw thema is, is het mogelijk dat uw .htaccess bestand is op de een of andere manier beschadigd geraakt. Meestal als dit gebeurt, hebt u nog steeds toegang tot het beheerdersgedeelte van de site. De .htaccess file behandelt de herschrijfregels en cache-instellingen, maar soms zul je dit bestand direct bewerken om handmatig code te maken in zaken als 301-omleidingen.

Oplossing:

Hernoem de .htaccess bestand in de hoofdmap van uw WordPress installatiemap naar iets als .htaccess_old. Als je het bestand daar niet echt kunt zien, moet je inschakelen bekijken van verborgen bestanden - de exacte methode om dat te doen, is afhankelijk van uw FTP-client. De “.” aan het begin van de bestandsnaam is een manier om te zeggen “Verberg dit” in Linux en andere UNIX-achtige systemen.

Zodra je de huidige .htaccess hebt hernoemd, ga je terug naar het WordPress-beheerdersgedeelte en ga je naar instellingen -> Permalinks en sla, zonder wijzigingen aan te brengen, op Opslaan. Hierdoor wordt automatisch een nieuwe werkversie van het bestand gegenereerd, maar alle wijzigingen die u handmatig hebt aangebracht, gaan verloren.

Schakel PHP Debugging in

We kunnen een foutopsporingslogboek inschakelen vanuit WordPress-configuratie, wat een aanwijzing zou kunnen geven over het exacte probleem - maar op dit punt staat u er alleen voor. U moet uitzoeken hoe u dit kunt oplossen, waarvoor codeervaardigheden vereist zijn.

Om het logboek voor foutopsporing in te schakelen, opent u wp-config.php in de hoofdmap van uw WordPress-installatie. Zoek de regel die zegt:

 define ('WP_DEBUG', false); 

Reageer het met behulp van // aan het begin en plak dan het volgende in:

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

Dit zal beginnen met het uitvoeren van fouten naar een bestand in de map wp-content met de naam error.log. Als u uw FTP ververst en na een minuut niets ziet, is het mogelijk dat het geen toestemming heeft om het bestand te maken. Maak handmatig een nieuw error.log bestand aan en geef het toestemming 666.

Wees gewaarschuwd: dit bestand blijft groter worden totdat je die regels uit je configuratie verwijdert. Vergeet ook niet de originele regel van commentaar te voorzien. Lees het bestand in een teksteditor en controleer op eventuele kritieke PHP-fouten. In dit voorbeeld zie ik veel PHP-berichten over verouderde code, maar deze zullen geen echte website breken.

Serverconfiguratie

Ik had onlangs een geval waarin ongeveer de helft van alle pagina-ladingen omhoog kwamen als 500, maar zonder een vastgesteld patroon en absoluut niets nuttigs in de foutenlogboeken. Het activeren van WordPress debug-logboeken toonde niets vanzelfsprekends - veel PHP-berichten en -afschrijvingen maar niets kritisch. Ten slotte besefte ik dat ik het weekend ervoor APC-caching op de server had geïnstalleerd om te gebruiken met W3 Total Cache. Door de installatie ongedaan te maken, zijn de 500 fouten volledig verwijderd.

Mijn punt: de 500-fout kan eenvoudig een combinatie zijn van serverconfigs die een incompatibiliteit vertonen. Dit is onwaarschijnlijk als u managed services gebruikt, maar met uw eigen Virtual Private Server (waarom zou u een VPS gebruiken in plaats van shared hosting? Waarom u een VPS zou moeten gebruiken in plaats van Shared Hosting voor WordPress Waarom u een VPS zou moeten gebruiken in plaats van Shared Hosting For WordPress Read More) bent u verantwoordelijk om ervoor te zorgen dat alles samenwerkt, en dit is moeilijker dan het klinkt.

Op een gedeelde host vindt u mogelijk de PHP-geheugenlimiet wordt geraakt - met name complexe plug-ins kunnen dit veroorzaken. Als je geluk hebt, krijg je ook een foutmelding in de trant van “Fatale fout: toegestane geheugengrootte van xxx bytes uitgeput”, maar niet altijd. U kunt dit mogelijk oplossen door de volgende regel toe te voegen aan uw wp-config.php:

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

ik zeg mei, omdat de meeste gedeelde hosts je niet echt de geheugenlimiet laten verhogen - je neemt wat je krijgt. Misschien is het tijd om andere vormen van hosting te overwegen. De verschillende vormen van website-hosting verklaard [Technology Explained] De verschillende vormen van website-hosting verklaard [technologie verklaard] MEER INFORMATIE ?

Natuurlijk, als je back-ups hebt genomen voordat je upgrades uitvoert. Hoe maak je een back-up en herstel je WordPress-site eenvoudig met UpdraftPlus Hoe maak je back-ups en herstel je WordPress-site eenvoudig Met UpdraftPlus Read More heb je een gemakkelijke route naar herstel. Het is vreselijk als je site ten onder gaat - vooral als het een bron van inkomsten voor jou is en niet alleen een hobby - maar door deze handleiding te volgen en methodisch te zijn, moet je hem snel weer een back-up laten maken.

Heeft u ooit een 500 Internal Server Error of een lege pagina gehad die niet door een van deze is opgelost? Laat ons weten wat je probleem was en hoe je het hebt gerepareerd.

Ontdek meer over: Wordpress, WordPress plug-ins.