De mest almindelige WordPress fejl – og hvordan du løser dem

Når du kender mønstrene, bliver fejlsøgning langt mindre stressende. De fleste fejl kan koges ned til: et plugin, et tema, en opdatering, en PHP-indstilling eller en serverbegrænsning, der kommer på tværs. Dine data er næsten altid stadig der – de skal “bare” gøres tilgængelige igen.

Denne artikel fungerer som en slags fejl-encyklopædi for klassiske WordPress problemer. Du får både forklaring på, hvad fejlene betyder, hvad de typisk skyldes, trin du selv kan prøve – og klare pejlemærker for, hvornår du skal stoppe og ringe efter hjælp.

Sådan griber du WordPress fejl an – en generel strategi

Inden vi går ned i de konkrete fejl, er det værd at have en generel metode.
Ellers ender man let i “jeg prøver bare alt”-mode, og det giver mere rod end løsninger.

Bevar roen – og tag backup først

Det er fristende at klikke løs og slette ting, når sitet er nede.
Men panik gør det ofte værre – især hvis du ikke har en frisk backup.

Inden du begynder at ændre filer, database eller indstillinger, så:

• Tag en backup via dit webhotels kontrolpanel eller et backup-plugin.
• Har du ingen backup, så vær ultra forsigtig: lav kun én ændring ad gangen og skriv ned, hvad du gør.
• Undgå drastiske ting som at slette databaser, reinstallere WordPress eller nulstille hele installationen, medmindre du er 100 % sikker.

Sørg for de rigtige værktøjer

For at kunne løse de fleste WordPress fejl i praksis, har du brug for adgang til:

• FTP/SFTP eller filhåndtering i dit kontrolpanel, så du kan omdøbe mapper, slette filer og uploade nyt.
• Database-adgang (phpMyAdmin eller lignende), så du kan tjekke tabeller, reparere og justere indstillinger.
• Webhotel-kontrolpanel, hvor du kan se error logs, ændre PHP-version, justere ressourcer og håndtere domæner og SSL.

Har du de tre ting, kan du løse rigtig meget uden at være hardcore udvikler.
Har du dem ikke, bliver du ret hurtigt afhængig af hostens support.

Brug WP_DEBUG klogt

Når du kun ser en hvid skærm eller en generisk fejl, mangler du detaljer.
Du kan ofte få mere information ved at aktivere debugging i wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Det opretter en logfil i wp-content/debug.log, hvor du kan se PHP-fejl, der hjælper dig (eller din udvikler) tættere på problemet.

Når du er færdig med at fejlsøge, skal du slå det fra igen:

define( 'WP_DEBUG', false );

Så undgår du, at besøgende ser potentielt følsomme fejlmeddelelser.

Tænk i “hvor” fejlen kommer fra

Næsten alle WordPress fejl kan placeres i én af disse kategorier:

• Plugins – nye plugins, opdateringer eller konflikter mellem flere.
• Tema – fejl i temaet eller i functions.php.
• Core – korrupte WordPress filer eller mislykkede opdateringer.
• Server – PHP-version, memory limit, filrettigheder, database-nedbrud.
• Indhold/konfiguration – permalinks, SSL, domæneændringer, redirects.

Jo hurtigere du kan indsnævre, hvilken kategori problemet ligger i, jo hurtigere kan du finde løsningen.

500 internal server error

Hvad betyder 500 internal server error?

En 500 internal server error betyder, at serveren godt kan se din forespørgsel, men rammer en fejl, som den ikke kan håndtere ordentligt. I stedet for en specifik fejlbesked får du bare den generelle “500 internal server error”.

I WordPress sammenhæng betyder det typisk, at noget i PHP-koden dør undervejs – ofte et plugin, et tema eller en forkert konfiguration i .htaccess. Serveren opgiver simpelthen at køre resten af scriptet og sender en “der gik noget galt”-besked tilbage.

