Akut reparation: Vanliga WordPress-fel och hur du snabbt åtgärdar dem

Om din WordPress-webbplats plötsligt bara visar en vit skärm eller om du får ett meddelande om att "databasanslutningen misslyckades", har du förmodligen ett av de vanligaste WordPress-problemen. I den här artikeln visar jag dig typiska Vanliga WordPress-fel och hur du själv kan åtgärda dem snabbt och säkert.

Centrala punkter

• Vit skärmOrsakerna är vanligtvis felaktiga plugins eller minnesproblem
• Fel 500Problem med .htaccess eller inkompatibla tillägg
• Fel i databasen: Felaktiga åtkomstdata eller serverproblem
• Permalänkar404-fel efter ändringar av plugins eller teman
• Felsökningsläge: Visualisera felkällan direkt i koden

1. Den fruktade vita skärmen av död (WSoD)

White Screen of Death (WSoD) är ett av de vanligaste felen - en tom vit skärm dyker plötsligt upp när sidan eller instrumentpanelen öppnas. Problemet orsakas vanligtvis av en Plugin eller tema. PHP-minnesbegränsningar spelar också en roll här.

Jag brukar börja min reparation med att avaktivera plugins via FTP. För att göra detta går du helt enkelt till katalogen /wp-innehåll/plugins byt namn på plugin-mappen eller flytta alla plugins till undermappar. Byt sedan till ett standardtema som "Twenty Twenty-Four" som ett test för att utesluta temat som en felkälla.

Om detta inte hjälper, ökar jag det tillgängliga PHP-minnet. I filen wp-konfig.php Jag ställde in:
define('WP_MEMORY_LIMIT', '256M');

Jag aktiverar felsökningsläget för ytterligare information:
define('WP_DEBUG', true);

2. Felet 500 intern server

Ett 500-fel ser värre ut än vad det ofta är. Jag börjar med att byta namn på eller ta bort den nuvarande .htaccess-fil och automatiskt skapa en ny genom att gå till instrumentpanelen under Inställningar → Permalänkar spara helt enkelt igen.

Om det inte räcker avaktiverar jag plugins och teman individuellt. PHP-minnet kan också vara skyldigt - så som vanligt: define('WP_MEMORY_LIMIT', '256M');

Experter tittar också på serverloggarna (som vanligtvis finns i hostingområdet) för att identifiera detaljer om utlösaren.

3. Anslutningsfel till databasen

Felet "Fel vid upprättande av en databasanslutning" betyder: WordPress kan inte komma åt data. Ofta är wp-konfig.php felaktig - särskilt användarnamn, lösenord eller domän för databasvärden.

Jag kontrollerar följande poster i filen:

• DB_NAME
• DB_ANVÄNDARE
• DB_PASSWORD
• DB_HOST

Om din databasvärd inte är "localhost" kan du ofta hitta namnet i värdmenyn. Ibland kan en omstart av MySQL-tjänsten eller en minnesuppgradering hjälpa om du har lite webbutrymme kvar.

4. 404-fel - korrekta permalänkar

Du klickar på sidlänkar och får bara upp "Sidan hittades inte"? Då är det förmodligen ett problem med Permalink struktur tidigare. Detta orsakas ofta av ändringar i teman eller insticksprogram.

Jag löser det snabbt genom att spara permalänkarna igen. För att göra detta går du till WordPress-admin under Inställningar → Permalänkar och bara klicka på "Tillämpa ändringar" utan att ändra något. WordPress kommer då att skriva en .htaccess-fil med de aktuella reglerna.

5. inloggningsproblem eller vidarebefordringsloopar

Om inloggningssidan håller på att laddas eller ett felmeddelande "för många omdirigeringar" visas, tänker jag på Cookie-fel eller URL-konflikter. Sedan raderar jag både webbläsarens cache och cookies.

Om du använder en annan domänkonfiguration (t.ex. www och utan www), kontrollera webbadressen för webbplatsen och hemadressen i databasen. Jag använder phpMyAdmin för att komma åt tabellen wp_alternativ och uppdatera där webbplatsurl och hem lämplig.

En vanlig stötesten är plugin-sekvensen - det är därför jag avaktiverar problematiska tillägg via FTP som ett test.

6. Teman och plugins som felkälla

För många vanliga WordPress-fel plugins som inte längre är uppdaterade är skyldiga. Jag avaktiverar plugins först, särskilt säkerhets-, cache- och SEO-tillägg, eftersom de stör systemet djupt.

Så snart problemet är borta återaktiverar jag dem individuellt. Jag testar temat en kort stund med WordPress standardskin. I sådana fall byter jag förr eller senare till ett väl underhållet tema.

7. problem på grund av föråldrade PHP-versioner

