Du opprettet en database i phpMyAdmin, installerte WordPress, og en uke senere oppdaget du uleselig tekst i stedet for lesbare tegn i tabellene dine. Du åpner innstillingene og ser latin1_swedish_ci. Alle som jobber med Laragon på Windows, støter før eller siden på denne overraskelsen.

Problemet er at MySQL-bygget som Laragon installerer ut av esken, arver et eldgammelt standardvalg: latin1 som tegnsett og latin1_swedish_ci som sorteringsregel. For norsk er dette en katastrofe: spesialtegn som æ, ø og å blir skrevet som spørsmålstegn eller krøll, strengsortering feiler, og utvidelser krasjer med feilmeldinger.

Nedenfor finner du to endringer i én fil som løser dette problemet permanent. Det tar tre minutter. Fungerer på Laragon 6, 5 og til og med den eldgamle versjon 4.

💡 Rask oversikt:

• Åpne my.ini via Laragon-menyen og legg til to linjer i [mysqld]-seksjonen
• Velg utf8mb4_unicode_ci som det optimale valget for WordPress i 2026 (og vi forklarer hvorfor)
• Lagre filen, start MySQL på nytt, og bekreft resultatet i phpMyAdmin
• Bonus: hvordan du endrer tegnsettet til en eksisterende database uten å miste data

Hvorfor standard tegnsett i det hele tatt betyr noe

MySQL opererer med et arvesystem på flere nivåer: server → database → tabell → kolonne. Hvis latin1_swedish_ci er satt på servernivå, vil hver ny database arve dette med mindre noe annet spesifiseres under opprettelsen.

For WordPress er dette kritisk fordi:

• Kjernen, temaer og de fleste utvidelser lagrer innhold i utf8mb4
• Når en database opprettes automatisk via wp-config.php, overstyrer WordPress IKKE serverens standardinnstilling
• Uoverensstemmelse i tegnsett mellom server og tabeller gir "uklare" feil: ??? i administrasjonspanelet, ødelagte tegn i JSON REST API, krasj under eksport

Ifølge data fra W3Techs driver WordPress 43,5% av alle nettsteder på internett, og CMS-et har selv krevd utf8mb4 siden versjon 4.2 for full emoji-støtte. Laragon er en av de mest populære lokale serverne for Windows, men MySQL-bygget leveres med et konservativt standardvalg for bakoverkompatibilitet. Derav konflikten.

Steg 1: Åpne my.ini via Laragon-menyen

Den enkleste måten å få tilgang til MySQL-konfigurasjonsfilen på er via Laragons innebygde meny:

• Høyreklikk på Laragon-ikonet i systemstatusfeltet
• Velg Meny → MySQL → my.ini

Notisblokk (eller ditt standard redigeringsprogram) åpnes med hele MySQL-konfigurasjonen. Filen er delt inn i seksjoner med hakeparenteser: [client], [mysqld] og [mysqldump]. Vi er interessert i [mysqld] (seksjonen for innstillinger for MySQL-demonen).

Hvis menyen av en eller annen grunn ikke åpner filen, finn den manuelt: C:\laragon\bin\mysql\<version>\my.ini. I Laragon 6-bygg kan banen være C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, avhengig av den installerte versjonen.

Steg 2: Legg til to linjer i [mysqld]-seksjonen

Bla til [mysqld]-seksjonen og legg til følgende to linjer på slutten (før neste seksjon, hvis det finnes en):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Hva som skjer her:

• character_set_server = utf8mb4 ber serveren om å bruke UTF-8 Multilingual Version 4-koding som standard, noe som støtter ALLE Unicode-tegn, inkludert emoji, kyrilliske tegn og hieroglyfer
• collation_server = utf8mb4_unicode_ci setter regelen for strengsammenligning: _unicode_ betyr "i henhold til Unicode-standarden", _ci betyr skille mellom store og små bokstaver er slått av

Du må legge disse linjene spesifikt til [mysqld], ikke til [client] eller [mysqldump]. Å bruke feil seksjon er den vanligste årsaken til at "ingenting endret seg".

Hele seksjonen etter redigering bør se omtrent slik ut:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Steg 3: Lagre filen og start MySQL på nytt

Lagre my.ini (Ctrl+S) og start MySQL på nytt. I Laragon gjøres dette via den samme menyen:

• Høyreklikk på Laragon-ikonet i systemstatusfeltet
• Meny → MySQL → Stopp
• Vent 3-5 sekunder
• Meny → MySQL → Start

Alternativt kan du klikke Meny → Start på nytt, så stopper og starter Laragon alle tjenester samtidig.

Etter omstart vil nye databaser bli opprettet med utf8mb4_unicode_ci som standard. Eksisterende databaser endres IKKE automatisk. Les avsnittet «Ofte stilte spørsmål» nedenfor for å lære hvordan du konverterer en eksisterende database.

Steg 4: Bekreft resultatet i phpMyAdmin

Åpne phpMyAdmin via Laragon-menyen (Meny → MySQL → phpMyAdmin) og opprett en testdatabase:

• Klikk «Opprett database»
• Skriv inn et valgfritt navn
• Se på nedtrekkslisten «Sorteringsregel»: den skal nå ha utf8mb4_unicode_ci som standard

Hvis nedtrekkslisten fortsatt viser latin1_swedish_ci, sjekk at linjene character_set_server og collation_server ble lagt til i [mysqld]-seksjonen (ikke [client]), og at det ikke er ekstra mellomrom mellom parameternavnet og =-tegnet.