Det betyder ikke, at dine indlæg eller sider er væk. Fejlen ligger i eksekveringen, ikke i selve indholdet, og i langt de fleste tilfælde kan problemet fikses uden datatab.

Typiske årsager til 500-fejl

Her er de mest almindelige årsager i praksis:

• Korrupte eller forkerte regler i .htaccess, især på Apache-servere.
• Plugins, der laver fatal PHP-fejl, fx efter en opdatering eller konflikt.
• Temafejl, typisk i functions.php eller custom skabeloner.
• For lavt PHP memory limit, så WordPress løber tør for hukommelse.
• Korrupte core-filer, fx efter mislykkede opdateringer eller dårlig migrering.
• Forkerte filrettigheder, så serveren ikke kan læse/eksekvere nødvendige filer.

Sådan løser du 500 internal server error – trin for trin

1. Genopbyg .htaccess

Start med det nemmeste og mest ufarlige:

• Log ind via FTP eller filhåndtering.
• Find .htaccess i roden af WordPress (samme sted som wp-config.php).
• Download en kopi til din egen computer som backup.
• Omdøb filen på serveren til noget som htaccess_old.
• Prøv at genindlæse din hjemmeside.

Hvis siden virker igen, skal du regenerere permalinks:

• Log ind i WordPress admin.
• Gå til Indstillinger → Permanente links.
• Tryk Gem ændringer uden at ændre noget.

WordPress opretter nu en ny, frisk .htaccess med standard-reglerne. Husk i denne forbindelse altid at tilbageføre eventuelle redirects som deer er skrevet i .htaccess da du ellers kan ende ud i at de redirects ikke virker mere.

2. Deaktiver alle plugins via FTP

Hvis .htaccess ikke er synderen, går vi efter plugins:

• Gå til wp-content/ i FTP.
• Omdøb mappen plugins til fx plugins_old.
• Indlæs din hjemmeside igen.

Hvis 500-fejlen forsvinder nu, ved du, at det er et pluginproblem.

Sådan finder du det konkrete plugin:

• Opret en ny tom mappe, der hedder plugins.
• Flyt plugins én for én tilbage fra plugins_old til plugins.
• Aktivér dem i backend og test sitet mellem hver aktivering.
• Når fejlen kommer igen, har du fundet det plugin, der skaber problemet.

3. Test med et standardtema

Hvis 500-fejlen også opstår med alle plugins slået fra, er temaet næste kandidat:

• Sørg for, at der ligger et standardtema som Twenty Twenty-Five i wp-content/themes/.
• Hvis du kan logge ind, så aktivér det under Udseende → Temaer.
• Hvis du ikke kan logge ind, kan du omdøbe mappen for dit aktive tema.
• WordPress vil så forsøge at falde tilbage til et standardtema automatisk.

Virker sitet med standardtemaet, er det tydeligt, at fejlen ligger i dit oprindelige tema.

4. Øg PHP memory limit

Hvis du stadig får 500-fejl, kan WordPress være løbet tør for hukommelse:

• Åbn wp-config.php.
• Tilføj (eller justér) linjen:

define( 'WP_MEMORY_LIMIT', '256M' );

Virker det, var memory-limit en del af problemet.
Virker det ikke, kan serveren have et hårdere loft i php.ini, som hosten skal ændre.

5. Geninstaller WordPress core-filer

Som sidste DIY-skridt kan du sikre, at WordPress’ egne filer ikke er korrupte:

• Download en frisk WordPress pakke fra wordpress.org.
• Pak den ud lokalt.
• Upload mapperne wp-admin og wp-includes til serveren og overskriv de eksisterende.
• Rør ikke wp-content og wp-config.php.

Det sikrer, at selve WordPress motoren er ren, uden at du mister temaer, plugins eller indhold.

Hvornår skal du ringe efter hjælp ved 500-fejl?

Stop selv-forsøgene og få hjælp, når:

