Answer: Steps to verify proper encoding and control double‑encoding
- Ensure PHP is configured for UTF‑8:
ini_set('default_charset', 'UTF-8'); or set default_charset = UTF-8 in php.ini and verify mbstring extension is enabled.
- Confirm the database connection uses UTF‑8: in Contao’s
config/databases.yml set charset: utf8mb4 and driver_options: { 1002: 'SET NAMES utf8mb4' } (PDO_MYSQL).
- Check that all tables and columns are
utf8mb4_unicode_ci (run SHOW FULL COLUMNS FROM tl_content; etc.).
- Clear Contao cache and warm up:
php vendor/bin/contao-console cache:clear and php vendor/bin/contao-console cache:warmup.
- View the rendered page source and verify
<meta charset="UTF-8"> is present; ensure no form contains an conflicting accept-charset attribute.
- Submit a test form with non‑ASCII characters (e.g., "äöü߀") and inspect the raw value stored in the database; it should match the submitted UTF‑8 bytes without extra escaping.
Confirmed facts
Contao 6 requires PHP 7.4+, expects UTF‑8 end‑to‑end, and has removed the legacy ISO‑8859‑1 fallbacks that existed in Contao 4.x. The framework now normalises input via Symfony Request and StringUtil, rejecting or replacing invalid UTF‑8 sequences instead of silently passing them.
Likely explanation
If the site previously used ISO‑8859‑1/latin1 or a mixed charset, the mismatch between PHP’s default_charset, the database connection/table collation, and the HTML meta charset can cause browsers to submit bytes that Contao reinterpreted, resulting in double‑encoding or mojibake after the upgrade.
Missing diagnostic detail
To determine whether a simple configuration fix suffices or a full charset conversion is required, please confirm:
- The Contao version you upgraded from (e.g., 4.9.x, 5.x).
- The database server’s
character_set_server and collation_server values before the upgrade.
If the prior setup was latin1, a dump‑convert‑reimport of the database is needed; otherwise, the steps above should resolve the issue.
contao