Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
По поводу сопоставления кодировки — я искренне не понял в чем проблема, но переменные $database_connection_method и $charset просто не импортируются в этот фрагмент, следующей строкой мы повторяем запрос так, как он должен был бы произойти.
Возможно это проблема моей конфигурации.
Возможно это проблема моей конфигурации.
зато исправили наконец проблемы с кодировкой БД.
извиняюсь, не исправили. Но старый хак: modxcms.com/forums/index.php/topic,4422.msg32209.html#msg32209 по-прежнему поможет поставить modx на любой хостинг с любой mysql.
Кодировку БД таки исправили, создается честный utf8. Пытались исправить сопоставление коннектора… не получилось :)
Патч по ссылке избыточен, достаточно сделать то, что я предложил в топике, проверено.
Патч по ссылке избыточен, достаточно сделать то, что я предложил в топике, проверено.
я пробовал дистрибутив ставить на HostGator и HostFabrica — проблема была. А после патча на форуме MODx спокойно встал на HostGator, HostFabrica и Хостинг-Центр, что означает, что избыточность себя оправдала. Ваш вариант, приведенный в топике, я не пробовал — на радостях сразу побежал скачивать, даже не дочитав топик. Но при внимательном рассмотрении этого варианта мне стало казаться, что он просто исключает выбор метода и сопоставления. Ведь при установке можно выбрать, как применять кодировку — SET NAMES или SET CHARACTER SET, и выбрать кодировку. Этот выбор как раз в приведенной вами строчке и обрабатывается. Какой смысл прописывать значение переменных вместо самих переменных, если суть от этого не меняется? Это первый аргумент в пользу «старого хака».
Второй аргумент такой: я потратил полдня, 6 часов, на проверку работоспособности дистрибутива на используемых мной хостингах. И только «старый хак» гарантировал мне полноценную работу из коробки и далее везде. Я добавил «старый хак» с utf8_unicode_ci, в установщике добавил крупным жирным шрифтом «Не забудь выставить сопоставление utf8_unicode_ci для базы, в которую станешь ставить», заботливо упаковал результат в архив, подписал его «production», и положил на видное место. В будущем я буду тратить 5 минут вместо 6 часов и буду уверен, что не придется вылавливать мелкий, но досадный сбой. И оно встанет — везде, на любом хостинге, какой еще может появиться, гарантированно.
Второй аргумент такой: я потратил полдня, 6 часов, на проверку работоспособности дистрибутива на используемых мной хостингах. И только «старый хак» гарантировал мне полноценную работу из коробки и далее везде. Я добавил «старый хак» с utf8_unicode_ci, в установщике добавил крупным жирным шрифтом «Не забудь выставить сопоставление utf8_unicode_ci для базы, в которую станешь ставить», заботливо упаковал результат в архив, подписал его «production», и положил на видное место. В будущем я буду тратить 5 минут вместо 6 часов и буду уверен, что не придется вылавливать мелкий, но досадный сбой. И оно встанет — везде, на любом хостинге, какой еще может появиться, гарантированно.
Смысл прописывать переменные прямо в строке очень простой, я покажу.
Разработчики честно попытались исправить ситуацию с кодировкой, для этого они ввели новую процедуру:
Однако, на этом участке кода, переменные database_connection_method и charset не импортированы, т.е. не имеют того значения, которое предписано в include/config.inc.php (SET CHARACTER SET utf8).
Следовательно, исполнение этой процедуры совершенно ничего не меняет, в итоге мы исполняем пустой запрос:
В моем варианте мы оставляем эту ошибку на совести разработчиков и повторяем ту же самую процедуру, но с предварительно сформированной строкой запроса:
Ваш вариант по ссылке делает абсолютно то же самое в пункте 2 и 3, но с некоторым избытком. Я поясню.
В моей конфигурации, для того что-бы исправить сопоставление, достаточно в файле dbapi.mysql.class.inc.php изменить или NAMES или CHARACTER SET но не SESSION. Ваш вариант делает все эти три операции сразу в двух файлах, хотя достаточно только одной из первых двух.
Что касается создания БД (первый пункт вашей ссылки), в моем случае, это оказалось лишним. БД уже создавалась с приемлемыми параметрами.
Но, нам не очем спорить ;) у каждого своя конфигурация, и по хорошему, чем накладывать грубые хаки, лучше было бы исправить код так, как это подразумевалось разработчиками.
Разработчики честно попытались исправить ситуацию с кодировкой, для этого они ввели новую процедуру:
@mysql_query("{$database_connection_method} {$charset}", $this->conn);Однако, на этом участке кода, переменные database_connection_method и charset не импортированы, т.е. не имеют того значения, которое предписано в include/config.inc.php (SET CHARACTER SET utf8).
Следовательно, исполнение этой процедуры совершенно ничего не меняет, в итоге мы исполняем пустой запрос:
mysql_query(" ", $this->conn);В моем варианте мы оставляем эту ошибку на совести разработчиков и повторяем ту же самую процедуру, но с предварительно сформированной строкой запроса:
mysql_query("SET CHARACTER SET 'utf8';", $this->conn);Ваш вариант по ссылке делает абсолютно то же самое в пункте 2 и 3, но с некоторым избытком. Я поясню.
В моей конфигурации, для того что-бы исправить сопоставление, достаточно в файле dbapi.mysql.class.inc.php изменить или NAMES или CHARACTER SET но не SESSION. Ваш вариант делает все эти три операции сразу в двух файлах, хотя достаточно только одной из первых двух.
Что касается создания БД (первый пункт вашей ссылки), в моем случае, это оказалось лишним. БД уже создавалась с приемлемыми параметрами.
Но, нам не очем спорить ;) у каждого своя конфигурация, и по хорошему, чем накладывать грубые хаки, лучше было бы исправить код так, как это подразумевалось разработчиками.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
0.9.6.2