Wordpress og webutvikling

Den ultimate veiledningen for å løse 500 interne serverfeil og tomme hvite sider i WordPress

Den ultimate veiledningen for å løse 500 interne serverfeil og tomme hvite sider i WordPress / Wordpress og webutvikling

500 Internal Server Error er den mest unhelpful og nondescript banen av webutviklere overalt. Det er en catch-all feilmelding som bokstavelig talt kan bety hva som helst. Noen ganger gir ditt WordPress-nettsted ingen feil i det hele tatt og viser bare en tom side. Hvordan på jorden skal du finne ut hva som er galt?

Det skjer med det beste av oss, men vi trenger ikke å panikk. Her er min egen feilsøkingsprosess, i sann sannsynlighet og med løsninger.

plugins

Hvis du nettopp har installert et nytt plugin, eller hvis nettstedet ditt viser 500 feil etter en kjernen WordPress-oppgradering, er den mest sannsynlige årsaken et inkompatibelt plugin. Det er mange grunner til at et plugin er “gått i stykker”:

  • WordPress kan ha fjernet noen kjernefunksjoner som plugin bruker.
  • Pluggen kan ha blitt kodet for en gammel versjon av PHP, og ikke blitt oppdatert.
  • Det kan bare være kodet feil, ved å henvise til standarddatabasenavn i stedet for å bruke prefikser, for eksempel.

Å identifisere plugin er enkelt hvis du nettopp har installert en og feilen har dukket opp, men hvordan kan du deaktivere pluginet hvis det er tatt ned wp-admin område på nettstedet ditt også? Du trenger FTP-tilgang, er det korte svaret, selv om den webbaserte filbehandleren fra CPanel eller Plesk vil fungere bra også.

Løsning:

Alt du trenger å gjøre er å gi nytt navn til wp-innhold / plugg / mappe. Plasser a _ foran plugin-mappen, så den heter _plugins, og du bør nå kunne logge på nytt til WordPress admin-området. Ved å gi nytt navn til mappen, deaktiveres du effektivt hver plugin - du bør få en rekke feilmeldinger fra WordPress “X-plugin ble deaktivert fordi filen Y.php ikke kan bli funnet”. Ikke bekymre deg, du vil ikke ha mistet noen innstillinger - de lagres i databasen, og et anstendig plugin burde finne dem igjen ved reaktivering.

Gi nytt navn til mappen tilbake igjen, fjerner _. Oppdater WordPress-pluginene, og de vil alle bli oppført igjen, men i en deaktivert tilstand. Du kan nå gjenaktivere dem en etter én til du finner skyldige; så gjør alt igjen, åpenbart å forlate det dårlige plugin denne gangen.

Det er uheldig når dette skjer, men sjansene er at det er en bedre plugin der ute som er kompatibel. Finn det.

Inkompatibelt tema

Deaktivere pluginene hjalp ikke? Det er sannsynligvis noe i temaet ditt da. Akkurat som plugins, kan du tvinge det aktive temaet til å bryte ved å bare omdøpe det. Gå tilbake til WordPress admin-området (Hvis du kan, selvfølgelig - hvis du ikke kan det, er det sannsynligvis ingenting å gjøre med temaet ditt) og WordPress vil varsle deg om at det er falt tilbake til standardtemaet. Sjekk siden igjen. Selvfølgelig hjelper dette ikke virkelig hvis du er forpliktet til et bestemt tema, så kanskje du vil aktivere den og gå ned til delen om Aktiverer PHP Debug; eller bare gå og finn et nyere, kompatibelt tema.

Dårlig .htaccess

Hvis deaktivering av pluginene dine ikke oppnådde noe, og det er heller ikke ditt tema, er det mulig at din .htaccess filen ble ødelagt på noen måte. Vanligvis når dette skjer, kan du fortsatt få tilgang til administrasjonsområdet på nettstedet. De .htaccess filhåndterer omregningsregler og hurtigbufferinnstillinger, men noen ganger vil du redigere denne filen direkte for å manuelt kode i ting som 301 omadresser.

Løsning:

Gi nytt navn til .htaccess fil i roten av WordPress installasjonsmappen din til noe som helst .htaccess_old. Hvis du ikke kan se filen der, må du aktivere visning av skjulte filer - Den eksakte metoden for å gjøre det vil variere i henhold til FTP-klienten din. De “.” ved starten av filnavnet er en måte å si på “gjem dette” i Linux og andre UNIX-lignende systemer.

