Föreställ dig det här: du har skrivit klart ett inlägg, klickat på "Publicera" och WordPress visar en röd banner med ett felmeddelande. Uppdatera sidan? Samma fel. Logga ut och in i adminpanelen igen? Ingen förändring. Inlägget sitter fast i utkast och tiden rinner iväg.

Felet "Uppdatering misslyckades" eller "Publicering misslyckades" är ett av de problem som gör dig frågande: meddelandet talar inte om exakt vad som gick sönder. Men efter år av arbete med WordPress har vi tagit fram en tydlig felsökningskedja. I de flesta fall ligger orsaken på ytan och det tar bara några minuter att åtgärda.

I den här guiden hittar du 7 beprövade metoder: från de enklaste (internetanslutning och webbplatsens URL) till riktad felsökning via wp-config och arbete med tillägg. Varje steg innehåller specifika åtgärder och skärmdumpar från adminpanelen.

💡 Snabb översikt:

• Kontrollera din internetanslutning och webbplatsens URL i inställningarna
• Öppna "Verktyg → Webbplatshälsa" och kontrollera REST API-statusen
• Aktivera felsökningsläge via WP_DEBUG i wp-config.php
• Ta bort den tillfälliga filen .maintenance från servern via FTP
• Avaktivera alla tillägg samtidigt och aktivera dem sedan ett i taget för att identifiera konflikten
• Ersätt tillfälligt Gutenberg med Classic Editor för att utesluta en blockredigerarkonflikt
• Om inget fungerar, kontakta ditt webbhotell eller WordPress-communityn

1. Kontrollera din internetanslutning och webbplatsens URL

Den enklaste (och därför ofta förbisedda) orsaken: WordPress tappar anslutningen till servern mitt i en begäran.

Öppna en annan webbläsarflik och besök en webbplats. Laddades sidan? Din internetanslutning fungerar. Om inte, återställ anslutningen och försök publicera inlägget igen.

Om internet fungerar är nästa misstänkta URL-inställningarna. Efter år av migreringar, domänbyten och HTTPS-experiment avviker adresserna under "Inställningar → Allmänt" ibland från verkligheten. Gå dit och jämför två fält: WordPress-adress (URL) och Webbplatsadress (URL). De ska matcha den faktiska adress du använder för att komma åt adminpanelen.

Om båda adresserna är korrekta men felet kvarstår, låt oss gräva djupare.

2. Kontrollera REST API-statusen

WordPress REST API är mekanismen genom vilken Gutenberg-redigeraren kommunicerar med servern. När REST API inte svarar eller returnerar ett fel slutar "Publicera"-knappen att fungera.

Som tur är innehåller WordPress 5.2 och senare ett inbyggt diagnosverktyg. Gå till Verktyg → Webbplatshälsa. Scrolla ner till avsnittet "Rekommenderade förbättringar" och leta efter raden "REST API stötte på ett oväntat resultat" eller ett liknande fel.

Om REST API visar ett fel, expandera felsökningsinformationen direkt på fliken "Info" → "REST API". Du ser det specifika anrop som misslyckades och serverns svarskod. Oftast ligger problemet i:

• Ett säkerhetstillägg som blockerar REST-förfrågningar (Wordfence, iThemes/Solid Security med aggressiva brandväggsinställningar);
• Egen kod i functions.php som av misstag bryter REST-slutpunkter;
• Ett cachelagringstillägg som serverar ett cachat REST API-svar.

Avaktivera det misstänkta tillägget och kontrollera REST API-statusen igen på samma sida.

3. Aktivera WordPress felsökningsläge

När problemet inte är uppenbart måste du "belysa" det. WordPress har ett inbyggt felsökningsläge för detta ändamål.

Du behöver tillgång till webbplatsens filer. En FTP-klient (FileZilla, WinSCP) eller filhanteraren i din webbhotellspanel fungerar. Innan du gör några filändringar, skapa en säkerhetskopia. Ett fel i wp-config.php kan ta ner din webbplats, men en säkerhetskopia återställer allt på en minut.

Steg att följa:

