MODx. Вопросительные знаки вместо текста. Решение проблемы

Тема избитая, но, увы, и на старуху бывает проруха.

Недавно пришлось потратить "пять минут", чтобы перенести старый сайт старого клиента с хостинга timeweb.com на хостинг reg.ru.

При экспорте базы выбрана правильная кодировка utf-8, даже вручную при редактировании дампа исправлены все вхождения cp1251 на utf8.

Но после импорта на новом хостинге все отображается отлично только до попытки отредактировать или добавить ресурс. Малейшее редактирование приводит к появлению вопросительных знаков в контенте.

Попытки менять параметры совместимости при экспорте, править кодировку php-файлов движка (ANSI на utf8), изменять кодировку дампа перед заливкой, перейти вообще везде на windows cp1251 не увенчались успехом.

Как оказалось, "ларчик просто открывался". Выяснить это помогла страничка Отчеты -> Системная информация движка. Оказалось, что при создании базы на reg.ru была выбрана кодировка по умолчанию, и она, разумеется, отличалась от utf8. При этом данная особенность базы не отображается ни в ее свойствах в phpMyAdmin ни в панели RISP Manager Reg.ru.

Возможно, есть более простое и элегантное решение, но я создал в ISP Manager новую базу, задав ей правильную кодировку, залил все тот же многострадальный правильный дамп, благо в нем всего 2,3 Мб, и перешел сюда, чтобы задокументировать полученный опыт.

Если не помогло

Личный опыт заставил написать продолжение. Обновлял движок ModX Evo для старого сайта, который когда-то писался еще на версии 0.9 и, естественно, был на windows cp1251.

После различных манипуляций вылезала кривая кодировка то в админке, то в комментариях Jot, не работал модуль Extras.

Разумеется, в админке была выставлена нужная кодировка.

Она же была прописана в .htaccess, и она же выставлена в настройках хостинга.

php_value default_charset utf-8

Помимо выкачивания и конвертации базы и прочих манипуляций нашел заключительные шаги на modx.ru:

1. (У меня всё пришло в порядок без этого действия) открываем файл manager\includes\extenders\dbapi.mysql.class.inc.php и в function connect после создания соединения вставляем строку

   mysql_query("SET CHARACTER SET 'utf8';", $this->conn);
   

2. Открываем файл manager\includes\lang\russian-UTF8.inc.php в блокноте и сохраняем в utf8 или открываем в Edit Pad Pro 7 (Notepad ++ или другой подобной софтине) и преобразуем его в utf8.
3. Открываем файл manager\includes\config.inc.php и выставляем переменную $database_connection_charset = 'utf8'.
4. Еще раз проверяем, что в админке выставлены настройки как на скрине выше: язык системы управления Russia-UTF8, кодировка Unicode (UTF-8)-utf-8.

Заключительный финт из того же источника, «гвоздь программы»:

Правим файл manager/includes/lang/russian.inc.php:

php_value default_charset utf-8

заменяем на

$contents = mb_convert_encoding($contents, 'UTF-8', 'UTF-8');

Также строку

$modx_manager_charset = 'cp1251';

правим на

$modx_manager_charset = 'utf8';

После всех этих манипуляций кодировка точно должна прийти в полный порядок. Успехов!

Обновлено 25.11.2020

Следующая статья: Типы ремаркетинга в контекстно-медийной сети Google https://capweb.ru/tipy-remarketinga-v-kms-google.html

Предыдущая статья: Как поставить галку в MODx, чтобы не отображать ресурс в списке https://capweb.ru/bool-tv-modx-revolution.html