Videre til indhold 
Hvis dit WordPress-site pludselig kun viser en hvid skærm, eller du får en meddelelse om, at "databaseforbindelsen mislykkedes", står du sandsynligvis over for et af de almindelige WordPress-problemer. I denne artikel viser jeg dig typiske Almindelige WordPress-fejl og hvordan du selv kan reparere dem hurtigt og sikkert.
Centrale punkter
- Hvid skærmÅrsager er normalt defekte plugins eller hukommelsesproblemer
- Fejl 500.htaccess-problemer eller inkompatible udvidelser
- Databasefejl: Forkerte adgangsdata eller serverproblemer
- Permalinks404-fejl efter ændringer i plugins eller temaer
- Fejlfindingstilstand: Visualiser kilden til fejlen direkte i koden
1. Den frygtede White Screen of Death (WSoD)
White Screen of Death (WSoD) er en af de mest almindelige fejl - en tom, hvid skærm dukker pludselig op, når man åbner en side eller et dashboard. Problemet er normalt forårsaget af en Plugin eller tema. PHP-hukommelsesgrænser spiller også en rolle her.
Jeg plejer at starte min reparation med at deaktivere plugins via FTP. For at gøre dette skal du blot gå til biblioteket /wp-indhold/plugins Omdøb plugin-mappen, eller flyt alle plugins til undermapper. Skift derefter til et standardtema som "Twenty Twenty-Four" som en test for at udelukke, at temaet er en fejlkilde.
Hvis det ikke hjælper, øger jeg den tilgængelige PHP-hukommelse. I filen wp-config.php Jeg er klar:
define('WP_MEMORY_LIMIT', '256M');
Jeg aktiverer fejlsøgningstilstanden for at få yderligere oplysninger:
define('WP_DEBUG', true);
2. Den interne serverfejl på 500
En 500-fejl ser værre ud, end den ofte er. Jeg starter med at omdøbe eller slette den aktuelle .htaccess-fil og automatisk oprette en ny ved at gå til instrumentbrættet under Indstillinger → Permalinks Du skal bare gemme igen.
Hvis det ikke er nok, deaktiverer jeg plugins og temaer hver for sig. PHP-hukommelsen kan også være skyld i det - så som sædvanlig: define('WP_MEMORY_LIMIT', '256M');
Fagfolk kigger også på serverens logfiler (findes normalt i hostingområdet) for at identificere detaljer om udløseren.
3. Forbindelsesfejl til databasen
Fejlen "Fejl ved oprettelse af databaseforbindelse" betyder, at WordPress ikke kan få adgang til dataene. Ofte er wp-config.php forkert - især databaseværtens brugernavn, adgangskode eller domæne.
Jeg tjekker følgende poster i filen:
DB_NAMEDB_BRUGERDB_PASSWORDDB_HOST
Hvis din databasehost ikke er "localhost", kan du ofte finde navnet i hostingmenuen. Nogle gange kan en genstart af MySQL-tjenesten eller en opgradering af hukommelsen hjælpe, hvis du kun har lidt webplads tilbage.
4. 404-fejl - ret permalinks
Klikker du på sidelinks og får kun "Siden blev ikke fundet"? Så er der sandsynligvis et problem med Permalink-struktur før. Det skyldes ofte ændringer i tema eller plugin.
Jeg løser det hurtigt ved at gemme permalinks igen. For at gøre dette skal du gå til WordPress-administratoren under Indstillinger → Permalinks og klik blot på "Anvend ændringer" uden at ændre noget. WordPress vil derefter skrive en .htaccess-fil med de aktuelle regler.
5. Login-problemer eller forwarding-loops
Hvis login-siden bliver ved med at blive indlæst, eller der vises en fejlmeddelelse "for mange omdirigeringer", tænker jeg på Cookie-fejl eller URL-konflikter. Derefter sletter jeg både browserens cache og cookies.
Hvis du bruger en anden domæneopsætning (f.eks. www og uden www), skal du kontrollere webstedet og hjemme-URL'en i databasen. Jeg bruger phpMyAdmin til at få adgang til tabellen wp_options og opdatere der siteurl og hjem passende.
En hyppig anstødssten er plugin-sekvensen - det er derfor, jeg deaktiverer problematiske udvidelser via FTP som en test.
6. Temaer og plugins som kilde til fejl
For mange almindelige WordPress-fejl Plugins, der ikke længere er opdaterede, er skylden. Jeg deaktiverer plugins først, især sikkerheds-, cache- og SEO-udvidelser, da de griber dybt ind i systemet.
Så snart problemet er væk, genaktiverer jeg dem enkeltvis. Jeg tester temaet kortvarigt med det almindelige WordPress-skin. I sådanne tilfælde skifter jeg før eller siden til et velholdt tema.
7. Problemer på grund af forældede PHP-versioner
Der opstår store begrænsninger, når du Forældet serverteknologi sæt. Mange udvidelser og selv WordPress-kernen kræver PHP 8.0 eller højere. Hvis du bruger PHP 7.4 eller ældre, vil du ofte få fejlmeddelelser eller timeouts.
Jeg opdaterer PHP-versionen i administratorområdet hos min hostingudbyder. Med webhoster.de Dette kan gøres på få sekunder. Hvis systemet fortsat er upålideligt, ville jeg overveje at skifte hoster.
| Sted | Hosting-udbyder | Kompatibilitet med WordPress | Ydelse | Forholdet mellem pris og ydelse |
|---|---|---|---|---|
| 1 | webhoster.de | Fremragende | Meget høj | Meget god |
| 2 | Vært B | God | Høj | God |
| 3 | Vært C | Medium | Gennemsnit | Medium |
8. Find fejlplaceringer med WordPress debug
Jeg genkender kun mange problemer med aktiv fejlsøgningstilstand. For at gøre dette åbner jeg wp-config.php via FTP og ændrer denne linje:
define('WP_DEBUG', true);
WordPress vil derefter vise alle meddelelser direkte på siden. Efter reparationen skal fejlfindingstilstanden deaktiveres igen - ellers vil dit websted også vise besøgende interne oplysninger:
define('WP_DEBUG', false);
9. genkende og forebygge fejlkilder
Fejl skyldes ofte forældede plugins, opdateringer uden backup eller uegnede hostingkonfigurationer. Jeg laver en komplet backup før hver WordPress-ændring. Jeg bruger et plugin eller hosterens eksportværktøj til dette.
Et staging-miljø - en kopi af webstedet til test - beskytter også mod fejl. Mange gode hostere tilbyder dette. Hvis du vil vide, hvad begyndere ofte falder for, kan du læse artiklen om Typiske WordPress-fejl for begyndere.
10. Når jeg hellere vil ringe til professionelle
I tilfælde af hackede hjemmesider, korrupte databaser eller fuldstændig ødelæggelse af layoutet henvender jeg mig til en specialiseret beredskabstjeneste. Sådanne situationer kræver mere dybdegående indgreb og viden.
Selv hvis du kun ser en "Parse Error" efter en opdatering, eller hvis hele din editor er gået ned, kan du få support. Du kan finde ud af mere om dette i denne artikel om Ødelagte layouts og backend-fejl.
11. Afhjælp SSL/HTTPS-problemer i god tid
I mange tilfælde undervurderer brugerne betydningen af en korrekt SSL/HTTPS-konfiguration. Almindelige symptomer er advarsler om "blandet indhold", hvor dele af siden stadig leveres ukrypteret, eller browserfejl som "Insecure" i adressefeltet. Med min hosting sørger jeg for, at SSL-certifikatet er korrekt integreret. Hvis nogle scripts eller billeder stadig henviser til HTTP efter overgangen, bruger jeg et søg-og-erstat-værktøj som "Better Search Replace" til at tilpasse alle URL'er. Plugins som "Really Simple SSL" kan også hjælpe her ved automatisk at omdirigere HTTP-aktiver til HTTPS.
Nogle gange støder jeg også på det problem, at certifikatet er udløbet, eller at der ikke er opsat noget. Så får jeg enten en advarsel i browseren eller oplysninger om en usikker forbindelse i WordPress-dashboardet. Senest på dette tidspunkt er det tid til at forny certifikatet via hosten eller aktivere Let's Encrypt. Hos nogle udbydere kan det gøres med nogle få klik, hos andre skal du uploade certifikaterne manuelt. Hvis du er i tvivl, er det vigtigt at kontrollere, om SSL videresendes korrekt, og om alle stier i temaet eller i plugins (f.eks. URL'er til JS- og CSS-filer) virkelig er indstillet til HTTPS.
12. Fejlkilder under WordPress-migrationer eller domæneændringer
Et andet ofte undervurderet punkt for WordPress-fejl er Migrationdvs. når du flytter din hjemmeside til en ny server eller et andet domæne. Det kan give flere problemer på én gang: Stier til medier er ikke længere korrekte, databaselinks peger stadig på det gamle domæne, eller SSL-stien genkendes ikke korrekt.
Jeg bruger gerne et plugin som "Duplicator" eller "All-in-One WP Migration", når jeg flytter, som automatisk tilpasser databasen. Så snart hjemmesiden er på den nye server, tester jeg permalinks, dashboardet og alle vigtige sider. Hvis noget ikke virker, tjekker jeg databasen for at se, om værdierne i siteurl og hjem den wp_options-tabellen er korrekte. Widgets eller menuer mister også nogle gange deres tildeling, hvis der stadig henvises til gamle ID'er eller stier internt.
Relativt typisk efter flytningen er en 404-fejl for undersidernår du er i .htaccess eller der er gamle regler i permalink-indstillingerne. Jeg går derfor regelmæssigt til "Indstillinger → Permalinks" og gemmer simpelthen igen. Derefter fungerer linkene normalt problemfrit.
13. Brug WP-CLI til at få dybere indsigt
WP-CLI er det officielle kommandolinjeværktøj til WordPress og understøttes af mange hostingudbydere. Personligt bruger jeg det til at opdatere plugins hurtigere, deaktivere temaer hurtigt eller tjekke databasen for fejl. Med kommandoer som wp-plugin deaktiveres --alle Jeg kan slå alle plugins fra på ingen tid uden at logge ind på dashboardet.
Det giver mig også et overblik over de installerede temaer i tilfælde af vanskelige fejl: Liste over wp-temaer viser mig, hvilke temaer der er aktive, og hvilke versioner der bruges. En anden praktisk funktion er at reparere databasen ved hjælp af wp db reparation. Dette kræver dog, at wp-config.php kommandoen define('WP_ALLOW_REPAIR', true); skal være aktiveret. Det er ofte min første indgang til tvivlsomme fejl, der peger på databasetabeller.
14. Problemer med cron-jobs og tidsstyring
Et aspekt, der ofte bliver overset, er WordPress' interne cron-jobs. De sikrer f.eks. automatisk offentliggørelse af planlagte indlæg eller regelmæssig udførelse af vedligeholdelsesopgaver for plugins. Hvis Cron ikke fungerer korrekt, vil du gå glip af planlagte udgivelser, opdateringer vil blive annulleret, eller plugins vil ikke kunne udføre deres opgaver.
Jeg tjekker derfor i min wp-config.php, om DEAKTIVER_WP_CRON på falsk og om min hosting bruger et rigtigt cron-job til at udløse WordPress-cron'en. For sider med høj trafik kan det give mening at deaktivere WP-cron og i stedet opsætte en system-cron, som kører hvert 15. minut. wp-cron.php opkald. Serverloggene hjælper også her med at se, om der er skjulte fejl i cron-udførelsen.
15. Snublesten med automatiske opdateringer
På den ene side er automatiske WordPress-opdateringer nyttige til at lukke sikkerhedshuller så hurtigt som muligt. På den anden side kan de uventet føre til Kompatibilitetsproblemer hvis temaer eller plugins endnu ikke er forberedt til den nyeste version. Så snart der kommer en større opdatering af WordPress, tager jeg først en sikkerhedskopi af hele min hjemmeside. Derefter tjekker jeg, om der er rapporteret om kendte konflikter i plugin-beskrivelserne eller udviklerfora.
Nogle gange er det værd at beholde automatiske opdateringer kun til mindre versioner og udføre større versionsspring manuelt. Det giver mig mulighed for at deaktivere alle inkompatible udvidelser før opdateringen eller erstatte dem med alternativer. Hvis jeg får fejlmeddelelser efter opdateringen, kan jeg hurtigere indkredse, hvilket plugin der er årsagen, da jeg allerede ved, hvad der er ændret i systemet.
Hvis du bruger et forældet tema, kan det ske, at nye funktioner i WordPress-kernen ikke længere adresseres korrekt. I sådanne tilfælde opstår den klassiske hvide skærm eller en 500-fejl, fordi temaet henviser til forældede hooks og funktioner. En opdatering eller ændring af et aktuelt tema er så ofte den eneste måde at fjerne disse inkompatibilitetsproblemer på.
16. Sikkerhedsplugins og deres faldgruber
For at beskytte deres WordPress-installation installerer mange brugere sikkerhedsplugins som Wordfence, iThemes Security eller lignende løsninger. Jeg bruger disse værktøjer til at overvåge potentielle indtrængningsforsøg og begrænse login-forsøg. Det kan dog ske, at Firewall-indstillingerne er for stive blokere din egen backend. Pludselig er du låst ude og får en kryptisk fejlmeddelelse, når du logger ind.
I sådanne situationer deaktiverer jeg sikkerhedsplugin'et som en test via FTP ved blot at omdøbe plugin-mappen. Hvis jeg derefter logger ind uden problemer, ved jeg, at sikkerhedsudvidelsens fine indstillinger er for strenge. Det samme gælder for nogle IP-blokkere eller admin-tilsløringsfunktioner. Hvis der foretages forkerte indtastninger her, kan du ikke længere få adgang til din WordPress-installation.
Ud over firewallen overvåger nogle sikkerhedsplugins også filændringer i WordPress, hvilket er godt, men kan generere mange falske positiver under opdateringer. Jeg anbefaler derfor at justere scanningsintervallerne og sikre, at vigtige kerne-filer bliver ikke blokeret ved en fejl.
Godt forberedt i stedet for hjælpeløs
Mange fejl kan løses hurtigt med en struktureret tilgang og lidt ro. Jeg anbefaler regelmæssige opdateringer, testede plugins og tilstrækkelig webplads. I kritiske situationer kan nødværktøjer og gennemsigtig hostingsupport hjælpe.
Hvis dit websted forbliver usikkert på trods af alle foranstaltninger, eller hvis selv logiske foranstaltninger ikke virker, bør du søge professionel hjælp. Artiklen om WordPress-sikkerhed efter et hackerangreb giver dig de første tips til nødsituationer.