• 500-fejlen bliver ved, selvom du har testet .htaccess, plugins og tema.
• Error logs peger på kompliceret custom kode eller avancerede serverproblemer.
• Du ikke kan hæve memory limit, men stadig rammer grænsen ved normal brug.

Her giver det mening at kontakte både webhotel og en WordPress udvikler.
Hosten kan hjælpe med serverdelen, mens udvikleren kan tage sig af koden.

“Error establishing a database connection”

Hvad betyder “Error establishing a database connection”?

“Error establishing a database connection” betyder, at WordPress ikke kan få adgang til den database, hvor alt dit indhold ligger.
WordPress selv er kun koden – selve sidens indhold, indstillinger mm. “bor” i databasen.

Når denne fejl vises, er WordPress i bund og grund ude af stand til at hente indlæg, sider, indstillinger og brugere.
Det er lidt som at have en webshop, hvor alt varerne står på lageret, men hvor nøglen til lagerdøren ikke virker.

Fejlen opstår typisk, når login-oplysningerne til databasen er forkerte, eller når databasen er nede eller beskadiget.
I nogle tilfælde kan det også være et tegn på, at serveren simpelthen er overbelastet og ikke accepterer flere forbindelser.

Typiske årsager til databasefejlen

De mest almindelige scenarier er:

• Forkert database-navn, brugernavn, password eller host i wp-config.php.
• Databaseserveren (MySQL/MariaDB) er nede, fx pga. hostingproblemer.
• Korrupte tabeller i databasen, hvor dele af data er skadet.
• For mange samtidige forbindelser eller ressourcebegrænsninger på database-serveren.

Sådan løser du “Error establishing a database connection”

1. Tjek database-oplysninger i wp-config.php

Åbn wp-config.php i roden af din WordPress installation.
Her står:

define( 'DB_NAME', 'dit_db_navn' );
define( 'DB_USER', 'dit_db_brugernavn' );
define( 'DB_PASSWORD', 'dit_db_password' );
define( 'DB_HOST', 'localhost' );

Sammenlign:

• DB_NAME med database-navnet i dit webhotels kontrolpanel.
• DB_USER og DB_PASSWORD med de login-oplysninger, der er oprettet til databasen.
• DB_HOST – ofte localhost, men nogle hostings bruger et specifikt hostnavn.

Bare ét forkert tegn kan være nok til, at WordPress ikke kan logge ind.

2. Tjek om databasen faktisk indeholder dine tabeller

Log ind i phpMyAdmin (eller et tilsvarende værktøj).

• Vælg den database, som DB_NAME peger på.
• Tjek om du ser tabeller som wp_posts, wp_users, wp_options osv.

Hvis databasen er tom, kan du have tilsluttet det forkerte database-navn.
Hvis der slet ikke findes en database med det navn, kan den være blevet slettet.

Har du en backup, kan databasen gendannes, men det kræver ofte hjælp fra hosten eller en teknisk person.

3. Brug WordPress’ indbyggede reparationsværktøj

Hvis databasen eksisterer, men nogle tabeller er korrupte, kan du prøve WordPress’ egen reparationsfunktion:

• Tilføj i wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

• Gå til: https://din-side.dk/wp-admin/maint/repair.php i din browser.
• Vælg “Reparer” eller “Reparer og optimer”.

Når du er færdig, fjerner du igen linjen med WP_ALLOW_REPAIR for at lukke adgangen.

4. Spørg hosten, om databasen er nede eller presset

Hvis oplysningerne i wp-config.php er korrekte, og databasen ser fin ud, kan problemet ligge hos hosten:

• Databaseserveren kan være midlertidigt nede.
• Der kan være for mange forbindelser.
• Der kan være overordnede performance-problemer.

Tjek eventuelle status-sider fra hosten eller kontakt deres support direkte.
Ofte kan de hurtigt be- eller afkræfte, om der er aktuelle databaseproblemer.

