Ik zal je vertellen waarom wordpress wit scherm verschijnt en hoe je dit kunt oplossen. Een beginnende blogger doet graag alles zelf, kiest het onderwerp en de motor, omdat hij geen geld wil investeren.
Redenen waarom wordpress wit scherm verschijnt
Ik zal je de redenen vertellen voor hoe het witte wordpress-scherm wordt gevormd. Dit zijn de belangrijkste fouten.
- Zonder API-kennis beginnen ze het function.php-bestand te bewerken, dit is het hoofdthema-bestand dat de hele sjabloon regelt.
- Ze bewerken themabestanden in de standaard WordPress-editor, wat niet kan. Nadat het bestand is opgeslagen via een standaardeditor, wordt het hele pad van bewerkingen gewist en als de sjabloon vastloopt, helpt niets.
- Plug-in geschil. Bij het laden van een nieuwe plug-in kan er een geschil ontstaan tussen een van de geïnstalleerde plug-ins.
- Een nieuw thema installeren. Het gebeurt zelden, vooral wanneer een thema met geweld wordt gedownload en geactiveerd via ftp.
- Na het overdragen van de bron, is het beter om dergelijke dingen aan het hostingpersoneel toe te vertrouwen.
- Eigenlijk is dit extra zelfvertrouwen bij het programmeren, ik weet wat een div is, dus ik ga alles zelf doen.
- Na het updaten van de wordpress engine zijn de updates de laatste tijd grilliger en schever.
Maak een back-up, hoe vaker hoe beter, ik doe het om de drie dagen.
Een korte lijst, er kunnen meer redenen zijn. Vervolgens zal ik de populaire technieken voor het elimineren van het witte scherm bekijken.
Ten eerste: fouten in de code
Gemaakt door de blogger zelf.
Maak altijd, voordat je gaat klimmen, back-ups van de site, of het thema zelf en databases. Dit is de eerste regel, maar niemand houdt zich eraan, dus als er geen back-up is, gaan we verder met de oplossing.
Je hebt toegang tot het admin paneel van WordPress.
Om dit te doen, opent u de editor en lost u het probleem op, dat wil zeggen dat we de code naar de oorspronkelijke versie brengen en opslaan. U moet altijd weten en onthouden wat er in de sitecode is gewijzigd en op welke plaats. In ieder geval kan alleen een fout in het funktion.php-bestand kritiek zijn, hij is het meest grillig. 
U kunt het beheerderspaneel niet openen.
- Wij doen het via ftp. We gaan via ftp-kanaal naar de hosting en zoeken de bestand(en) die gewijzigd zijn. Een pad als dit is public-html-> wp-content-> thema's-> je actieve thema.
We vinden het bestand om te bewerken, wijzigen het en uploaden het terug naar de hosting.
Er zijn nog steeds problemen: ga naar de hosting en vraag de ondersteuningsdienst, zij kunnen helpen het te repareren. Of maak een simpele back-up. Bij normale hosting worden kopieën van de site en databases minimaal 3 dagen bewaard.
Plugin geschil en wit scherm in admin gebied
Plug-in controverse is de belangrijkste reden voor het witte scherm op WordPress. Dit wordt waargenomen op die blogs die beheerders erg graag plaatsen. Er zijn situaties waarin plug-ins groter zijn dan 40, dit is niet toegestaan.
U kunt naar het beheerderspaneel gaan
Het komt zelden voor dat de plug-in vastzit en u het beheerderspaneel kunt openen. Je hebt de plug-in geïnstalleerd en de blog blijft hangen, je moet de nieuwe ingeschakeld laten en de rest één voor één uitschakelen om erachter te komen waar het geschil aan de hand is. Dat wil zeggen, ze hebben er een uitgeschakeld, vervolgens naar de blog overgeschakeld, als het niet hielp, dan weer terug naar het beheerderspaneel enzovoort, totdat je erachter bent gekomen waar het argument over gaat.
Er is geen toegang tot het beheerderspaneel
Dit geval is waarschijnlijker. Om het probleem op te lossen, hebt u het volgende nodig:
Als de blog is gestart, is deze plug-in de schuldige. Dus degene die het laatst is verwijderd, dat wil zeggen, we verwijderen de map van de hosting. 
Er is een andere manier:
Zo weet je direct wat er precies in de weg staat.
Kromme thema
In zeldzame gevallen raad ik je aan om thema's alleen van vertrouwde bronnen te downloaden. Als de blog vastloopt en het scherm van de dood verschijnt vanwege een nieuw onderwerp, dan raad ik je aan dit te doen.
Je hebt toegang tot de console
Verander het actieve onderwerp in een ander.
Als je een ander thema activeert, verwijder deze dan onmiddellijk en scan WordPress op virussen.
Geen consoletoegang
Sommigen zullen zeggen dat je dit niet kunt doen, alles gebeurt automatisch op nieuwe versies van WordPress. Na het verwijderen van het actieve thema, niet via het admin-paneel, zal de site werken.
Debug-modus inschakelen
Als de vorige stappen niet hebben geholpen, moet je erachter komen wat de reden is van WordPress zelf. Dat wil zeggen, u moet de foutopsporingsmodus inschakelen, die in geval van een fout een hint zal weergeven in plaats van leeg te zijn.
1 manier
Dat wil zeggen, er is een fout in index.php in de vierde regel.
2 wegen
Als er geen fouten zijn verschenen, maar bewerk het wp-content.php-bestand verder, vóór de zin / * Dat is alles, bewerk het niet verder. Veel geluk! * / zet de combinatie.
Ini_set ("display_errors", 1);
Het zou er zo uit moeten zien. Sla het op en download het terug.
3 manier
Je ziet direct wat er kapot is. Maar standaard bij het hosten kan deze modus worden uitgeschakeld, en het bewerken van wp-content zal niet helpen. Dan moet je .htaccess downloaden en deze regels eraan toevoegen. Opslaan en terug uploaden naar de site.
Php_flag log_errors aan
Voer deze stappen in die volgorde uit om fouten te voorkomen.
Verhoogde geheugendump
In sommige gevallen kan een dergelijke fout optreden na het inschakelen van foutopsporing.
Dit betekent dat het toegewezen RAM-geheugen niet voldoende is en moet worden verhoogd. Er zijn drie manieren, allemaal gerelateerd aan ftp, dus ga rechtstreeks naar de bestandsbeheerder en download het eerste bestand.
- Download het bestand wp-config.php en plak deze code erin. We hebben het opgeslagen en bijgewerkt, als het niet helpt, ga je gang. definiëren ("WP_MEMORY_LIMIT", "64M");
- Download het .htaccess-bestand en voeg de combinatie eraan toe. php_value memory_limit 64M
- Op hostingsites waar een bundel met nginx is, kun je het proberen via het php.ini-bestand, het zou in de root van de site moeten staan, dat wil zeggen, samen met de mappen wp-content en wp-admin. Als het er niet is, dan creëren we, en zetten we deze combinatie erin. geheugenlimiet = 64M;
Als al het andere faalt, nemen uw nieuwe thema's en plug-ins veel geheugen in beslag. De belangrijkste reden is misschien een overvloed aan gedownloade thema's en actieve plug-ins, die al het actieve RAM-geheugen opslokken.
Om deze theorie te testen, schrijft u naar de hoster om de fout- en overbelastingslogboeken te controleren en u te informeren, of u kunt het zelf controleren als u kunt. Aan het einde van het filmpje.
Nu heb je geleerd waarom het witte scherm van WordPress verschijnt en hoe je er vanaf kunt komen. De belangrijkste reden zijn de scheve handen van beginners in 90% van de gevallen.
Grote online winkel op basis van WordPress en WooCommerce plugin. Volgens de klant: "Hij werkte, hij werkte, en vandaag begon hij naar het admin-paneel te gaan, maar daar is niets. Het is niet opgenomen in de kortere." Nou, als het niet is inbegrepen, is dit een echt probleem, maar met het admin-paneel kon ik het niet laten, trollen is leuk. Denk niet, ik heb de klant dit niet verteld en ik raad je niet aan om ze te trollen, je moet weten dat ze per definitie jouw en mijn humor niet begrijpen. Over het algemeen is het probleem dat we in plaats van een handig en mooi CMS WordPress-beheerderspaneel een wit scherm van de dood hebben (dit is niet mijn idee, zo wordt het op het net genoemd).
Dus de cliënt rent en trekt aan de haren op zijn hoofd, wiens verhaal zwijgt. De site, en trouwens een online winkel met een maandelijkse omzet van anderhalf miljoen roebel, lijkt te werken, maar wanneer je het admin-paneel betreedt, verschijnt er een wit scherm van de dood en dat is het. Alles, dit is echt alles, geen interessante berekeningen voor u in de console, noch enige uitvoer van waarschuwingen en foutmeldingen voor u. De site zelf is gemaakt, zoals ik hierboven schreef, op WordPress met behulp van de WooCommerce-plug-in.
Je raadt het al wat ik als eerste deed. Precies, dus ik ging naar de configuratie en zette de foutopsporingsmodus aan. Dit gebeurt eenvoudig, we klimmen via FTP naar de root, of waar het bestand daar verborgen is wp-config.php en open het om te bewerken. Er is een speciale regel die de vereiste constante instelt voor de CMS WordPress, in feite is het voldoende om te veranderen vals Aan waar... En nu is de foutopsporingsmodus ingeschakeld.
Welnu, als u om de een of andere reden niet zo'n regel hebt, aarzel dan niet om deze zelf toe te voegen. U kunt daar ook dergelijke regels toevoegen:
Definieer ("WP_DEBUG_DISPLAY", false); definiëren ("WP_DEBUG_LOG", waar);
Dan heb je een bestand aangemaakt debug.log bij papa wp-inhoud en alle gedetecteerde fouten worden daar geschreven. Zoals je misschien al geraden hebt, schakelt de eerste regel de weergave van fouten in de browser uit en de tweede regelt de invoer van het bovengenoemde foutenlogboek.
Trouwens, wie wist het niet, ken nu de verhuizerWordPress is een slimme engine, het maakt het gemakkelijk om je configuratiebestand een beetje te verbergen. Standaardwp-configuratiephp bevindt zich in de root, maar u kunt het naar een hoger niveau verplaatsen, dat wil zeggen, het volledig uit de openbare map verwijderen. De hoofdmap van uw site heeft bijvoorbeeld het pad<доменное имя сайта>/ openbaar_html /. We nemen en dragen het bestand over vanopenbaar_html naar een map één niveau hoger, dat wil zeggen<доменное имя сайта>... Verder een sluwe verhuizerWordPress doet het allemaal. In zekere zin, als hij het bestand niet in de root vindt, zal hij, niet al te verbaasd over dit feit, naar een hoger niveau kijken, waar er geen openbare toegang is vanaf het netwerk, en ziedaar, hij zal daar de bestand dat we daar veilig hebben verstopt.
Grote informatieve voetnoot, nou, ik kon niet zwijgen, mee eens, dit is nuttige informatie! Oké, laten we doorgaan, deze acties leverden niets op, er waren geen fouten, om zo te zeggen, het witte scherm van de dood WordPress, ik was het niet die het zo noemde, het werd zo genoemd op de enorme uitgestrektheden van het internet, was onwrikbaar en symboliseerde nog steeds de uitdrukking " Al het leven is as".
Nou, ik ben een vrolijke go ... persoon, ja, zomaar, ik besloot om aan de andere kant naar de foutenlogboeken te kijken via de hosting. Ja, ja, hosting heeft zo'n functie. Eigenlijk heb ik het loggen van alle fouten aangezet, het witte scherm een paar keer bijgewerkt en geklommen om te zien wat ik interessant vond in de logs. Stel je mijn verbazing voor dat ook daar leeg was, dat wil zeggen, echt helemaal leeg, zoals ze zeggen, geen enkele vlieg zat.
Maar als we iets slechts doen, zijn we niet te stoppen, het belangrijkste is om aan het eind geen koekje te eten, anders wordt het 's ochtends slecht.
Verwijderingsmethoden voor WordPress White Screen
Normale methoden hielpen niet, ik ging verder met abnormale. En hij was het die het nummer 1 nam en toevoegde in de naam van de map met plug-ins in de map wp-content. Waarom zo, nou, je bent het niet vergeten, we proberen in het beheerderspaneel te komen. Hier, en je kunt alle plug-ins tegelijk uitschakelen, zijn er drie manieren, via het admin-paneel, degene die ik heb gebruikt (het is sneller en gemakkelijker) en de derde door phpMijnAdmin.
Een paar woorden over de derde methode, ja, ja, nogmaals, ik kan het niet laten en moet het je vertellen. Maar dit is voor jou! Het maakt niet uit dat je het niet gebruikt, maar je zult het weten. We gaan naar de database (oh ja, dit is het, dezelfde database waar je geen contact mee wilde hebben, en die je altijd bang maakte met drie letters SQL) en daar voeren we, op het tabblad SQL-query's, de volgende regel in:
UPDATE wp_options SET option_value = "" WHERE option_name = "active_plugins";
Of ga aan tafel wp_option kijk daar in de kolom optienaam, lijn active_plugins... En nu, in deze regel, wissen we de inhoud van de cel option_value. Ik raad je aan om het met pennen te doen, zonder een SQL-query te gebruiken, daar zul je de grote geheimen van JSON ontdekken, namelijk daarin slaat de sluwe WordPress gegevens op in de bovengenoemde cel van zijn database. Puur uit nieuwsgierigheid om te zien, als er geen wens is, gebruik dan een SQL-query.
Over het algemeen heb ik de plug-ins uitgeschakeld en niets, opnieuw een wit scherm, en de site werkte nog steeds niet. Ja, ja, het gebeurt wanneer u plotseling alle plug-ins in één keer afsnijdt. Maar zoals je je herinnert, heb ik de tweede methode gebruikt en door een simpele manipulatie heb ik alle plug-ins opnieuw gelanceerd. En oh, wonder, de site begon weer te werken, maar niet het admin-paneel, dat wil zeggen, we kwamen waar we begonnen. Wit scherm en zijn sacramentele "Al het leven is verval". Maar, zoals je je herinnert, ben ik een opgewekte go ... persoon. Ik besloot niet verder te graven, ik kon netjes een kleine code toevoegen aan het admin.php-bestand en toch de infectie vinden die aanleiding gaf tot het witte scherm. En ik zou dit hebben gedaan, maar de klant zei dat er een wit scherm verscheen nadat de site was overgebracht naar een nieuwe hosting, waar het veilig werkte en alles werkte terwijl de antivirus op de hosting stond (trouwens, het was verwekt, maar ze hebben daar een gratis antivirusprogramma, ik vind het ook leuk, er zijn over het algemeen veel goede dingen, ik raad het aan) heb niet gezegd dat er een virus is gevonden en het is noodzakelijk om het te behandelen door de kwaadaardige code uit het bestand te verwijderen (van welke hosting de site is overgedragen, om voor de hand liggende redenen zal ik zwijgen, ik zal zeggen dat het groot en solide is, en zeer bekend). Nou, de klant was het daar natuurlijk mee eens en de code werd verwijderd. Maar het probleem met alle antivirussen is dat ze niet alleen kwaadaardige code verwijderen, maar ook de code vasthaken die nodig is, maar beschadigd is door de ingesloten code.
In het licht van de nieuwe informatie stopte ik met dansen met een tamboerijn en het zingen van sjamanistische deuntjes, anders waren ze al thuis, ze begonnen me argwanend aan te kijken en wierpen argwanende blikken op de telefoon. En ik besloot om, figuurlijk gesproken, een club te gebruiken, nou, dit is een van oorsprong Russische manier om fijne elektronica te repareren. Namelijk om de WordPress-engine opnieuw te installeren, maar niet op een eenvoudige en toegankelijke manier, maar op een handmatige manier, ja, hoewel we een club gebruiken, zal de klant niet blij zijn als we " We branden en de hele wereld ligt in het stof"(c) DMB.
Trouwens, vriend, ik hoop dat je al in het stadium was tussen het accepteren van een bestelling van een klant en het doorzoeken van de sitebestanden, de moeite nam om een BACKAP te maken van de sitebestanden en de bijbehorende database, of de klant dwong om het te doen . Zo niet, dan wil ik geen slechte woorden zeggen, doe het gewoon nu! En in de toekomst, wat je ook doet met de site van de klant, maak altijd eerst een back-up. Verander de code in het bestand, behoud het originele bestand, hernoem het gewoon, voeg het _ voorvoegsel toeoud of iets anders, je zou het op het niveau van een onbewuste reflex moeten hebben.
Maar terug naar onze handmatige WordPress-update. Hier gaat alles gewoon hier kantoor. WordPress-site en download de distributiekit, onze motor. We pakken het resulterende archief uit op onze computer. Vervolgens openen we de bestanden van onze site via FTP (ik gebruik WinSCP, ik gebruikte FileZilla) en daar verwijderen we twee mappen dit wp-admin en wp-inclusief... De rest raken we niet aan, onthoud, het is niet onze taak om te laten zien hoe cool we zijn, maar om te doen wat de klant wil, hij heeft als het ware altijd gelijk. En dan kopiëren we alles uit de uitgepakte distributiekit, terwijl we ermee instemmen alles te vervangen wat hij daar wil veranderen, geloof me, hij weet wat en waar hij moet veranderen, dus laat hem het veranderen. Het enige dat overblijft is om naar het admin-paneel te gaan en te controleren of alles daar is. Ja, het admin-paneel zal hoe dan ook werken na zo'n onzedigheid die we hebben gedaan. Het doel is bereikt, goed voor jou en voorspoed!
Laten we eens kijken naar verschillende redenen voor het witte WordPress-scherm bij de ingang van de site en oplossingen die het probleem van de dood van de beheerder binnen een paar minuten zullen oplossen.
Deze engine werkt feilloos, en als er iets met je is gebeurd, kan de reden zijn je eigen fouten bij het schrijven van code in afzonderlijke bestanden, incompatibiliteit van plug-ins of thema's, weinig geheugen bij de hoster, het werk van caching-plug-ins.
Wit scherm in plaats van een website - wat te doen?
Je hebt je gebruikersnaam en wachtwoord ingevoerd, maar in plaats van het bekende admin-paneel zie je alleen een wit scherm. Wat betekent dit? Het script kan om de 5 bovenstaande redenen niet worden uitgevoerd en het is heel goed mogelijk dat er andere zijn. En voor elk geval is er een snelle oplossing.
Wat te controleren wanneer het witte scherm van de dood in WordPress verschijnt
- Het eerste waar u naar moet kijken, zijn uw recente acties. U hebt een plug-in, thema geïnstalleerd of bijgewerkt. Of ze hebben een nieuw item aan het bestand toegevoegd met een fout.
- Het is gemakkelijk om te controleren of een plug-in defect is. Het is voldoende om de map met plug-ins op de server te hernoemen en opnieuw te proberen het beheerderspaneel te openen. Je hoeft ze helemaal niet te verwijderen. Als het probleem niet is opgelost, is dit niet het geval. Zet de map terug naar de oorspronkelijke naam.
- Als je bijvoorbeeld een bestand hebt toegevoegd aan het function.php-bestand van een child-thema, controleer dan of het bestand correct is geschreven en gecodeerd. Slechts één vinkje kan een witte afbeelding oproepen in plaats van een website.
- Het kan ook gewoon een cache zijn. Schoon
- Nog een reden: de hostingprovider wijst weinig PHP-geheugen toe en de scripts hebben niet genoeg geheugen om te draaien. Wijzig in dat geval het tariefplan of ga naar een andere hosting. U kunt, indien toegestaan, ook schrijven in het .htaccess-bestand php_value memory_limit 64M Maar het is beter om contact op te nemen met de ondersteuning van het hostingbedrijf met het verzoek om het PHP-geheugen te vergroten.
Dit aantal is meestal voldoende om scripts te laten werken.
Schrijven van WordPress-logboeken toestaan
Om het gemakkelijker te maken om elk probleem op te sporen, schakelt u tijdens de ontwikkeling het WordPress-logboek in, dat is opgeslagen in de map /wp-content/debug.log
V wp-config.php toevoegen:
Uit mijn ervaring: wit scherm na het aanbrengen van wijzigingen in het .htaccess-bestand
Het is gebruikelijk om nieuwe items aan het .htaccess-bestand toe te voegen. Maar op de een of andere manier kreeg ik een rare storing. Ik heb de regels ingevoerd die al op andere sites zijn gecontroleerd en kreeg een wit scherm voor gebruikers (de beheerder kon in het beheerderspaneel komen en daar werken). Maak deze wijzigingen ongedaan, keerde de oude .htaccess terug en het probleem bleef bestaan. En wat het meest interessante is, geen van de rechten om fouten op het scherm weer te geven werkte. Puur witste en leeg vel!
Als gevolg hiervan heb ik alle bestanden opgeslagen met de cacheconfiguratie op het LAN (zonder dat de caching-plug-ins zijn ingeschakeld) en ze vervolgens van de server verwijderd. En de site kwam tot leven, schreef onmiddellijk fouten dat het cachebestanden nodig had. Ik heb ze teruggestuurd en de site begon als een uurwerk te werken.
Hier is zo'n onbegrijpelijk verhaal. En het meest interessante is dat ik nog steeds regels moet toevoegen aan .htaccess. Maar de situatie herhalen is op de een of andere manier eng.)
Misschien hebben we allemaal minstens één keer te maken gehad met het zogenaamde "witte scherm van de dood" in WordPress na het installeren van een plug-in of het wijzigen van instellingen. Noch inhoud noch admin panel - niets is beschikbaar. Als je bekend bent met de beschreven situatie, dan is dit artikel iets voor jou.
Ik zal je vertellen over alle mogelijke problemen, de meest voorkomende oorzaken van hun optreden, en ook - het belangrijkste - ik zal je oplossingen bieden om je site zo snel mogelijk weer in orde te krijgen.
White Screen of Death (WSOD) wordt bijna altijd geassocieerd met bugs in PHP-code of onvoldoende beschikbaar geheugen. Het eerste dat u moet doen, is bepalen of het beheerdersdashboard werkt of niet. Als de frontend van de website niet wordt weergegeven, maar het admin-paneel werkt, wordt het probleem waarschijnlijk veroorzaakt door een beschadigd thema of een beschadigde plug-in.
Schakel plug-ins en thema's uit
De beste manier om hiermee om te gaan, is door alle plug-ins uit te schakelen. Als dit het probleem helpt oplossen, hoeft u alleen maar de boosdoener te vinden. Begin de plug-in één voor één te activeren door uw site na elke activering opnieuw te laden. Als je frontend niet meer werkt, heb je een problematische plug-in gevonden.
Lukt dat niet, dan kun je tijdelijk overschakelen naar het standaard WordPress-thema. U kunt bijvoorbeeld Twenty Fifteen gebruiken. Als uw site goed werkt, ligt het probleem bij uw thema.
Schakel de foutopsporingsmodus in
Als je site nog steeds niet actief is, of als het beheerdersdashboard niet wil starten (of als je de boosdoener hebt gevonden maar nog dieper wilt graven), kun je de foutopsporingsmodus inschakelen, zodat je eventuele fouten kunt zien.
Het probleem is dat wanneer een fatale fout optreedt, het script gewoon stopt met uitvoeren. Als er een fout optreedt voordat er inhoud wordt weergegeven, ziet u gewoon een wit scherm zonder enige informatie.
Om de foutopsporingsmodus in te schakelen, moet u het bestand wp-config.php van uw WordPress-build openen. Het moet de volgende regel bevatten:
Definieer ("WP_DEBUG", false)
U moet false vervangen door true en vervolgens de site opnieuw laden. In plaats van een wit scherm des doods, krijg je een wit scherm met foutmeldingen. Geen grote verbetering, maar er verschijnen in ieder geval enkele aanwijzingen.
Als je thema's en plug-ins niet hebt uitgeschakeld, kun je erachter komen wie de boosdoener is door simpelweg de foutmelding te bekijken. Het bericht moet aangeven welk bestand de fout heeft veroorzaakt. Voorbeeld:
Kan get_posts () (eerder gedeclareerd in /var/www/html/wordpress/wp-includes/post.php:1874) niet opnieuw declareren in / var / www / html / wordpress / wp-content / plugins / my-test-plugin / mijn-test-plugin.php online 38
Zoals je kunt zien, veroorzaakte regel 38 van een plug-in met de naam "my-test-plugin" het probleem. Schakel deze plug-in uit en alles zou moeten werken.
Tip: als je FTP-toegang hebt of je kunt inloggen op de server via je hostingcontrolepaneel (bijvoorbeeld cPanel), dan kun je alle plug-ins in één keer deactiveren door de map plug-ins te hernoemen naar bijvoorbeeld plug-ins.hold. De map staat in wp-contents.
Als je goed bent met code, kun je proberen de plug-in zelf aan te passen. In het geval van een plug-in uit de officiële repository, raad ik aan deze naar de auteur te schrijven in plaats van zelf te proberen iets te repareren. Wanneer u een plug-in handmatig wijzigt, moet u alle wijzigingen zelf onderhouden, wat een nogal problematische taak is. Het is gemakkelijker om het te deactiveren en te wachten tot de ontwikkelaar het repareert.
Geheugenlimieten verhogen
Als u nog steeds een lege pagina ziet of een bericht ontvangt over onvoldoende geheugen, moet u meer geheugen toewijzen aan de toepassing. Dit kan gedaan worden via het wp-config.php-bestand in de meeste assemblages, voeg gewoon de volgende code toe:
Definieer ("WP_MEMORY_LIMIT", "64M");
Als dat niet werkt, heb je verschillende opties om verder te gaan. In een normale omgeving kunt u uw .htaccess-bestand - dat zich in uw WordPress-hoofdmap bevindt - gebruiken om uw geheugenlimiet te verhogen. Voeg er gewoon de volgende regel aan toe:
Php_value memory_limit 64M
Als je werkt met moderne hosts die Nginx in hun architectuur gebruiken, is het .htaccess-bestand mogelijk niet beschikbaar. In dit geval kunt u het php.ini-bestand gebruiken om de geheugenlimiet te verhogen. Plaats de volgende regel in dit bestand:
Geheugenlimiet = 64M
Als het toegewezen geheugen nog steeds bijna vol is, is er mogelijk een probleem met uw toepassing. De kans is groot dat uw thema of een van uw plug-ins een buitensporige hoeveelheid bronnen gebruikt. Neem contact op met de ontwikkelaars of uw hostingbedrijf om uw SQL-logboeken en brongebruiksstatistieken te bekijken.
Problemen met bestandsrechten oplossen
Het is onwaarschijnlijk dat deze oorzaak leidt tot een wit scherm van de dood, maar het kan nog steeds verschillende problemen veroorzaken.
Voor WordPress gelden de volgende regels:
- Bestanden moeten 664 . zijn
- Mappen moeten 775 . zijn
- Het bestand wp-config.php moet 660 . zijn
Als je SSH-toegang tot je server hebt, kun je de juiste regels afdwingen door de volgende opdracht uit te voeren vanuit je WordPress-hoofdmap:
Sudo vinden. -type f -exec chmod 664 () + sudo vinden. -type d -exec chmod 775 () + sudo chmod 660 wp-config.php
Als je bang bent om zelf iets te veranderen, neem dan contact op met je hosting. Zij zullen het voor u doen. Sommige WordPress-hosts hebben automatische machtigingscontrole, waardoor u alles in een paar seconden kunt instellen.
Problemen oplossen met automatische updates
In zeldzame gevallen kan WordPress updateproblemen tegenkomen, zoals servertime-out. In de regel wordt alles automatisch opgelost, maar in sommige situaties kan dit leiden tot het verschijnen van een white screen of death.
Het eerste dat u in dit geval moet doen, is naar de hoofdmap van WordPress gaan en kijken of er bestandsonderhoud is. Verwijder dit bestand en probeer uw site opnieuw te uploaden. Als de update is gelukt - maar WordPress kon dit bestand niet automatisch verwijderen - wordt alles weer normaal.
Als de update niet is voltooid, kan dit automatisch worden gedaan, waardoor de site weer normaal wordt. Als dit niet helpt, kunt u in dit geval de handmatige updateprocedure doorlopen, waarmee u het probleem voor eens en altijd kunt oplossen.
Het zogenaamde witte scherm van de dood van WordPress is bekend bij veel gebruikers van het platform - dit is een van de meest onaangename situaties die met uw website kunnen gebeuren. Als u een leeg wit scherm ziet wanneer u uw site opent of wanneer u het beheerderspaneel opent, is dit een duidelijk teken.
Meestal verschijnt het na het updaten van WordPress, het installeren of updaten van plug-ins, actief thema, enz. Je kunt natuurlijk terugdraaien door een back-up in te zetten, maar dit is geen oplossing voor het probleem. Er zijn vier manieren om met een wit scherm om te gaan in WordPress.
- Plug-ins controleren;
- PHP-geheugenlimieten verhogen;
- Wijzig het actieve onderwerp;
- Debugger activering.
Aandacht! Voor elke actie is een volledige back-up van uw site en database vereist.
1. Plug-ins controleren
Een defecte of conflicterende plug-in is de meest voorkomende oorzaak van een wit scherm en de gemakkelijkste manier om het probleem op te lossen. De meest voorkomende oorzaak is een geïnstalleerde plug-in die conflicteert met een andere plug-in of actief thema. We moeten uitzoeken wat deze plug-in is en deze deactiveren.
Met consoletoegang
Als je toegang hebt tot het CMS, ga dan naar de sectie Plug-ins en deactiveer de meest recent geïnstalleerde plug-in(s). In 99 van de 100 gevallen lost dit het probleem van het witte scherm op en kun je de site gewoon blijven gebruiken. Maar als het probleem niet is opgelost, schakel dan geleidelijk elke plug-in uit en controleer tegelijkertijd de prestaties van de site. Als het uitschakelen van alle plug-ins het probleem niet oplost - wees niet ontmoedigd, ga naar stap 2.
Geen consoletoegang
Als je geen toegang hebt tot de sitebeheerconsole, maak er dan verbinding mee via FTP met een FTP-client, ga naar de wp-content-map in de hoofdmap van je site en hernoem de map met plug-ins naar een andere naam. Na deze procedure worden alle plug-ins op uw site gedeactiveerd. Controleer de beschikbaarheid van de site in uw browser. Als de site actief is geworden, hernoemt u de map opnieuw naar plug-ins, gaat u naar de sitebeheerconsole en activeert u de plug-ins opnieuw, waarbij u controleert of de site werkt na het activeren van elke plug-in. Laat me je eraan herinneren dat het jouw taak is om erachter te komen welke plug-in het conflict veroorzaakt en om er vanaf te komen. Als het probleem na het deactiveren van alle plug-ins niet is opgelost, ga dan naar de volgende stap.
2. PHP-geheugenlimieten verhogen
wp-config.php bewerken
U heeft opnieuw een FTP-client nodig. We zullen wijzigingen aanbrengen in het WordPress-configuratiebestand. Laat me je eraan herinneren dat het wp-config.php heet en zich in de hoofdmap van je site bevindt. Open het bestand wp-config.php in een teksteditor en voeg deze regel toe:
Definieer ("WP_MEMORY_LIMIT", "64M");
64 MB is de optimale hoeveelheid RAM die nodig is om uw gemiddelde WordPress-site te laten draaien. Het moet duidelijk zijn dat als het maximaal beschikbare RAM-geheugen op uw server minder is dan dit cijfer, of als er meerdere vraatzuchtige sites op de server draaien, u moet overwegen uw tariefplan te wijzigen, extra geheugen te kopen of caching op de site te installeren . Stel ook niet te veel geheugen in, dit kan voor problemen van andere aard zorgen. Als het probleem zich blijft voordoen, gaat u verder.
php.ini bewerken
In de regel heeft niet iedereen er toegang toe. Op dezelfde manier maken we verbinding met de site via een FTP-client en zoeken we naar het php.ini-bestand. Als je het niet hebt gevonden, worden we niet boos en gaan we verder met het volgende item. Indien gevonden, open het en voeg de volgende regel toe:
Geheugenlimiet = 64M;
Opgemerkt moet worden dat als u het bestand niet kunt vinden, het probeert te maken in de hoofdmap van uw WordPress-site.
.htaccess bewerken
Als niet iedereen php.ini heeft, dan hebben alle WordPress-sites zeker .htaccess. Je hebt opnieuw een FTP-client nodig om er te komen en de volgende regel toe te voegen:
Php_value memory_limit 64M
Deze regel initieert dezelfde acties als de vorige twee paragrafen, namelijk verhoogt de hoeveelheid beschikbaar RAM tot 64 MB. Als u het .htaccess-bestand plotseling niet in de hoofdmap van uw site vindt, maak het dan aan en voeg deze regel toe.
3. Wijzig actief thema
Met consoletoegang
Als je toegang hebt tot de content management console, ga dan naar het gedeelte "Uiterlijk" - "Thema's" en activeer een van de standaard WordPress-thema's (bijvoorbeeld 2014 of 2013) en controleer de functionaliteit van je site. Als het witte scherm verdwijnt, zit het probleem in het onderwerp en moet je een debugger gebruiken om erachter te komen wat het precies veroorzaakt.
Geen consoletoegang
Als je geen toegang hebt tot het CMS, dan is de oplossing iets gecompliceerder. Maak eerst verbinding met uw site via een FTP-client en zorg ervoor dat de standaardthema's zijn geladen. Ter herinnering: WordPress-thema's worden opgeslagen in de map wp-content / thema's /. Log vervolgens in op uw hostingconfiguratiescherm, zoek naar PhpMyAdmin, open het en navigeer naar de tabel wp_options. Blader door de optiepagina's totdat u "template" en "stylesheet" vindt. U moet hun waarden vervangen door de naam van de themamap die u wilt activeren. Bijvoorbeeld "twentyfourteen" of "twentythirteen". In het onderstaande voorbeeld kun je zien dat het statfort-thema momenteel is geactiveerd, klik op het potlood en schrijf de naam van een van de standaard WordPress-thema's.
Ververs uw startpagina en hoop op het beste!
4. Activering van de debugger
Log in op de site met uw FTP-client, open uw WordPress-configuratiebestand (wp-config.php) dat u al kent en zoek de volgende regel erin:
Definieer ("WP_DEBUG", onwaar);
En vervang false door true, waardoor de foutopsporingsmodus wordt geactiveerd. Als een dergelijke regel niet in het configuratiebestand staat, voegt u deze toe. Het zou er zo uit moeten zien:
Definieer ("WP_DEBUG", waar);
Open daarna uw site, u ziet alle foutopsporingsinformatie en u kunt eenvoudig bepalen wat de fout precies veroorzaakt. U kunt meer informatie over fouten vinden in de WordPress-codex en PHP-referentie.
Nu weet je hoe je moet omgaan met WordPress White Screen of Death.
Ik hoop echt dat dit artikel je heeft geholpen, maar zo niet, dan kan dat altijd.
Al het nieuwste en meest interessante uit de wereld van Wordpress in mijn Telegram-kanaal. Abonneren!