Stora begränsningar uppstår när du Föråldrad serverteknik uppsättningar. Många tillägg och till och med WordPress-kärnan kräver PHP 8.0 eller högre. Om du använder PHP 7.4 eller äldre kommer du ofta att få felmeddelanden eller timeouts.

Jag uppdaterar PHP-versionen i adminområdet hos min hostingleverantör. Med webhoster.de detta kan göras på några sekunder. Om systemet förblir opålitligt skulle jag överväga att byta hoster.

Plats	Hostingleverantör	Kompatibilitet med WordPress	Prestanda	Förhållande mellan pris och prestanda
1	webhoster.de	Utmärkt	Mycket hög	Mycket bra
2	Värd B	Bra	Hög	Bra
3	Värd C	Medium	genomsnitt	Medium

8. Hitta felplatser med WordPress Debug

Jag känner bara igen många problem med aktivt felsökningsläge. För att göra detta öppnar jag wp-config.php via FTP och ändrar den här raden:

define('WP_DEBUG', true);

WordPress kommer då att visa alla meddelanden direkt på sidan. Efter reparationen måste felsökningsläget avaktiveras igen - annars kommer din webbplats också att visa besökare intern information:

define('WP_DEBUG', false);

9. identifiera och förebygga felkällor

Fel orsakas ofta av föråldrade plugins, uppdateringar utan säkerhetskopiering eller olämpliga hostingkonfigurationer. Jag gör en fullständig säkerhetskopia före varje WordPress-ändring. För detta använder jag ett plugin eller webbhotellets exportverktyg.

En staging-miljö - en kopia av webbplatsen för testning - skyddar också mot fel. Många bra värdar erbjuder detta. Om du vill veta vad nybörjare ofta går på, läs artikeln om Typiska WordPress-fel för nybörjare.

10. när jag hellre vill ringa professionella

I händelse av hackade webbplatser, korrupta databaser eller fullständig förstörelse av layouten vänder jag mig till en specialiserad räddningstjänst. Sådana situationer kräver mer djupgående insatser och kunskap.

Även om du bara ser ett "Parse Error" efter en uppdatering eller om hela din editor har kraschat kan du få support. Du kan läsa mer om detta i den här artikeln om Trasiga layouter och fel i backend.

11. åtgärda SSL/HTTPS-problem i god tid

I många fall underskattar användarna betydelsen av en korrekt SSL/HTTPS-konfiguration. Vanliga symptom är "mixed content"-varningar, där delar av sidan fortfarande levereras okrypterat, eller webbläsarfel som "Insecure" i adressfältet. Med mitt webbhotell ser jag till att SSL-certifikatet är korrekt integrerat. Om vissa skript eller bilder fortfarande hänvisar till HTTP efter övergången använder jag ett sök- och ersättningsverktyg som "Better Search Replace" för att anpassa alla webbadresser. Plugins som "Really Simple SSL" kan också hjälpa till här genom att automatiskt omdirigera HTTP-tillgångar till HTTPS.

Ibland stöter jag också på problemet att certifikatet har löpt ut eller att inget har konfigurerats. Då får jag antingen en varning i webbläsaren eller information om en osäker anslutning i WordPress instrumentpanelen. Senast vid denna tidpunkt är det dags att förnya certifikatet via hostern eller aktivera Let's Encrypt. Hos vissa leverantörer kan detta göras med bara några klick, hos andra måste du ladda upp certifikaten manuellt. Om du är osäker är det viktigt att kontrollera om SSL vidarebefordras korrekt och om alla sökvägar i temat eller i plugins (t.ex. webbadresser till JS- och CSS-filer) verkligen är inställda på HTTPS.

12. felkällor vid WordPress-migreringar eller domänbyten

En annan ofta underskattad punkt för WordPress-fel är Migrationt.ex. när du flyttar din webbplats till en ny server eller en annan domän. Detta kan orsaka flera problem samtidigt: Sökvägar till media är inte längre korrekta, databaslänkar pekar fortfarande till den gamla domänen eller SSL-sökvägen känns inte igen korrekt.

När jag flyttar använder jag gärna ett plugin som "Duplicator" eller "All-in-One WP Migration", som automatiskt anpassar databasen. Så snart webbplatsen ligger på den nya servern testar jag permalänkar, dashboard och alla viktiga sidor. Om något inte fungerar kontrollerar jag databasen för att se om värdena i webbplatsurl och hem den wp_alternativ-tabellen är korrekta. Widgets eller menyer förlorar också ibland sin tilldelning om gamla ID:n eller sökvägar fortfarande refereras internt.

Relativt typiskt efter flytten är en 404-fel för undersidornär i .htaccess eller så finns det gamla regler i permalänkinställningarna. Jag går därför regelbundet in på "Inställningar → Permalänkar" och sparar helt enkelt om. Efter det fungerar länkarna oftast smidigt.