Hvornår skal du ringe efter hjælp ved databasefejl?

Få hjælp, når:

• Du ikke kan matche database-oplysningerne til noget som helst i kontrolpanelet.
• Databasen ser tom ud, men du ved, at siden har eksisteret med indhold.
• Reparationsværktøjet melder alvorlige fejl eller ikke kan gennemføre.

I de situationer er det ofte en kombination af host-support og udvikler, der skal til.
Det handler både om at sikre infrastrukturen og om at redde mest muligt indhold.

White screen of death (WSoD) / kritisk fejl

Hvad betyder white screen of death?

White screen of death betyder, at du forsøger at åbne din WordPress side – og i stedet får en helt hvid skærm uden indhold.
Ingen fejlmeddelelser, ingen HTML, ingenting.

I nyere WordPress versioner kan du nogle gange se teksten “Der er opstået en kritisk fejl på dette websted”, men mekanikken bag er den samme.
Et stykke PHP-kode stopper så fatalt, at WordPress ikke når at vise siden.

Det er næsten altid et tegn på en fatal fejl i et plugin, tema eller stykke custom kode.
Alternativt kan det være et tegn på, at memory limit er blevet ramt, så scriptet bliver stoppet midt i eksekveringen.

Typiske årsager til WSoD

De mest almindelige syndere er:

• Opdaterede eller nye plugins, der ikke er kompatible med din version af WordPress eller PHP.
• Fejl i temaets functions.php, især hvis du har indsat custom kode.
• For lavt memory limit, så scriptet løber tør midt i en proces.
• Korrupte WordPress filer, typisk efter mislykkede opdateringer eller afbrudte uploads.

Sådan håndterer du white screen of death

1. Aktivér debug-log

Start med at få mere information:

• Slå debug til i wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

• Indlæs siden igen.
• Tjek filen wp-content/debug.log via FTP.

Her vil du ofte se fejl af typen:

PHP Fatal error: Call to undefined function … i /wp-content/plugins/navnet/fil.php

Det giver dig et meget konkret sted at starte.

2. Deaktiver alle plugins

Hvis loggen peger på et plugin – eller du slet ikke kan logge ind – gør du:

• Omdøb mappen wp-content/plugins til plugins_old.
• Prøv at åbne siden igen.

Virker den nu, er det et pluginproblem.
Så finder du synderen på samme måde som ved 500-fejl: flyt plugins tilbage ét ad gangen og test.

3. Skift tema midlertidigt

Hvis ingen plugins ser ud til at være synderen, eller loggen peger på temaet:

• Sørg for, at et standardtema ligger i wp-content/themes/.
• Omdøb mappen for dit aktive tema.
• WordPress vil forsøge at aktivere standardtemaet automatisk.

Hvis WSoD forsvinder, er fejlen næsten helt sikkert i dit oprindelige tema.
Det kan være i functions.php eller i en skabelonfil.

4. Justér memory limit

Hvis loggen viser memory-relaterede fejl, skal du hæve memory limit:

define( 'WP_MEMORY_LIMIT', '256M' );

Hjælper det ikke, kan begrænsningen ligge i serverens php.ini, og så skal hosten justere den.

Hvornår skal du ringe efter hjælp ved WSoD?

Overvej at få hjælp, når:

• Debug-loggen viser fejl i kode, du ikke forstår eller selv vil pille i.
• Fejlen ligger i et komplekst premium-plugin eller -tema, hvor du ikke kan gennemskue strukturen.
• Du har selv indsat kode og nu har WSoD, men ikke lige kan se, hvor fejlen er.

En udvikler kan ofte på relativt kort tid identificere og rette fejlen – især hvis du kan sende debug.log med.

“Allowed memory size exhausted” / Memory exhausted

Hvad betyder memory exhausted?

Fejlen “Allowed memory size exhausted” betyder, at PHP-scriptene på dit site har brugt al den hukommelse, de må bruge, og forsøger at bruge mere.
Når den grænse nås, stopper PHP med en fatal fejl for at beskytte serveren.