Rask verifisering via SQL-spørring (kjør i phpMyAdmin under SQL-fanen):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Begge variablene skal returnere henholdsvis utf8mb4 og utf8mb4_unicode_ci.

Hvilken koding du bør velge: sammenligning av alternativer

MySQL-koding har samlet mange myter, så la oss bryte ned tre aktuelle alternativer og ett utdatert:

Hvorfor vi anbefaler utf8mb4_unicode_ci for lokal utvikling i Laragon:

• Laragon leveres med ulike MySQL-versjoner (fra 5.7 til 8.0+), og utf8mb4_0900_ai_ci dukket først opp i MySQL 8.0 og er fraværende i MariaDB, som ofte følger med i alternative bygg
• utf8mb4_unicode_ci fungerer overalt fra og med MySQL 5.5.3 (2010)
• Forskjellen i sorteringskvalitet mellom unicode_ci og 0900_ai_ci er ubetydelig for et typisk WordPress-nettsted
• Delte hostingplaner bruker ofte MySQL 5.7. Hvis du utvikler lokalt med 0900_ai_ci, men det mangler i produksjon, får du en feil under migrering

Hvis du vet med sikkerhet at produksjonsserveren din kjører MySQL 8.0+ og din lokale Laragon bruker MySQL 8.0, kan du gå for utf8mb4_0900_ai_ci. Dette er den moderne standarden anbefalt av Oracle, med bedre støtte for flerspråklig sortering.

Hva med utf8_general_ci? Det var relevant for omtrent ti år siden, da utf8mb4 ennå ikke var bredt støttet. I dag har det to fatale svakheter: det kan ikke lagre emoji (WordPress bruker dem aktivt i administrasjonspanelet), og det sorterer utvidede tegn feil. Det er ingen grunn til å bruke det i 2026.

Video: hvordan endre MySQL-databasekoding via phpMyAdmin

Tekstinstruksjoner er flotte, men noen ganger er det lettere å se det én gang. Denne 4-minutters videoen viser hele prosessen med å endre kodingen til en eksisterende database via phpMyAdmin-grensesnittet, fra valg av tabeller til endelig verifisering:

⁉️🤔 Ofte stilte spørsmål

Jeg har allerede en database med latin1_swedish_ci. Hvordan endrer jeg kodingen på den?

Den tryggeste måten er via phpMyAdmin. Velg databasen til venstre, gå til fanen «Operasjoner», velg utf8mb4_unicode_ci i blokken «Sorteringsregel», og klikk «Utfør». phpMyAdmin vil generere ALTER-spørringer for hver tabell. Før denne operasjonen må du sørge for å opprette en sikkerhetskopi: «Eksport»-fane → SQL-format → «Utfør».

Jeg endret my.ini, startet MySQL på nytt, men phpMyAdmin viser fortsatt latin1_swedish_ci. Hva er galt?

Tre vanligste årsaker: (1) linjene ble lagt til i [client] i stedet for [mysqld]. Sjekk hvilken seksjon med hakeparentes de står under. (2) MySQL ble ikke startet på nytt. Åpne Windows Oppgavebehandling og bekreft at mysqld.exe-prosessen forsvant og dukket opp igjen. (3) Det finnes flere [mysqld]-seksjoner i my.ini. Dette skjer noen ganger etter flere Laragon-oppdateringer. Behold bare én.

Hva er best for WordPress: utf8mb4_unicode_ci eller utf8mb4_general_ci?

For WordPress er forskjellen minimal. utf8mb4_unicode_ci sorterer flerspråklig innhold mer nøyaktig (for eksempel tysk «ß» = «ss»), mens utf8mb4_general_ci er litt raskere på store volumer, men forskjellen er i millisekunder. Velg unicode_ci og ikke tenk mer på det.

Kan jeg bare spesifisere kodingen i wp-config.php?

define('DB_CHARSET', 'utf8mb4') og define('DB_COLLATE', 'utf8mb4_unicode_ci') i wp-config.php påvirker KUN tabellene som WordPress selv oppretter under installasjonen. Serverens standard forblir uendret, og enhver database som opprettes manuelt via phpMyAdmin, vil få latin1_swedish_ci. Derfor er det fortsatt nødvendig å redigere my.ini.

Etter endring av koding ble noe tekst på nettstedet til spørsmålstegn. Er dette reversibelt?

Ja, men du må gå forsiktig frem. Spørsmålstegn oppstår når data ble skrevet i latin1, men leses som utf8. Løsningen: eksporter databasen med flagget --default-character-set=latin1, og importer deretter med --default-character-set=utf8mb4. Den nøyaktige kommandoen avhenger av din MySQL-versjon, så se den offisielle dokumentasjonen.

Oppsummering: hva du skal legge til i my.ini akkurat nå

Hvis du bruker Laragon til lokal WordPress-utvikling, vil de to linjene nedenfor løse kodingsproblemet en gang for alle:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Dette alternativet fungerer på alle MySQL-versjoner fra 5.5 til 8.4 og på alle aktuelle MariaDB-bygg. Det lagrer norske tegn, emoji korrekt, og skaper ingen overraskelser når databasen migreres fra lokal til produksjon, uavhengig av hvilken hosting som driver produksjonsserveren din.

Har du spørsmål om en spesifikk Laragon-versjon eller ikke-standard konfigurasjon? Sjekk ut tråden på Laragon-forumet, der utviklere diskuterer nyanser i kodingskonfigurasjon, inkludert Docker-bygg og egendefinerte porter. Og hvis denne artikkelen sparte deg for en kveld, del den med kolleger som også sliter med latin1_swedish_ci.