Hemsidan visar ett fel

En tom vit sida, ett HTTP 500-fel eller ett meddelande om ett kritiskt WordPress-fel kan bero på ett PHP-fel i ett plugin, tema eller anpassad kod. Kontrollera felloggarna för att identifiera orsaken innan du ändrar något.

Om du istället ser "Briefly unavailable for scheduled maintenance" är hemsidan fast i underhållsläge - se Fast i underhållsläge för en snabbfix med ett klick.

Läs det faktiska felet

Det snabbaste stället att se det underliggande felet är fliken Loggar i Templ-panelen - ingen installation behövs:

Öppna din hemsida i Templ-panelen och gå till fliken Loggar.
Under Log, välj Error log och klicka sedan på Fetch logs.
Ladda om sidan som visar fel, hämta igen och läs de senaste posterna. De namnger vanligtvis filen och raden som orsakar felet.

Om felloggarna inte visar tillräckligt med detaljer, aktivera WordPress felsökning för att fånga det fullständiga PHP-felet i en fil:

Följ Aktivera WordPress felsökning för att slå på WP_DEBUG och WP_DEBUG_LOG.
Ladda om sidan som visar fel och läs sedan wp-content/debug.log. De sista posterna namnger vanligtvis filen och raden som orsakar felet.

Felmeddelandet pekar ofta direkt på en specifik plugin- eller temafil.

Isolera orsaken

Om felet namnger ett specifikt plugin, inaktivera bara det från panelens Inaktivera plugins-verktyg - det fungerar även när hemsidan visar en vit skärm. Om felet inte namnger en uppenbar bov, inaktivera plugins och teman för att isolera det: inaktivera alla plugins och byt till ett standardtema, aktivera dem sedan ett i taget tills felet återkommer.

Om hemsidan inte är helt nere - felet träffar bara vissa sidor - felsök på en staging-sajt istället, så att besökare inte påverkas.

Vanliga problem och lösningar

Elementor-fel efter en uppdatering

Elementor- och Elementor Pro-versioner som inte fungerar tillsammans kan orsaka ett kritiskt fel eller HTTP 500-respons. Felloggarna kan visa:

Class "Elementor\Modules\AdminBar\Module" not found

Kontrollera båda installerade versionerna under Tillägg → Installerade tillägg i WordPress. Detta fel ensamt bekräftar inte en versionskonflikt: en ofullständig eller korrupt uppdatering kan se likadan ut, och olika versionsnummer är inte nödvändigtvis inkompatibla.

Om felet började efter att ett plugin uppdaterades, återställ en känd fungerande kombination genom att uppdatera det andra till en kompatibel version eller rulla tillbaka den senaste uppdateringen. Skapa en backup innan du ändrar versioner. Om du inte kan komma åt WordPress, kontakta support med felet och eventuella versionsdetaljer du har.

Granska därefter båda pluginens inställningar för automatiska uppdateringar. Om automatiska uppdateringar orsakade konflikten, hantera deras uppdateringar tillsammans och testa på staging först istället för att lämna något av pluginen föråldrat.

Databasanslutningsfel efter en återställning eller staging-kopiering

Om du ser "Error establishing a database connection" efter att ha återställt en backup eller kopierat staging, kan databasåtkomsten ha misslyckats även om datan återställdes. Meddelandet ensamt betyder inte att databasen saknas. Innan du upprepar återställningen eller byter ut databasen, kontakta support med operationen, tid inklusive tidszon och felet så att vi kan kontrollera åtkomst och den återställda datan.

Rulla tillbaka en nylig ändring

Om felet dök upp direkt efter en uppdatering eller redigering, ångra den ändringen - och återställ inte mer än nödvändigt.

Om ett plugin är felet, inaktivera det som beskrivits ovan - ingen återställning behövs.
Om trasig kod är orsaken, gör en partiell återställning av endast de berörda filerna och kryssa i Do not restore database, så att du inte förlorar beställningar, inlägg och annan data som skapats sedan backupen.
För en pluginuppdatering, rulla tillbaka den till föregående version över SSH.
En fullständig backup-återställning är sista utvägen, eftersom den också rullar tillbaka databasen.

Om du inte kan tolka felet, kontakta support med de relevanta raderna från Error log i fliken Loggar (eller från debug.log) så hjälper vi dig att läsa dem.

Verifiera fixet

Testa den ursprungliga felande URL:en igen med ?nocache=123456 tillagd (använd &nocache=123456 om den redan har en query string). Bekräfta X-Cache-Status: BYPASS med hjälp av cache-status-instruktionerna; detta kringgår Templ Cache, men inte nödvändigtvis en tredjepartscache.

Testa den berörda funktionen, inte bara hemsidan, och kontrollera loggar för den nya förfrågans tidsstämpel. En gammal felpost betyder inte att problemet kvarstår.