I praksis er det som at have en computer med for lidt RAM og åbne for mange tunge programmer.
På et tidspunkt kører det bare ikke længere, og systemet lukker noget ned.

I WordPress dukker det ofte op:

• Når du bruger tunge page builders eller WooCommerce med mange udvidelser.
• Når du laver imports, backup, scanning eller andre tunge processer.
• Når tema og plugins samlet set bare kræver mere, end din nuværende opsætning kan give.

Typiske årsager til memory exhausted

De typiske forklaringer er:

• Mange tunge plugins aktiveret samtidig.
• Dårligt optimerede plugins eller temaer, der bruger unødigt meget RAM.
• Store datamængder, fx mange produkter, store queries, tunge rapporter.
• Lavt sat memory limit på en i forvejen presset hosting.

Sådan løser du memory exhausted

1. Hæv memory limit via wp-config.php

Start med at give WordPress noget mere luft:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Gem filen og test der, hvor fejlen opstår (fx ved upload, import eller visning af en bestemt side).
Hvis fejlen forsvinder, var det den primære årsag.

2. Identificér de mest ressourcetunge plugins

Hvis fejlen bliver ved:

• Deaktiver midlertidigt de mest tunge plugins (page builder, backup, sikkerhed, WooCommerce-tilføjelser).
• Prøv igen at udføre den handling, der gav fejlen.
• Tænd plugins ét ad gangen for at se, hvor memory-forbruget eksploderer.

Når du har identificeret synderen, har du nogle muligheder:

• Skift til et mere letvægts-plugin, hvis det findes.
• Justér indstillingerne, fx færre scanninger, mindre aggressive funktioner.
• Flyt tunge opgaver som backup til et eksternt værktøj.

3. Ryd op i database og indhold

Nogle gange er problemet, at din installation er vokset “skævt” over tid:

• Mange gamle revisions af indlæg.
• Masser af forældede transients og log-data.
• Plugins, der har efterladt data, selvom de er slettet.

Et seriøst oprydningsplugin – eller en udvikler med SQL-handskerne på – kan fjerne meget unødvendigt skrammel.
Det gør ofte både sitet hurtigere og mindre hukommelsestungt.

Hvornår skal du ringe efter hjælp ved memory-fejl?

Hvis du allerede har sat memory limit fornuftigt højt (256–512 MB), og fejlen stadig opstår, er det tid til hjælp.
Det kan være, at arkitekturen simpelthen er for tung til den hosting, du bruger.

En udvikler kan hjælpe med at profilere forbruget og foreslå konkrete optimeringer.
I nogle tilfælde er svaret dog ærligt talt: flyt til bedre hosting eller slank sit setup.

404-fejl – når sider tilsyneladende “forsvinder”

Hvad betyder 404-fejl i WordPress?

En 404-fejl betyder, at serveren ikke kan finde den side eller ressource, som URL’en peger på.
For brugeren ligner det bare, at siden ikke findes.

I WordPress er en 404-fejl dog ikke altid lig med, at indholdet er væk, slettet eller med vilje fjernet på et tidspunkt.
Det kan lige så godt være, at permalinks er gået i stykker, at .htaccess ikke omskriver URL’er korrekt, eller at siden har fået en ny adresse uden redirect.

Du kan have:

• 404 på enkelte sider, fordi de er slettet eller flyttet.
• 404 på alle undersider (men ikke forsiden), fordi permalinks eller rewrite-regler er knækket.

Typiske årsager til 404-fejl

Du ser typisk 404-fejl, når:

• Permalink-strukturen er ødelagt eller ændret forkert.
• .htaccess mangler eller er forkert konfigureret (på Apache).
• Nginx-konfigurationen ikke har korrekte WordPress regler.
• Sider, indlæg eller produkter er slettet eller flyttet uden 301-redirects.
• Custom post types ikke har de rigtige rewrite-indstillinger.

