Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Character-Encoding Errors Appear After a MySQL Migration

Text such as Ã© instead of é usually means UTF-8 bytes were decoded or re-encoded using the wrong character set. Changing the WordPress display charset may hide one symptom while corrupting new writes.

Preserve the migrated and original databases. Determine the actual stored bytes before running replacements.

Classify the damage

Record examples from posts, titles, options, filenames and plugin tables. Determine whether all text, only old rows or only newly saved content is affected.

Patterns:
correct database, wrong page headers
wrong import connection charset
latin1 declaration around UTF-8 bytes
double-encoded UTF-8
unsupported emoji/supplementary characters

Use non-sensitive sample text and retain exact bytes/hex where possible.

Compare source and destination

Inspect table/column charset and collation on both servers. Check dump headers for SET NAMES, client character set and collation statements.

SHOW CREATE TABLE wp_posts;
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

Run read-only queries with the actual prefix. Server defaults do not automatically describe every existing column.

Inspect stored bytes

Compare a known string using HEX() in source and destination. If bytes match but display differs, the connection or page decoding is wrong. If bytes differ, the import transformed data.

Do not copy customer content into public tools. Work on a staging copy with exact row IDs.

A visual browser comparison alone cannot distinguish single from double encoding.

Check WordPress database constants

Review DB_CHARSET and DB_COLLATE in wp-config.php. Modern WordPress commonly uses utf8mb4 with an empty collation unless the host requires otherwise.

Do not change these constants casually on an existing database; they influence connections and schema operations but do not safely convert every stored value.

Check HTTP response <meta charset> and headers as a separate display layer.

Re-import with explicit settings

When the destination can be rebuilt, the cleanest repair is often a fresh export/import that preserves bytes and declares the correct connection charset.

Test on a separate database and compare row counts and hex samples before switching WordPress. Keep new production writes out of the migration window or merge them explicitly.

Do not repeatedly import into the same partially transformed tables.

Repair double encoding carefully

Double-encoded data may require a reversible conversion, but the correct expression depends on the current bytes and intended text. Test specific rows in staging and preserve originals.

Avoid global search-replace of visible sequences like Ã; legitimate text and different corruption patterns can be damaged.

Build a bounded list of affected columns/rows and validate accents, Catalan middle dot, Spanish punctuation, emoji and non-Latin examples.

Convert schema when required

Use application/DBA-supported conversion to utf8mb4, checking index lengths and MySQL version. Large ALTER TABLE operations can lock writes and need free disk.

Back up and schedule maintenance. Do not convert authoritative production tables without estimating duration and rollback.

Ensure plugins/custom tables are included deliberately, not just WordPress core.

Review URLs, slugs and filenames

Encoding damage can change percent-encoded URLs and post slugs even when visible titles are repaired. Compare canonical URLs, menu links, attachment filenames and redirects with the original site.

Do not regenerate every slug automatically; that breaks indexed URLs and inbound links. Repair a bounded mapping, add intentional redirects and keep identifiers stable where possible. For filenames, distinguish filesystem encoding from database attachment metadata before renaming anything.

Verify old and new content

Test public display, editor load/save, search, URLs/slugs, email and database exports. Saving a correctly displayed old row should not corrupt it again.

Compare source/destination samples and run a fresh backup/restore rehearsal. Recurring migration care should record charset at export, connection and storage; encoding integrity is proven by bytes and round-trip writes, not by one page looking acceptable.