Når du har omdøpt nåværende .htaccess, gå tilbake til WordPress admin-området, og deretter gå over til innstillinger -> Permalinks og uten å gjøre noen endringer, trykk på lagre. Dette genererer automatisk en ny arbeidsversjon av filen, men eventuelle endringer du har gjort manuelt, vil gå tapt.

Aktiver PHP-feilsøking

Vi kan aktivere en feilsøkingslogg fra WordPress config, som kan gi en anelse om det nøyaktige problemet - men på dette tidspunktet er du alene. Du må finne ut hvordan du kan fikse det, som vil kreve kodingsevner.

For å aktivere feilsøkingsloggen, åpner du wp-config.php i roten til WordPress-installasjonen din. Finn linjen som sier:

 define ('WP_DEBUG', falsk);

Kommenter det ut med // i starten, og lim deretter inn følgende:

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

Dette begynner å skrive ut feil til en fil i wp-innhold mappen kalt error.log. Hvis du oppdaterer FTP og ser ingenting etter et minutt eller så, er det mulig at det ikke har tillatelse til å opprette filen. Opprett en ny error.log-fil manuelt og gi den tillatelse 666.

Vær advart: denne filen fortsetter å vokse til du fjerner disse linjene fra konfigurasjonen din. Ikke glem å uncomment den opprinnelige linjen også. Les filen i et tekstredigeringsprogram, og kontroller eventuelle kritiske PHP-feil. I dette eksemplet ser jeg mange PHP-meldinger om utdatert kode, men disse vil faktisk ikke bryte et nettsted.

Serverkonfigurasjon

Jeg har nylig hatt en sak hvor omtrent halvparten av alle sidelastene kom opp som 500, men uten innstilt mønster og absolutt ingenting nyttig i feilloggene. Aktivering av WordPress-feilsøkingslogger viste ingenting åpenbart - mange PHP-merknader og avskrivninger, men ingenting kritisk. Endelig innså jeg at jeg hadde installert APC-caching på serveren helgen før, for å bruke med W3 Total Cache. Avinstallerer som helt utryddet 500 feil.

Mitt poeng: 500 feilen kan ganske enkelt være en kombinasjon av server configs som presenterer en inkompatibilitet. Dette er usannsynlig hvis du bruker administrerte tjenester, men med din egen Virtual Private Server (hvorfor skal du bruke en VPS i stedet for delt hosting? Hvorfor du bør bruke en VPS i stedet for delt hosting for WordPress Hvorfor du bør bruke en VPS istedenfor Delt Hosting for WordPress Read More) du er ansvarlig for å sikre at alt fungerer sammen, og dette er vanskeligere enn det høres ut.

På en delt vert kan du finne PHP minnegrense blir truffet - spesielt komplekse plugins kan forårsake dette. Hvis du er heldig, får du en feilmelding også i tråd med “Fatal Error: Tillatt minnestørrelse på xxx bytes utmattet”, men ikke alltid. Du kan kanskje fikse dette ved å legge til følgende linje i wp-config.php:

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

jeg sier kan, Fordi de fleste delte verter ikke vil la deg øke minnegrensen - du tar det du får. Kanskje det er på tide å vurdere andre former for hosting. De forskjellige skjemaene for Website Hosting forklart. [Teknologi forklart] De ulike skjemaene for webvertvert forklart [Teknologi forklart] Les mer ?

Selvfølgelig, hvis du hadde tatt sikkerhetskopier før du kjører noen oppgraderinger. Slik sikkerhetskopierer og gjenoppretter du WordPress-nettstedet ditt enkelt med UpdraftPlus. Slik sikkerhetskopierer og gjenoppretter du WordPress-nettstedet ditt enkelt med UpdraftPlus Les mer, du vil ha en enkel rute til gjenoppretting. Det er forferdelig når nettstedet ditt går ned - spesielt hvis det er en inntektskilde for deg og ikke bare en hobby - men ved å følge denne veiledningen og være metodisk, bør du få den opp igjen snart.

Har du noen gang hatt en 500 intern serverfeil eller en tom side som ikke ble løst av en av disse? Gi oss beskjed om hva problemet ditt var, og hvordan du fikset det.

Utforsk mer om: Wordpress, Wordpress Plugins.