Sådan løser du 404-problemer i WordPress

1. Regenerér permalinks

Det første og mest ufarlige skridt:

• Gå til Indstillinger → Permanente links i WordPress.
• Tryk Gem ændringer uden at ændre selve strukturen.

Det tvinger WordPress til at genskabe sine rewrite-regler.
På Apache opdaterer det som regel også .htaccess automatisk.

2. Tjek .htaccess (på Apache)

Hvis du bruger Apache, bør du tjekke, om .htaccess faktisk indeholder standard-reglerne:

• Åbn .htaccess i roden af WordPress.
• Sammenlign med en standard WordPress .htaccess (fx fra en frisk installation).
• Ret eventuelle fejl eller opret filen helt på ny med korrekt indhold.

Husk at sikre, at filen har passende rettigheder (typisk 644) og at mappen kan læses korrekt.

3. Tjek om indholdet faktisk eksisterer

Hvis 404 kun gælder bestemte sider:

• Gå i WordPress backend og søg efter siden eller indlægget.
• Tjek om det ligger i papirkurven, som så kan gendannes.
• Se om slug/URL er blevet ændret af en anden redaktør.

Hvis URL’en er ændret, bør du opsætte en 301-redirect fra den gamle adresse til den nye.
Det kan du gøre via et SEO-plugin eller et dedikeret redirect-plugin.

Hvornår skal du ringe efter hjælp ved 404-fejl?

Få hjælp, når:

• Alt over en kam giver 404, og hverken permalinks eller .htaccess hjælper.
• Du kører Nginx og ikke har adgang til eller erfaring med serverkonfiguration.
• Du har avancerede custom post types eller multisite, hvor fejlene er mere komplicerede end “bare en side mangler”.

Her er det ofte hurtigere, at en tekniker eller udvikler kigger på det, fremfor at du gætter.

Sidder fast i maintenance mode (“briefly unavailable for scheduled maintenance…”)

Hvad betyder maintenance mode i WordPress?

Når du opdaterer WordPress, plugins eller temaer, sætter WordPress automatisk sitet i maintenance mode.
Det er en måde at sikre, at brugere ikke rammer halvopdaterede filer midt i processen.

Det sker ved, at WordPress opretter en lille fil i roden af installationen, som hedder .maintenance.
Mens den fil ligger der, viser sitet beskeden:

Briefly unavailable for scheduled maintenance. Check back in a minute.

Normalt slettes filen automatisk, når opdateringen er færdig.
Hvis noget går galt – fx timeout eller fejl i et plugin – bliver filen liggende, og sitet sidder “fast” i maintenance mode.

Typiske årsager til at sidde fast i maintenance mode

Her er de klassiske situationer:

• Timeout under opdatering, fx pga. langsom hosting.
• Opdatering af rigtig mange plugins på én gang, så processen bliver for tung.
• Afbrudt opdatering, hvor browseren lukkes midt i processen.

Sådan fjerner du maintenance mode

1. Slet .maintenance-filen

Det er så simpelt, at det næsten er komisk:

• Log ind via FTP eller filhåndtering i kontrolpanelet.
• Gå til WordPress roden (der hvor wp-config.php ligger).
• Find filen .maintenance.
• Slet den og genindlæs din hjemmeside.

I langt de fleste tilfælde er siden nu oppe igen.

2. Tjek, hvad der blev opdateret – og hvad der ikke gjorde

Når du har adgang til admin:

• Gå til Kontrolpanel → Opdateringer.
• Tjek, om nogle plugins eller temaer står som ikke opdateret eller fejlet.
• Opdater dem én ad gangen i stedet for i én stor klump.

Hvis du rammer en fejl igen under opdatering af et bestemt plugin, ved du, hvor problemet sitter.

Hvornår skal du ringe efter hjælp ved maintenance-problemer?

