Kort svar: Beskeden betyder, at du er logget korrekt ind – men din bruger har ingen rettigheder. Efter en flytning er årsagen næsten altid, at tabelpræfikset i wp-config.php ikke matcher databasen: WordPress leder efter rettigheder under det nye præfiks, mens de ligger gemt under det gamle. Tjek præfikset begge steder, og ret
$table_prefixi wp-config.php til det, databasen faktisk bruger.
Flytningen gik tilsyneladende fint: forsiden virker, du kan logge ind – og så møder wp-admin dig med “Sorry, you are not allowed to access this page” (på dansk: “Beklager, du har ikke adgang til denne side”). Det føles som en låst dør, men nøglen findes: beskeden handler om rettigheder, ikke om login, og efter en migrering peger den næsten altid samme sted hen.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med anonymiserede præfikser og viser mekanismen – det er ikke output fra hostious.io.
En 403 Forbidden kommer fra serveren eller en firewall, før WordPress overhovedet svarer. “Sorry, you are not allowed” kommer derimod fra WordPress selv: requesten nåede frem, du er logget ind, men WordPress kan ikke finde en rolle på din bruger, der giver adgang. Det skel afgør, hvor du skal lede – her handler det om databasen, ikke om serveren.
WordPress gemmer brugerrettigheder i databasen under nøgler, der indeholder tabelpræfikset: rettighederne ligger i usermeta som PRÆFIKS_capabilities, og rollerne i options som PRÆFIKS_user_roles. Skifter præfikset – fordi wp-config.php blev sat op påny under flytningen, eller fordi databasen kommer fra en anden opsætning – leder WordPress efter wpnyt_capabilities, mens databasen indeholder wpgml_capabilities. Resultatet: du findes som bruger, men uden rettigheder.
Sammenlign to ting: $table_prefix i wp-config.php og de faktiske tabelnavne i databasen (phpMyAdmin viser dem i venstre kolonne). Med WP-CLI kan du se begge dele på få sekunder:
$table_prefix i wp-config.php til databasens præfiks. Én linje, ingen data-ændringer – det er den rigtige løsning i langt de fleste flyttesager.PRÆFIKSgammel_capabilities → PRÆFIKSnyt_capabilities, PRÆFIKSgammel_user_level → PRÆFIKSnyt_user_level i usermeta, og PRÆFIKSgammel_user_roles → PRÆFIKSnyt_user_roles i options. Tag en databasebackup først.Bland aldrig de to veje sammen: vælg én kilde til sandheden – enten følger wp-config databasen, eller databasen bringes på linje med wp-config – og gennemfør den hele vejen.
Matcher præfikserne, så tjek disse i rækkefølge: Brugerens rolle kan reelt være fjernet eller nedgraderet – en anden administrator kan bekræfte under Brugere. Sitet kan være flyttet fra et multisite, hvor rettigheder lå på netværksniveau og ikke fulgte med ud. Og enkelte sikkerhedsplugins begrænser adgangen til udvalgte admin-sider – deaktiver dem kortvarigt via konflikttest-metoden, hvis beskeden kun rammer bestemte sider.
Sagen er lukket, når du kan åbne alle admin-sider, din bruger står som administrator under Brugere, og et gem af permalinks går igennem uden fejl. Gennemgå til sidst de øvrige brugere – en præfiks-fejl rammer alle på én gang, så kollegernes roller skal også være på plads. Flytter du til Hostious, er den slags tjek i øvrigt en del af den gratis migrering – så opdages præfiks-problemer, før du gør.
Fordi forsiden ikke kræver rettigheder. WordPress finder fint indholdet i databasen – det er kun koblingen mellem din bruger og en rolle, der er knækket.
Nej. Indlæg, sider, ordrer og brugere ligger urort i databasen. Fejlen sidder i én konfigurationslinje eller nogle få meta-nøgler – og begge dele kan rettes uden tab.
Ja: flyt altid wp-config.php’s $table_prefix sammen med databasen, og test wp-admin som det første efter flytningen. Eller lad hostingudbyderen stå for flytningen – så er præfiks-tjekket deres ansvar.