• Anslut till servern via FTP och hitta WordPress rotmapp (där wp-content, wp-admin och wp-includes finns).
• Hitta filen wp-config.php och ladda ner den till din dator.
• Öppna filen i en textredigerare (Notepad++, Sublime Text, inte Word eller Anteckningar, som kan förstöra teckenkodningen).
• Längst ner, före raden /* That's all, stop editing! Happy publishing. */, lägg till:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Den första raden aktiverar felsökning, den andra skriver fel till filen wp-content/debug.log (utan att visa dem för besökare) och den tredje döljer fel från webbplatsens visning.

Spara filen och ladda upp den till servern igen och ersätt originalet. Försök nu publicera ett inlägg. Om felet är borta var orsaken en PHP-varning som störde REST-svaret. Öppna wp-content/debug.log via samma FTP och leta efter poster med PHP Notice eller PHP Warning. De pekar ut det problematiska tillägget.

När du är klar, se till att avaktivera WP_DEBUG genom att ersätta true med false. Annars växer debug.log obegränsat.

Om felet kvarstår, låt oss gå vidare.

4. Ta bort.maintenance-filen

WordPress skapar en tillfällig .maintenance-fil i webbplatsens rot under uppdateringar av kärnan, tillägg och teman. Den försätter webbplatsen i underhållsläge och besökare ser meddelandet "Kort otillgänglig för schemalagt underhåll. Kom tillbaka om en minut."

Ibland avslutas uppdateringen men .maintenance finns kvar. WordPress tror att underhåll fortfarande pågår och blockerar publicering.

Öppna FTP igen, gå till rotmappen och hitta filen .maintenance (med en punkt i början, den är dold; i FileZilla aktiverar du visning av dolda filer via "Server → Tvinga visning av dolda filer").

Ta bort .maintenance och kontrollera publiceringen omedelbart. Effekten varar i cirka 10 minuter (WordPress återskapar filen om en uppdatering fortfarande är aktiv). Om felet försvinner men återkommer efter 10 minuter pågår en bakgrundsuppdatering fortfarande. Vänta eller tvinga den att slutföras via "Tillägg → Installerade tillägg" (du ser uppdateringsstatusen där).

5. Hitta det motstridiga tillägget

Den vanligaste orsaken till publiceringsfel är tilläggskonflikter. Ett tillägg bryter REST API, ett annat stör sparprocessen och ett tredje hamnar i konflikt med Gutenberg.

Det snabba sättet att hitta boven är massavaktivering med sekventiell återaktivering:

• Gå till Tillägg → Installerade tillägg.
• Markera kryssrutan "Tillägg" i tabellhuvudet för att välja alla.
• I rullgardinsmenyn "Massåtgärder", välj "Avaktivera" och klicka på "Verkställ".

Nu är alla tillägg avaktiverade. Försök publicera ett inlägg. Fungerade det? Bra, orsaken är ett av tilläggen. Aktivera dem ett i taget och kontrollera publiceringen efter varje. Så snart felet återkommer har du hittat boven.

Vad du ska göra med det problematiska tillägget:

• Uppdatera det till den senaste versionen (utvecklaren kan redan ha åtgärdat felet).
• Kontakta tilläggets support med detaljer: WordPress-version, tilläggsversion och vilken åtgärd som utlöser felet.
• Ersätt det tillfälligt med ett alternativ tills utvecklaren släpper en korrigering.

6. Ersätt tillfälligt Gutenberg med Classic Editor

Gutenbergs blockredigerare introducerades i WordPress 5.0 och har kommit långt sedan dess. Men konflikter med vissa tillägg och teman förekommer fortfarande, särskilt med äldre sidbyggare (WPBakery, gamla versioner av Elementor) och tillägg som inte är anpassade för REST API.

Classic Editor använder inte REST API för att spara. Den fungerar via den gamla admin-ajax.php. Så att installera den är ett snabbt test: om felet försvinner ligger problemet specifikt i kombinationen Gutenberg + något tillägg.

Installera Classic Editor, det officiella tillägget från WordPress-teamet:

• Tillägg → Lägg till nytt.
• I sökningen, skriv "Classic Editor".
• Klicka på "Installera nu", sedan "Aktivera".

Efter aktivering, försök publicera ett inlägg via den klassiska redigeraren. Fungerar det? Då ligger konflikten på Gutenbergs sida.

Viktigt: detta är ett diagnostiskt steg, inte en permanent lösning. Classic Editor avaktiverar blockredigeraren och du förlorar alla Gutenberg-funktioner: block, mallar, inbyggd formatering. När du hittat det problematiska tillägget (med metoden från steg 5), ta bort Classic Editor och återgå till Gutenberg med en fixad miljö.

7. Sök hjälp

Om du har genomfört alla sex steg och felet kvarstår ligger problemet troligen djupare: på servernivå, webbhotellsnivå eller ett sällsynt fel i WordPress-kärnan.

Här är vart du kan vända dig, i effektivitetsordning:

Webbhotell. Kontakta deras support med detaljer: WordPress-version, PHP-version, vilka tillägg som är aktiva och vilken åtgärd som utlöser felet. Webbhotellet har tillgång till serverloggar och kan ofta upptäcka orsaken på en minut (diskutrymmet tog slut, en PHP-modul är avaktiverad, minnesgränsen överskriden).

WordPress-forum. Det officiella WordPress.org supportforum är en levande community där kärnutvecklare och tilläggsförfattare svarar. Öppna ett ämne, bifoga skärmdumpar och utdata från debug.log.

Efter att ha läst den här guiden har du en komplett diagnoskedja: från ett musklick till redigering av serverfiler. I 9 av 10 fall löses problemet med steg 1-5, utan FTP eller wp-config.

Nedan hittar du svar på de vanligaste frågorna och en video för att befästa materialet.

⁉️🤔 Vanliga frågor

Varför uppstår felet direkt efter uppdatering av WordPress?

Troligtvis är ett av tilläggen inkompatibelt med den nya kärnversionen eller den nya PHP-version som webbhotellet aktiverade i samband med uppdateringen. Gå igenom steg 5 (massavaktivering) så hittar du snabbt boven.

Kan jag bara ominstallera WordPress utan att felsöka?

Att ominstallera kärnan via "Uppdateringar → Ominstallera nu" är säkert och rör inte innehåll/tillägg. Men om felet orsakas av en tilläggskonflikt hjälper det inte att ominstallera kärnan. Det är bättre att lägga 5 minuter på diagnosstegen ovan än att blint prova slumpmässiga lösningar.

Varför visas felet bara på ett inlägg medan andra publiceras normalt?

Den troliga orsaken är själva innehållet i inlägget. Någon kombination av Gutenberg-block, en inbäddad iframe eller ett skript orsakar ett fel under sparandet. Försök kopiera innehållet till ett nytt inlägg och publicera det. Om det nya inlägget publiceras framgångsrikt, ta bort det gamla och arbeta med kopian.

Bör jag behålla Classic Editor permanent efter att ha åtgärdat problemet?

Nej. Classic Editor är en tillfällig diagnostisk lösning. När du har hittat och åtgärdat det motstridiga tillägget, ta bort Classic Editor och återgå till Gutenberg. Blockredigeraren är WordPress-standarden och du bör inte överge den utan allvarliga skäl.

Vad ska jag göra om jag inte har FTP-åtkomst?

Använd filhanteraren i din webbhotellspanel (cPanel → File Manager, ISPmanager → Filer). Funktionsmässigt gör den samma sak. Om det inte heller är tillgängligt, kontakta ditt webbhotells support så hjälper de dig att få åtkomst.

Vilken metod bör du prova först?

Den universella formeln: kontrollera internet (10 sekunder) → titta på Webbplatshälsa (30 sekunder) → massavaktivera tillägg (1 minut). I de flesta fall är problemet redan löst i detta skede.

Om felet återkommer efter en korrigering har du hittat ett symptom snarare än grundorsaken. Aktivera WP_DEBUG_LOG (steg 3) och samla en komplett logg. Den visar exakt fil och rad med felet. Med denna logg kan du kontakta tilläggets supportteam eller WordPress-forumet.

Och viktigast av allt: ha alltid en färsk säkerhetskopia. Den förvandlar varje misslyckande från en katastrof till en fem minuters fördröjning.