Kort svar: WordPress opretter filen
.maintenanceunder en opdatering og fjerner den normalt igen. Hvis beskeden står i mere end få minutter, skal du først sikre dig, at opdateringsprocessen ikke stadig arbejder. Omdøb derefter filen i WordPress-roden, genindlæs siden og kontrollér, hvilken core-, plugin- eller temaopdatering der blev afbrudt. Kør opdateringen kontrolleret igen og verificér versioner, filer og logs.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Et kontrolleret vedligeholdelsessvar med Retry-After er efterprøvet med Hostious Article Lab 1.4.1; en ægte fastlåsning skal knyttes til den afbrudte opdatering.
Beskeden “Kortvarigt utilgængelig på grund af planlagt vedligeholdelse” er normal under en opdatering. Problemet opstår, hvis processen stopper, før .maintenance bliver fjernet.
Før du ændrer noget: Tag backup, og kontrollér updaterstatus, aktive PHP-/CLI-processer og seneste log. Fjern ikke filen midt i en igangværende core- eller pluginopdatering.
På denne side
Vent et par minutter ved en almindelig pluginopdatering og kontroller admin i en separat fane. Notér:
| Observation | Handling |
|---|---|
| Updateren arbejder stadig og loggen vokser | Vent; afbryd ikke |
| Ingen proces/logaktivitet, beskeden står fast | Omdøb .maintenance |
| Disk/quota er fuld | Frigør/udvid sikkert før ny opdatering |
| Pluginmappe har midlertidig/ufuld version | Gendan eller geninstaller samme version |
| Coreopdatering blev afbrudt | Kontroller corefiler og databaseopgradering |
Brug tre observationer sammen, før du rører filen: .maintenance-filens seneste ændringstid, updaterens seneste loglinje og om den samme PHP- eller CLI-proces fortsat bruger CPU. Hvis alle tre står stille, er der stærkt belæg for, at låsen er efterladt. Hvis blot loggen eller processen stadig bevæger sig, skal du vente og følge processen i stedet for at fjerne dens sikkerhedsskilt.
Når beskeden er væk efter omdøbningen, afgør den næste request retningen:
WordPress' normale maintenance-response er midlertidig. Notér derfor også HTTP-status og eventuel Retry-After-header. En specialbygget maintenance.php kan ændre både udseende og response, så teksten alene er ikke nok til at afgøre, om WordPress core eller et eksternt deployværktøj ejer tilstanden.
Åbn filmanager eller SSH og find mappen, der indeholder wp-admin, wp-includes og normalt wp-config.php. .maintenance er en skjult fil i denne base.
Sørg for, at skjulte filer vises. På installationer, hvor WordPress core ligger i en undermappe, er public webroot og WordPress-rod ikke altid den samme. Slet ikke en tilfældig .maintenance fra en anden installation på kontoen.
Når updateren er stoppet, omdøb først:
.maintenance → .maintenance.stuck-YYYYMMDD-HHMMEn omdøbning er lettere at rulle tilbage end sletning. Genindlæs forsiden og /wp-admin/. Hvis beskeden forsvinder, har du bekræftet, at filen var den direkte lås – men du har endnu ikke bevist, at opdateringen blev gennemført korrekt.
Når efterkontrollen er afsluttet og backupen er på plads, kan den omdøbte fil fjernes.
Gå til Kontrolpanel → Opdateringer, og sammenlign installerede versioner med updatehistorik/log. Kontrollér den komponent, der blev opdateret:
Kør ikke “opdater alt” igen. Genkør den ene afbrudte opdatering, så du kan se, om problemet ligger i pakken, filrettighederne eller serverressourcerne.
De mest almindelige dokumenterbare årsager er:
Brug Site Health Info til filesystem permissions og serverdata. Sammenlign den berørte mappes ejer/rettigheder med fungerende komponenter. Brug aldrig 777 som generel løsning.
Ved en stor eller kritisk opdatering bør næste forsøg ske på staging. Hvis den samme pakke fejler dér, er det ikke en produktionscache, der er årsagen.
Hvis plugin- eller temamappen er ufuldstændig:
Ved core skal du bruge WordPress' kontrollerede geninstallation/checksumproces og bevare wp-content samt wp-config.php. Overskriv ikke brugerindhold.
Lav testen på staging, hvis du ikke allerede har et fastlåst produktionssite. Brug en lille, reversibel pluginopdatering, som er kompatibel med den installerede WordPress- og PHP-version. Undlad at skabe en falsk .maintenance på produktion; testen skal vise updaterens virkelige adfærd.
.maintenance forsvinder uden manuel handling./wp-admin/ i nye requests.Ved en reel fastlåsning bruges samme protokol, men med to ekstra checkpoints: tidspunktet hvor aktiviteten stoppede, og tidspunktet hvor filen blev omdøbt. Et brugbart sagsnotat kan se sådan ud:
| Checkpoint | Bevis | Bestået når |
|---|---|---|
| Før indgreb | Maintenance-response, fil-timestamp og updaterlog | Ingen aktivitet i det aftalte observationsvindue |
| Efter omdøbning | Ny HTTP-request og PHP-log | Sitet svarer uden ny fatal fejl |
| Efter komponentkontrol | Installeret version og fil-/checksumkontrol | Én entydig, komplet version er aktiv |
| Efter nyt forsøg | Updaterens afslutning og funktionstest | .maintenance fjernes automatisk, og funktionen virker |
Kør ikke en hel kø af ventende opdateringer som eftertest. Hvis nummer to fejler, mister du forbindelsen mellem ændringen og resultatet. Gem også cachepurge til sidst: en frisk cache bør først bygges, når kildefiler og versioner er kendt gode.
En ny fastlåsning ved samme komponent peger på pakken, skriveadgangen eller den konkrete runtime. En fastlåsning ved forskellige komponenter peger oftere på fælleslaget: diskplads, filsystemejer, timeout, workerstop eller samtidige deploys. Gentag ikke manuel filfjernelse som fast drift. Sammenlign i stedet de to hændelsers varighed, logslutning og ressourcegraf, og eskalér med dette fælles mønster.
Et nyttigt mikroeksempel er to fastlåsninger ved forskellige plugins, begge præcis når udpakningen starter. Hvis loggen i begge tilfælde stopper med en skrivefejl og diskpladsen er tæt på nul, er fællesnævneren filsystemet – ikke de to pluginpakker. Frigør eller udvid plads efter hostingens procedure, kontrollér ejerskab, og test derefter kun én lille opdatering.
Hvis .maintenance derimod vender tilbage med et nyt timestamp, efter du har omdøbt den, arbejder en proces stadig eller starter igen. Lad være med at gentage omdøbningen i en løkke. Find processen, cronjobbet eller deploymentet og stop kun efter at have afklaret, om den kan afbrydes sikkert.
Når årsagen er fundet, notér også om automatiske opdateringer eller et eksternt deploysystem kan starte samme forløb igen. Ellers kan den næste planlagte kørsel genskabe fastlåsningen, selv om den manuelle test lykkes.
/wp-admin/ åbner uden maintenance-besked..maintenance normalt, hvis det er forsvarligt at teste.Purge først cache efter kilde og version er verificeret. En cachepurge løser ikke en efterladt fil og kan sende unødige requests til et halvopdateret site.
Hvis omdøbningen afslører et halvopdateret site, kan du midlertidigt gendanne .maintenance-navnet, mens du ruller komponent/core tilbage fra backup. Gendan den tidligere version og databasebackup som et samlet, dokumenteret punkt, hvis opdateringen havde schemaændringer.
Går opdateringen galt igen, er det som regel ressourcer eller filrettigheder. WordPress hosting hos Hostious har staging og daglige backups, så en afbrudt opdatering aldrig rammer det live site.
Hosting skal hjælpe ved fastlåste processer, disk, ejerskab, PHP-timeout eller update-download. Udvikleren skal hjælpe, hvis samme komponentopdatering reproducerbart fejler på staging. Hostious WordPress-support kan gennemgå versioner og rollback.
Dokumentér den berørte WordPress-rod og komponent uden at vise andre serveroplysninger:
.maintenance i den korrekte rod; andre filnavne anonymiseres.Gem filens timestamp, updater- eller logstatus før omdøbning og versions-/HTTP-eftertesten. Ingen serverkonto eller fulde stier må vises.
Fordi en opdatering blev afbrudt, før WordPress fik slettet .maintenance-filen – typisk ved timeout, hukommelsesfejl eller en lukket fane midt i processen.
Nej, hvis opdateringen ikke længere kører. Vent et par minutter, omdøb eller slet filen i WordPress-roden, og genindlæs. Kontrollér bagefter, at den afbrudte opdatering faktisk blev gennemført.
Opdatér i staging først, tag få plugins ad gangen, og sørg for rigelig PHP-hukommelse og timeout. Fejler samme opdatering gentagne gange, er det den, der skal undersøges – ikke filen.