Det er sjældent nødvendigt, hvis det blot er .maintenance, der hænger.
Men du bør overveje hjælp, hvis:

• Sitet stadig ikke virker, selv efter filen er slettet.
• Du ser 500-fejl eller WSoD lige efter en opdatering.
• Det er kritiske plugins (fx WooCommerce), hvor du ikke tør eksperimentere.

Upload-fejl – billeder og filer, der ikke vil op

Hvad betyder upload-fejl i WordPress?

Upload-fejl viser sig typisk, når du prøver at lægge billeder eller dokumenter i mediebiblioteket.
Du kan få beskeder som “HTTP error”, “Upload failed” eller se, at upload-baren bare stopper.

Nogle gange ser filen ud til at være uploadet, men billedet vises ikke rigtigt i frontend.
Andre gange får du besked om, at filen er for stor, selvom det virker helt rimeligt.

I praksis betyder upload-fejl, at WordPress ikke kan gemme filen korrekt i wp-content/uploads eller bliver stoppet af PHP’s grænser.
Det handler typisk om filstørrelse, rettigheder eller konfiguration.

Typiske årsager til upload-fejl

De hyppigste forklaringer er:

• For lav upload_max_filesize og post_max_size i PHP, så filen er “for stor” set fra serverens side.
• For lav max_execution_time, så upload-processen timeouter.
• Forkerte rettigheder på wp-content/uploads, så WordPress ikke kan skrive til mappen.
• Understøttes filtypen ikke, eller er filnavnet fyldt med specialtegn.

Sådan løser du upload-fejl

1. Tjek maks. upload-størrelse

Gå til Medier → Tilføj ny og se beskeden om maks. upload-størrelse.
Hvis der står fx “Maksimal upload-størrelse: 2 MB”, er det ret begrænsende.

For at øge grænsen kan du – alt efter hosting – justere:

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

Det kan ske i php.ini, i en .user.ini, i .htaccess eller via hostens kontrolpanel, afhængigt af setup.

2. Tjek rettigheder på upload-mappen

Forbind via FTP og gå til wp-content/uploads.

• Tjek at mapper generelt har rettigheder omkring 755.
• Tjek at filer har rettigheder omkring 644.
• Sørg for, at ejerskab (owner/group) matcher resten af WordPress filerne.

Kan WordPress ikke skrive til mappen, får du upload-fejl – ofte uden særlig god forklaring.

3. Tjek sti og URL til uploads

I ældre opsætninger kan man have pillet ved upload-stien i indstillingerne.
Hvis stien peger forkert, vil WordPress gemme ét sted og forvente filer et andet sted.

Som tommelfingerregel er det bedst at køre med standardindstillinger, hvor uploads ligger i wp-content/uploads/år/måned.
Custom stier er kun en god idé, hvis du præcis ved, hvad du laver.

Hvornår skal du ringe efter hjælp ved upload-fejl?

Du får typisk brug for hjælp, når:

• Du ikke kan ændre PHP-indstillinger selv via kontrolpanel eller filer.
• Rettigheder og ejerskab på filer er rodet sammen med andre serverindstillinger.
• Problemerne kun rammer visse brugere/roller eller multisite-konfigurationer.

Her er hostens support første stop – og eventuelt en udvikler, hvis der er mere avancerede ting i spil.

Blandet indhold (mixed content) og SSL-fejl

Hvad betyder blandet indhold?

Blandet indhold (mixed content) opstår, når din side indlæses over HTTPS, men nogle af ressourcerne stadig leveres over HTTP.
Browseren siger i praksis: “Selve siden er krypteret, men noget af det, den indlæser, er ikke”.

For brugeren kan det vise sig som:

• Ingen hængelås, selvom du har SSL-certifikat.
• Advarsler om, at siden ikke er helt sikker.
• Blokerede billeder eller scripts.

