Introduksjon
I denne veiledningsserien har vi tidligere gått gjennom hvordan du tar sikkerhetskopi av nettstedet ditt, hvordan du oppdaterer WordPress og hvordan du oppdaterer PHP. Dette er tiltak som kan forebygge problemer, men på et komplekst nettsted er det nesten uunngåelig at du vil støte på feil fra tid til annen. I denne veiledningen tar vi for oss noen av de vanligste feilene, og de beste fremgangsmåtene for å løse dem.
Begynn med forberedelsene nedenfor, og gå deretter videre til den delen som best beskriver det du ser. Du kan teste utvidelser og temaer når du mistenker en konflikt, aktivere loggføring hvis feilmeldingen som vises ikke gir tilstrekkelig informasjon, eller hoppe til avsnittet om vanlige feil slik som en tom side, HTTP 500-feil, feil i databaseforbindelsen eller en vedlikeholdsskjerm som henger seg opp.
Før du rører ved noe som helst
Før du begynner å deaktivere utvidelser eller endre innstillinger er det tre ting du bør du gjøre.
1 – Noter detaljene. Kopier feilmeldingen ordrett, noter hvilken side eller handling som utløste den, når den oppstod, og den siste endringen du gjorde før den dukket opp. Hvis feilen nevner en bestemt utvidelse, et tema eller en fil er det ditt beste spor. Den siste endringen du gjorde er også en interessant ledetråd siden endring av PHP-versjonen, oppdatering av en utvidelse eller til og med oppdatering av WordPress-kjernen kan føre til konflikter som først viser seg i etterkant.
2 – Ta en sikkerhetskopi. Selv om nettstedet ikke fungerer bør du ta et øyeblikksbilde av den nåværende tilstanden, før du begynner å eksperimentere videre. En sikkerhetskopi med WordPress Toolkit i Plesk utføres på hosting-siden uten at WordPress trenger å lastes inn, så denne metoden er tilgjengelig selv hvis wp-admin er nede. Hele prosessen for sikkerhetskopiering er beskrevet i del 21.
3 – Reproduser feilen. Prøv å utføre den samme handlingen som forårsaket feilen, på den samme siden og på samme måte. Hvis du klarer å gjenskape feilen flere ganger vet du at det er et reelt problem og ikke bare skyldes for eksempel et tidsavbrudd. Hvis du ikke klarer å reprodusere feilen kan du prøve en annen nettleser eller et inkognitovindu for å utelukke at problemet skyldes nettleserens cache eller utvidelser.
Identifikasjon av konflikter mellom utvidelser
Konflikter mellom utvidelser er en vanlig årsak til problemer i WordPress. To utvidelser som fungerer fint hver for seg kan komme i konflikt med hverandre, eller en oppdatering av en utvidelse kan føre til feil. Noen ganger kan en utvidelse være uforenlig med den versjonen av WordPress eller PHP du bruker. For å finne ut av dette må du deaktivere utvidelsene på en systematisk måte og teste etter hver endring.
Test i wp-admin
- Gå til Utvidelser → Installerte utvidelser.
- Noter deg hvilke utvidelser som er aktive for øyeblikket (ta et skjermbilde eller skriv dem ned, slik at du kan gjenopprette det aktuelle oppsettet senere).
- Hvis feilmeldingen navngir en bestemt utvidelse må du først deaktivere denne og deretter teste. Hvis problemet forsvinner vet du nå at du må fokusere på den aktuelle utvidelsen.
- Hvis det ikke opplagt hvilken utvidelse du bør teste, kan du bruke avkryssingsboksen øverst på listen til å velge alle utvidelser, velge Deaktiver fra rullegardinmenyen Massehandlinger og klikke på Bruk. Test nettstedet på nytt.
- Hvis problemet forsvinner når alle utvidelser er deaktivert, kan du aktivere dem én om gangen og teste etter hver aktivering inntil problemet dukker opp igjen. Den siste utvidelsen du aktiverte er årsaken til problemet.
Når du har funnet den skyldige bør du sjekke endringsloggen og støtteforumet for å se om det fins allerede identifiserte problemer med din WordPress-versjon. Hvis du finner en oppdatering eller en løsning kan du prøve den. Hvis ikke må du bestemme deg for om du vil vente på en løsning, kontakte utviklerens kundestøtte eller se etter en alternativ utvidelse.
Hva gjør du hvis wp-admin ikke lastes inn?
Hvis en utvidelse har forårsaket en så alvorlig feil at selve WordPress-kontrollpanelet ikke lar seg åpne, kan du fortsatt administrere utvidelser via Plesk.
WordPress Toolkit er den enkleste måten hvis webhotellet ditt støtter den. I Plesk åpner du nettstedets WordPress Toolkit-kort og utvider seksjonen Plugins. Hver utvidelse har en bryter du kan bruke til å deaktivere den direkte.
File Manager er den manuelle løsningen hvis du ikke har tilgang til WordPress Toolkit. I Plesk åpner du Files, navigerer til httpdocs → wp-content → plugins, og endrer navnet på mappen til den mistenkte utvidelsen (du kan for eksempel endre navnet på problem-utvidelse til problem-utvidelse-deaktivert). WordPress behandler en omdøpt utvidelses-mappe som om utvidelsen ikke eksisterer, så systemet vil ikke prøve å laste den inn. For å deaktivere alle utvidelser samtidig kan du gi hele plugins-mappen et nytt navn, for eksempel plugins-deaktivert.
Merk: Mappen som inneholder
wp-contentkan ha et annet navn ennhttpdocshos ditt webhotell (f.eks.public_htmleller navnet på det aktuelle underdomenet).
Identifikasjon av konflikter mellom temaer
Hvis det ikke hjelper å deaktivere alle utvidelser er temaet den neste mulige årsaken. WordPress leveres med standardtemaer (som Twenty Twenty-Five) som er kjent for å fungere godt sammen med kjernen. Å bytte til et av disse som en test er en god metode for å finne ut om det er et potensielt problem i koden til temaet ditt.
- I WordPress, gå til Utseende → Temaer.
- Sørg for at du har minst ett standard WordPress-tema installert.
- Aktiver standardtemaet og test nettstedet.
Hvis problemet forsvinner når du bruker et standardtema ligger feilen i det opprinnelige temaet ditt. Sjekk om det finnes en oppdatering, se etter informasjon på temaets støtteforum, eller ta kontakt med utvikleren. Hvis du ikke får tilgang til wp-admin kan WordPress Toolkit i Plesk bytte tema fra hosting-siden på samme måte som det håndterer utvidelser.
Det er lurt å ha minst ett standard WordPress-tema installert, selv om du aldri bruker det. Det gir deg en lett tilgjengelig løsning for nettopp denne typen tester.
Aktiver loggføring av feilsøk
Hvis du trenger mer informasjon om hva som skjer i kulissene kan WordPress skrive detaljert feilinformasjon til en loggfil i bakgrunnen. Med WordPress Toolkit i Plesk kan du slå denne funksjonen av eller på uten å måtte redigere noen filer.
Åpne nettstedets WordPress Toolkit i Plesk og se etter bryteren Debugging. Klikk på konfigurasjonsikonet ved siden av denne bryteren, så får du opp alternativene for å aktivere utdata for feilsøking. Velg WP_DEBUG for å aktivere feilsøkingsmodus og WP_DEBUG_LOG for å lagre feil, advarsler og merknader i en loggfil. Med mindre du jobber på et nettsted som ikke er i produksjon bør du la WP_DEBUG_DISPLAY være deaktivert, slik at feilsøkingsmeldinger ikke er synlige på publiserte sider.
Når disse innstillingene er aktivert kan du reprodusere feilen én gang til. Åpne deretter Plesk File Manager og gå til httpdocs → wp-content. WordPress oppretter normalt filen debug.log der når det er noe å loggføre. Nyttige oppføringer inneholder et tidsstempel og kan angi navnet på filen og linjen der feilen oppstod. En linje som PHP Fatal error: ... in /httpdocs/wp-content/plugins/en-viss-utvidelse/main.php on line 42 tyder på at denne utvidelsen er den første du bør undersøke.
Deaktiver feilsøking når du er ferdig. Feilsøkingslogger kan inneholde filstier, databaseopplysninger og annen intern informasjon som ikke bør ligge på en produksjonsserver. Når du har funnet den informasjonen du trenger går du tilbake til WordPress Toolkit og deaktiverer begge innstillingene for feilsøking.
Vanlige problemer og hva du kan gjøre med dem
“Det har oppstått en alvorlig feil på dette nettstedet”
Dette er skjermbildet for alvorlige feil i WordPress. Det betyr at PHP har funnet en feil som er alvorlig nok til å stoppe kjøringen; vanligvis en konflikt mellom en utvidelse og et tema, en inkompatibilitet mellom PHP-versjoner eller ødelagte filer.
Sjekk e-postkontoen til administratoren for nettstedet ditt, inkludert spam-mappen. WordPress har en innebygd gjenopprettingsmodus som kan sende en e-post med en spesiell lenke når den oppdager en alvorlig PHP-feil under normal innlasting av en side. Når du klikker på denne lenken åpnes en beskyttet administratorøkt der utvidelsen eller temaet som forårsaket feilen er satt på pause, tilgjengelig bare for deg. Du kan deretter gå inn på wp-admin for å deaktivere, oppdatere eller reparere komponenten det gjelder. Gjenopprettingslenken utløper, så sjekk den så raskt som mulig.
Hvis e-posten ikke kommer frem (noe som kan skje hvis serverens utgående e-post ikke er konfigurert riktig, eller hvis det er nettopp den utvidelsen som håndterer utgående e-post som har krasjet), kan du bruke WordPress Toolkit i Plesk til å deaktivere utvidelser eller bytte tema direkte fra webhotellet i stedet for å følge fremgangsmåten beskrevet ovenfor.
Tom, hvit side
En helt tom side uten feilmelding kan skyldes en PHP-feil, en databasefeil eller en konflikt mellom en utvidelse og et tema. Aktiver WP_DEBUG og WP_DEBUG_LOG via WordPress Toolkit som beskrevet ovenfor, last inn den aktuelle siden på nytt og sjekk deretter debug.log i Plesk File Manager, vanligvis under httpdocs → wp-content. Hvis denne loggen ikke viser årsaken, gå tilbake til hjemmekatalogen din, åpne mappen logs og sjekk den aktuelle error_log-filen for oppføringer fra tidspunktet da den tomme siden dukket opp.
wp-admin lastes ikke inn
Hvis det brukerne ser på nettstedet ditt fungerer normalt, men wp-admin viser en feilmelding eller omdirigerer i en endeløs loop, kan du prøve å gå direkte til dittdomene.com/wp-login.php i stedet for /wp-admin. En fungerende påloggingsside bekrefter at WordPress fremdeles har tilgang til påloggingsskjermen, men det avdekker ikke årsaken til problemet med wp-admin. Sjekk feilloggene, og bruk deretter WordPress Toolkit i Plesk til å teste mistenkte utvidelser én etter én.
Hvis verken påloggingssiden eller wp-admin lastes inn, kan problemet skyldes en ødelagt .htaccess-fil. Dette er en konfigurasjonsfil som ligger i nettstedets rotkatalog og styrer hvordan URL-er håndteres. Åpne Plesk File Manager, gå til httpdocs, finn .htaccess og endre navnet til .htaccess-sikkerhetskopi. Test nettstedet på nytt. Hvis det fungerer igjen inneholdt den gamle filen en regel med feil i. Du kan generere en ny, feilfri fil ved å gå til Innstillinger → Permalenker i WordPress og klikke på Lagre endringer uten å endre den valgte strukturen.
HTTP 500 – Intern serverfeil
En 500-feilmelding betyr at det har oppstått en feil på serversiden, men at serveren ikke oppgir nøyaktig hva feilen består i. Den egentlige årsaken kan være en PHP-feil, en ødelagt .htaccess-fil, en minnebegrensning eller et problem med serverkonfigurasjonen.
Begynn med feilloggen til serveren. I Plesk åpner du Files, navigerer til hjemmekatalogen din og åpner deretter mappen logs. Se etter den aktuelle loggfilen og finn oppføringer som samsvarer med tidspunktet da 500-feilen oppstod.
Hvis loggen viser til en utvidelse, følg fremgangsmåten for identifisering av feil i utvidelser. Hvis den nevner en ødelagt .htaccess-fil må du gi filen et nytt navn via File Manager som beskrevet ovenfor og lagre permalenker på nytt. Hvis loggen nevner minneutnyttelse eller PHP-begrensninger er dette noen ganger et problem på hostingnivå som du bør ta opp med kundestøtte i stedet for å prøve å løse det selv, spesielt hvis du ikke har gjort noen vesentlige endringer på nettstedet ditt.
Unngå å øke PHP-minnegrensen i
wp-config.phpsom første reaksjon. Overbelastet minne er vanligvis et symptom på noe annet (en utvidelse som har gått amok, en massiv forespørsel, en unormal trafikkøkning), og å heve grensen uten å forstå årsaken skjuler bare det egentlige problemet inntil det blir verre.
Feil ved oppretting av en databaseforbindelse
Dette betyr at WordPress ikke klarte å koble seg til eller velge databasen sin. Vanlige årsaker er feil i databaseinnstillingene i wp-config.php, en utilgjengelig databaseserver eller påloggingsopplysninger som ikke ble korrekt oppdatert under en migrering.
Gå gjennom disse kontrollpunktene i Plesk før du kontakter kundestøtte.
1 – Åpne Databases og sjekk at nettstedets database og databasebruker fremdeles eksisterer under fanene Databases og User Management. Prøv også å åpne databasen via phpMyAdmin ved å klikke på Web Admin-ikonet til høyre på siden. Hvis phpMyAdmin åpnes som vanlig, betyr det at selve databasetjenesten kjører.
2 – Ta sikkerhetskopi av nettstedet og åpne deretter wp-config.php via File Manager. Sammenlign DB_NAME og DB_USER med databaseopplysningene som vises i Plesk. På vanlige webhotell bør DB_HOST være localhost. Ikke endre en verdi med mindre du er helt sikker på den skal være.
3 – Hvis databasebrukeren finnes, men passordet er ukjent eller nylig er endret, må du tilbakestille brukerens passord i Plesk og angi det samme nye passordet som DB_PASSWORD i wp-config.php. De to verdiene må stemme overens. Sørg for at du redigerer brukeren som er tilordnet denne databasen, og hold passordet hemmelig.
Hvis databasen og brukerkontoen finnes, men phpMyAdmin ikke klarer å koble seg til, eller hvis innstillingene for pålogging stemmer, men WordPress fremdeles viser feilmeldingen, bør du vente noen minutter og prøve på nytt. Dersom feilen vedvarer på dette tidspunktet kan det tyde på et problem med databasetjenesten eller webhotellet. Ta derfor kontakt med kundestøtte og oppgi tidspunktet da feilen oppstod samt hvilke tester du har utført.
Innlegg og sider gir 404-feil
Hvis hjemmesiden din lastes inn, men enkelte innlegg eller sider gir 404-feil, har WordPress’ omskrivingsregler sannsynligvis kommet ut av synk. Dette skjer oftest etter en migrering eller en oppdatering av permalenker som ikke ble gjort på riktig måte.
Gå til Innstillinger → Permalenker og klikk på Lagre endringer uten å endre den valgte strukturen. Dette får WordPress til å generere de interne URL-reglene på nytt.
Hvis ikke dette hjelper bør du sjekke at siden eller innlegget du prøver å åpne faktisk finnes (det kan ha blitt slettet), og deretter finne .htaccess i httpdocs via Plesk File Manager. Sjekk kolonnen Permissions. Den vanlige innstillingen er rw- r-- r--, også kjent som 644, som gir filens eier lese- og skrivetilgang til filen, mens alle andre kun har lesetilgang.
Hvis tilgangsrettighetene er annerledes, klikker du på .htaccess-linjen og velger Change Permissions. Under Owner velger du Read og Write. Under Group og Others velger du kun Read. La alle Execute/search-boksene være tomme, og klikk deretter på Save. Ikke gjør filen skrivbar for alle, og ikke sett innstillingen til 777.
Fastlåst i vedlikeholdsmodus
Når WordPress kjører en oppdatering lager systemet en midlertidig fil kalt .maintenance i nettstedets rotkatalog. Dette får WordPress til å vise meldingen “midlertidig utilgjengelig på grunn av planlagt vedlikehold” i stedet for å laste inn nettstedet. Normalt slettes denne filen automatisk når oppdateringen er fullført, men en avbrutt eller mislykket oppdatering kan føre til at den blir liggende igjen.
Sjekk først at det ikke er noen oppdatering som fortsatt pågår. Åpne deretter Plesk File Manager, naviger til mappen httpdocs, finn mappen .maintenance og slett den. Vedlikeholdsvarselet bør da forsvinne. Hvis oppdateringen ikke ble fullført, kan du kjøre den på nytt fra Oppdateringer i kontrollpanelet når du er tilbake i wp-admin.
Endringer vises ikke
I dette tilfellet har du redigert en side eller endret en innstilling, men nettstedet viser fortsatt den gamle versjonen. WordPress-nettsteder kan ha flere cache-lag som ligger oppå hverandre. Gå gjennom dem ett og ett.
1 – Nettleserens cache er et godt sted å starte. Gjør en hard oppdatering av siden med Ctrl+Shift+R (Windows) eller Cmd+Shift+R (Mac), eller åpne siden i et inkognitovindu for å teste med en tom nettlesercache.
2 – WordPress-cachen er neste punkt. Hvis du bruker AccelerateWP eller en annet cache-utvidelse, åpner du innstillingene og ser etter en Tøm– eller Tøm cache-knapp. AccelerateWP viser et Tøm alt-alternativ i WordPress-linjen øverst på hver side. Andre cache-utvidelser har lignende kontroller, vanligvis under Innstillinger eller som et menypunkt på øverste nivå i venstre sidefelt.
3 – Objektcache gjelder hvis du bruker Redis, som vi gikk gjennom i del 14 i denne veiledningsserien. Åpne Innstillinger → Redis i WordPress-kontrollpanelet og klikk på Tøm buffer. Dette sletter de lagrede databaseforespørslene som Redis oppbevarer i minnet.
Hvis ingen av disse løsningene hjelper bør du dobbeltsjekke at du har redigert riktig side. På nettsteder med lignende sidenavn eller flere utkast er det lett å gjøre den feilen at man redigerer en side som det ikke er lenket til i menyen.
Sider som lastes tregt eller tidsavbrudd
Et tidligere raskt nettsted som nå har begynt å gå tregt kan ha nådd grensen for serverressurser, kjøre en ressurskrevende utvidelse eller slite med en database som har blitt for stor og tung.
Sjekk Resource Usage-seksjonen i Plesk for domenet ditt. Du finner den blant domeneverktøyene under Websites & Domains. Hvis du ser at grensene for CPU, minne eller samtidige prosesser ble nådd på de tidspunktene da nettstedet var tregt, må du oppgi disse tidsstemplene når du kontakter STW-kundestøtte. Disse dataene hjelper dem med å finne årsaken på serversiden.
Hvis ressursbruken ser normal ut ligger problemet mest sannsynlig i WordPress. Deaktiver utvidelser én etter én for å finne den som belaster systemet mest. Vanlige årsaker er blant annet utvidelser som kjører planlagt sikkerhetskopiering når nettstedet er aller travlest, analyse-utvidelser som foretar eksterne API-anrop, samt komplekse skjema- eller popup-utvidelser. I tidligere veiledninger har vi sett på caching, bildeoptimalisering og databaseopprydding, som alle bidrar til god ytelse.
Kontroll av integriteten til kjernefiler
Hvis feilen vedvarer etter at du har utelukket utvidelser eller temaer som årsak, kan WordPress Toolkit i Plesk sjekke om kjernefilene dine i WordPress er endret eller ødelagt. Åpne WordPress Toolkit-kortet for nettstedet ditt, klikk på Check WordPress Integrity og deretter på Verify Checksums. Dette sammenligner hver enkelt kjernefil på serveren din med de offisielle kontrollsummene til WordPress for din versjon.
Hvis sjekken avdekker filer som ikke stemmer overens, tilbyr WordPress Toolkit et alternativ for å installere WordPress-kjernen på nytt. Dette erstatter kjernefilene med rene kopier. Å installere kjernen på nytt påvirker ikke nettstedets innhold, men du bør likevel ta en sikkerhetskopi først. Dette er en metode for reparasjon av skadde kjernefiler, ikke en løsning på problemer med utvidelser eller konfigurasjon.
Finn bedre svar på nettet
Søk med spesifikke kriterier
Kopier en karakteristisk linje fra feilmeldingen og sett den i anførselstegn. Oppgi navnet og versjonen på utvidelsen eller temaet det gjelder, og inkluder også WordPress- eller PHP-versjonen din dersom problemet oppstod etter en versjonsoppdatering. Et søk som "Call to undefined function" flavor-developer 3.2.1 WordPress 7.0 vil gi mye mer relevante resultater enn WordPress-side lastes ikke inn.
Begynn med de mest pålitelige kildene:
- Utvidelsen eller temaets egen dokumentasjon og endringslogg. Utviklere dokumenterer ofte kjente problemer eller løser dem i nyere versjoner.
- Utvidelsens støtteforum på WordPress.org. Utviklere og erfarne brukere legger ut løsninger og provisoriske tiltak, og du kan søke etter den eksakte feilmeldingen din.
- Utvidelsens GitHub-issues, dersom utvikleren bruker GitHub. Issues kan søkes i, og diskusjonene gjelder ofte spesifikke versjoner.
- Den offisielle WordPress-dokumentasjonen. Siden Vanlige feil og håndboken Feilsøking dekker det viktigste.
Vær forsiktig med gamle foruminnlegg og generiske “slik løser du problemet”-artikler. En løsning fra 2019 for en utvidelse som er blitt grundig revidert siden den gang passer kanskje ikke til din situasjon, og kan gjøre problemet verre. Sjekk datoer og versjonsnumre før du følger noen råd.
Ikke lim inn kode fra ukjente kilder i
wp-config.php,.htaccesseller temaetsfunctions.phputen å forstå hva de gjør. En kodelinje som løste et problem for noen andre i et annet hostingmiljø kan lett ødelegge ditt.
Når bør du kontakte kundestøtte?
Noen problemer er det ikke opp til deg å løse. Å vite hvor du skal sende en forespørsel sparer tid for alle.
Kontakt webhotellet ditt ved driftsavbrudd på databaseserveren, feilmeldinger i serverloggen som omhandler minnebegrensninger eller PHP-konfigurasjon, begrensninger i ressursbruken som opptrer sammen med symptomene, feil i SSL-sertifikater samt problemer med DNS eller domene-resolving. Kundestøtte har tilgang til informasjon på serversiden som du selv ikke kan se med WordPress eller Plesk.
Ta kontakt med utvikleren av utvidelsen eller temaet hvis feilsøkingsloggen eller feilmeldingen spesifikt nevner koden deres, når en funksjon sluttet å fungere etter oppdatering av den aktuelle komponenten, eller når en konflikt mellom to utvidelser krever innspill fra utvikleren for å løses.
Slik sender du en nyttig støtteforespørsel
Oppgi den nøyaktige feilmeldingen, når problemet oppstod og hva som ble endret før det, hvilken versjon av WordPress og PHP du bruker, hvilket tema som er aktivt og hvilken versjon det har, samt hvilken utvidelse du bruker og hvilken versjon den har. Oppgi eventuelle vesentlige endringer du har gjort på webhotellet ditt, og hva du allerede har prøvd (deaktivering av utvidelser, bytte av tema, funn i feilsøkingsloggen), slik at den som svarer ikke trenger å starte med helt blanke ark.
Knappen Kopier nettstedsinformasjonen til utklippstavlen under fanen WordPress → Verktøy → Nettstedshelse → Info gir deg en oversikt over nettstedets tilstand som du kan lime inn i en privat dialog med kundestøtte. Se nøye gjennom den før du eventuelt publiserer den offentlig, siden den inneholder serverbaner og opplysninger om webhotellet.
Oppgi aldri påloggingsopplysninger for databaser, API-nøkler, autentiseringssalter for WordPress eller hele innholdet i
wp-config.phpi noen form for støtteforespørsel, verken offentlig eller privat.
Konklusjon
De fleste WordPress-problemer er mye enklere å diagnostisere hvis man slutter å gjette og begynner å avgrense mulige årsaker. En sikkerhetskopi før du gjør noe som helst, systematisk testing av utvidelser og temaer samt en gjennomgang av loggene vil ofte avdekke om det neste trinnet ligger hos en bestemt utvikler eller hos webhotellet.
Neste trinn: