Slik ser problemet ut
Før
INSERT INTO wp_posts (post_title) VALUES ('Blåbærsyltetøy – årets sesong på Ålesund');Etter
INSERT INTO wp_posts (post_title) VALUES ('Blåbærsyltetøy – årets sesong på Ålesund');Hvor det kommer fra
WordPress lagrer tekst som UTF-8. Mange eldre installasjoner opprettet imidlertid tabellene som latin1 eller koblet til med latin1. Så lenge skriving og lesing gjør samme feil, merker ingen noe. Etter flytting til en ny server, eksport med phpMyAdmin eller endring av tegnsettet for tilkoblingen blir plutselig hver æ, ø og å til to tegn.
DB_CHARSETiwp-config.phperlatin1eller samsvarer ikke med tabellene.- Dumpen ble eksportert som
latin1og importert somutf8mb4– eller omvendt. - Et tillegg eller et importskript konverterte allerede ødelagt tekst én gang til. Da oppstår dobbelt kodet tekst som
ø.
Rett opp eksporten
- Ta sikkerhetskopi av databasen før du endrer noe.
- Eksporter de berørte tabellene som
.sql-fil, for eksempel med phpMyAdmin ellermysqldump --default-character-set=utf8mb4. - Slipp filen i feltet ovenfor. Mojibuster retter bare de ødelagte stedene og viser deg hver endring.
- Last ned den reparerte filen og importer den med
utf8mb4i en ny testdatabase. - Sjekk nettstedet. Ser alt riktig ut, importerer du den i den ordinære databasen.
Dumpen lastes aldri opp – det er viktig, siden den som regel inneholder brukerkontoer, e-postadresser og kommentarer. Mer om det for bedrifter og personvernombud.
Pass på serialiserte data
WordPress lagrer noen innstillinger i wp_options og wp_postmeta som serialiserte PHP-verdier, for eksempel s:8:"Blåbær";. Tallet er lengden i byte. Når ø blir til ø igjen, stemmer det ikke lenger, og WordPress forkaster verdien. Reparer derfor innholdstabeller som wp_posts, wp_comments og wp_terms først. For innstillinger er wp search-replace fra WP-CLI det bedre verktøyet, fordi det oppdaterer lengdene.
Fiks årsaken i MySQL
- Bytt tabeller og tilkobling til
utf8mb4og settdefine('DB_CHARSET', 'utf8mb4');iwp-config.php. - Inneholder en
latin1-kolonne UTF-8-byte, må du ikke konvertere den direkte – da kodes den en gang til. Vanlig fremgangsmåte går via en binær type: førstMODIFY … LONGBLOB, deretterMODIFY … LONGTEXT CHARACTER SET utf8mb4. - Test hver endring på en kopi av databasen først.
Ofte stilte spørsmål
Kan jeg reparere en hel WordPress-database på én gang?
Ja, selv store SQL-dumper. Pass likevel på serialiserte data i wp_options og wp_postmeta – WP-CLI håndterer dem bedre.
Blir riktige tegn i dumpen endret?
Nei. Mojibuster retter bare sekvenser som er tydelig ødelagt. Riktig tekst blir som den er.
Hva er forskjellen på utf8 og utf8mb4?
I MySQL lagrer utf8 bare tegn på opptil tre byte, så emojier går tapt. utf8mb4 er ekte UTF-8 og det riktige valget for WordPress.
Fungerer dette også for andre systemer enn WordPress?
Ja. Joomla, Drupal, Magento eller ditt eget program på MySQL eller MariaDB har samme problem og samme løsning.