For dig som ejer betyder det både sikkerheds- og troværdighedsproblemer – og det kan også påvirke SEO negativt.

Typiske årsager til mixed content

I praksis ser man ofte:

• Gamle http://-links i databasen, fordi siden tidligere kørte uden SSL.
• Hårdkodede URLs i temaet, hvor der står http://din-side.dk i stedet for dynamiske funktioner.
• Plugins, der genererer absolutte URL’er med http i output.
• Eksterne ressourcer, der kun er tilgængelige via HTTP.

Sådan rydder du op i blandet indhold

1. Sørg for, at WordPress kører på https

Gå til Indstillinger → Generelt og tjek:

• WordPress adresse (URL) – skal starte med https://.
• Webstedsadresse (URL) – skal også starte med https://.

Hvis én af dem stadig står med http://, retter du det til https://.
Det er grundlaget for, hvordan WordPress selv genererer links.

2. Erstat http med https i databasen

Hvis sitet har kørt længe på http://, ligger der masser af gamle links i databasen.

Du kan:

• Bruge et velafprøvet search & replace-plugin, der håndterer serialiserede data korrekt.
• Eller bruge WP-CLI, fx:

wp search-replace 'http://din-side.dk' 'https://din-side.dk' --skip-columns=guid

Tag altid backup af databasen først.
En forkert search/replace kan lave mere skade end gavn.

3. Fjern hårdkodede URLs i temaet

Åbn dit tema og kig efter steder, hvor der er hårdkodede http://-links.
Det kan være i header.php, footer.php, functions.php eller skabeloner.

I stedet for hårdkodede links bør du bruge WordPress funktioner som:

• home_url() til hjemmeside-adressen.
• get_stylesheet_directory_uri() til tema-assets.
• plugins_url() til plugin-filer.

Så følger alle links automatisk domæne og protokol.

4. Overvej et SSL-plugin – men brug det med omtanke

Plugins som Really Simple SSL kan hjælpe med at “fange” mixed content ved at omskrive output.
Det er en nem måde hurtigt at få hængelåsen tilbage.

Men langsigtet er det bedre at rydde op ved kilden: database, tema, plugins.
SSL-plugins bør ses som støttehjul, ikke den eneste løsning.

Hvornår skal du ringe efter hjælp ved mixed content?

Få hjælp, når:

• Mixed content kommer fra minificerede, obfuskerede eller komplekse tema-/plugin-filer, du ikke vil røre.
• Du er usikker på at lave search/replace direkte i databasen.
• Siden stadig ikke viser “sikker” i browseren, selvom du synes at have rettet alt.

En udvikler kan typisk hurtigt identificere de sidste rester med browserens udviklerværktøjer og serverkonfiguration.

Hvornår skal du ikke være din egen WordPress tekniker?

Det er sundt at kunne løse de klassiske fejl selv.
Men der er også situationer, hvor det er bedre at stoppe og få hjælp.

Stop selv-forsøgene, hvis:

• Du er på vej til at slette tabeller eller hele databasen “for at prøve noget”.
• Du begynder at pille i filer og kode, du ikke forstår, mens sitet er i produktion.
• Du ingen backup har, men overvejer drastiske tiltag som at reinstallere WordPress fra bunden.
• Der er tydelige tegn på hack, malware eller blacklisting, som kræver systematisk oprydning.

Sådan gør du det nemmere for en udvikler/host at hjælpe dig

Inden du kontakter nogen, så saml:

• En kort tidslinje: hvornår opstod fejlen, og hvad blev ændret lige før?
• Screenshots af fejlbeskeder og forsøgte handlinger.
• Relevante uddrag fra wp-content/debug.log eller serverens error logs.
• En liste over de ting, du allerede har prøvet.

Det gør en enorm forskel for, hvor hurtigt problemet kan løses.
Og det reducerer risikoen for, at nogen gætter sig frem på dit live-site.

FAQ – ofte stillede spørgsmål om WordPress fejl