13. Använd WP-CLI för djupare insikter

WP-CLI är det officiella kommandoradsverktyget för WordPress och stöds av många hostingleverantörer. Personligen använder jag det för att uppdatera plugins snabbare, avaktivera teman snabbt eller kontrollera databasen för fel. Med kommandon som wp plugin avaktivera --all Jag kan stänga av alla plugins på nolltid utan att logga in på instrumentpanelen.

Detta ger mig också en överblick över de installerade teman i händelse av svåra fel: wp tema lista visar mig vilka teman som är aktiva och vilka versioner som används. En annan praktisk funktion är att reparera databasen med hjälp av wp db reparation. Detta kräver dock att wp-konfig.php befälet define('WP_ALLOW_REPAIR', true); måste vara aktiverad. Detta är ofta min första anhalt för tvivelaktiga fel som pekar på databastabeller.

14. Problem med cron-jobb och tidsstyrning

En aspekt som ofta förbises är WordPress interna cron-jobb. Dessa säkerställer t.ex. automatisk publicering av schemalagda inlägg eller regelbundet utförande av underhållsuppgifter för plugins. Om Cron inte fungerar korrekt missar du schemalagda publiceringar, uppdateringar avbryts eller plugins kan inte slutföra sina uppgifter.

Jag kontrollerar därför i min wp-config.php om INAKTIVERA_WP_CRON på falska och om mitt webbhotell använder ett riktigt cron-jobb för att trigga WordPress cron. För högtrafikerade webbplatser kan det vara vettigt att avaktivera WP-cron och i stället skapa en systemcron som körs var 15:e minut. wp-cron.php samtal. Serverloggarna hjälper också till här för att se om fel är dolda i cron-körningen.

15. Stötestenar med automatiska uppdateringar

Å ena sidan är automatiska WordPress-uppdateringar bra för att så snabbt som möjligt täppa till säkerhetsluckor. Å andra sidan kan de oväntat leda till Kompatibilitetsproblem om teman eller plugins ännu inte är förberedda för den senaste versionen. Så snart det är dags för en större uppdatering av WordPress säkerhetskopierar jag först hela min webbplats. Sedan kontrollerar jag om några kända konflikter har rapporterats i plugin-beskrivningarna eller i utvecklarforum.

Ibland är det värt att behålla automatiska uppdateringar endast för mindre versioner och utföra större versionshopp manuellt. På så sätt kan jag avaktivera alla inkompatibla tillägg före uppdateringen eller ersätta dem med alternativ. Om jag får felmeddelanden efter uppdateringen kan jag snabbare ringa in vilket plugin som är orsaken eftersom jag redan vet vad som har ändrats i systemet.

Om du använder ett föråldrat tema kan det hända att nya funktioner i WordPress-kärnan inte längre adresseras korrekt. I sådana fall uppstår den klassiska vita skärmen eller ett 500-fel eftersom temat hänvisar till föråldrade krokar och funktioner. En uppdatering eller ändring av ett aktuellt tema är då ofta det enda sättet att eliminera dessa inkompatibilitetsproblem.

16. Säkerhetsplugins och deras fallgropar

För att skydda sin WordPress-installation installerar många användare säkerhetsplugins som Wordfence, iThemes Security eller liknande lösningar. Jag använder dessa verktyg för att övervaka potentiella intrångsförsök och begränsa inloggningsförsök. Det kan dock hända att Brandväggsinställningarna är för rigida blockera din egen backend. Plötsligt är du utelåst och får ett kryptiskt felmeddelande när du loggar in.

I sådana situationer avaktiverar jag säkerhetstillägget som ett test via FTP genom att helt enkelt byta namn på plugin-mappen. Om jag sedan loggar in utan problem vet jag att fininställningarna i säkerhetstillägget är för strikta. Detsamma gäller för vissa IP-blockerare eller funktioner för att dölja administratörer. Om felaktiga inmatningar görs här kan du inte längre komma åt din WordPress -installation.

Förutom brandväggen övervakar vissa säkerhetsplugins också filändringar i WordPress, vilket är bra, men kan generera många falska positiva resultat vid uppdateringar. Jag rekommenderar därför att du justerar skanningsintervallen och ser till att viktiga kärna-filer blockeras inte av misstag.

Väl förberedd istället för hjälplös

Många fel kan lösas snabbt med ett strukturerat tillvägagångssätt och lite lugn. Jag rekommenderar regelbundna uppdateringar, testade plugins och tillräckligt med webbutrymme. I kritiska situationer kan nödverktyg och transparent hosting-support hjälpa till.

Om din webbplats förblir osäker trots alla åtgärder eller om inte ens logiska åtgärder ger resultat bör du söka professionell hjälp. Artikeln om WordPress säkerhet efter en hackerattack ger dig de första tipsen för nödsituationer.