Прощай кракозябры. Здравствуй 1.6!

[Sonya]

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

Что делать при обновлении, если база уже в utf-8?
Сразу же после обновления нужно изменить/проверить две настройки в файле config.php

Должно стоять на utf-8

Code: Select all

$config['default_encoding'] = 'utf-8';

Новый параметр, который отвечает за отправление set names перед каждым запросом должен стоять на true

Code: Select all

$config['set_names'] = true;

Больше НЕ трогаем include.php!!!

Что делать при обновлении, если база НЕ в utf-8?
Ничего не делать и не трогать, все должно работать как раньше.

[Temp_user_test]

Глупый вопрос.

Как обновить сайт 1.5.4 на 1.6?
Просто заменить все файлы? Просто нет diff'a, в следствии чего возник вопрос, нет ли изменений в структуре БД?

p.s.
Все спасибо, установил.
Не заметил текст:
"Diff Packages.
Due to the extent of the changes, there will be no diff releases for 1.6. You will need to download the full package, and transfer the whole thing up to your new website… please download the appropriate checksum package and validate your upload with that."

[Sonya]

нет ли изменений в структуре БД?

Есть.

1. Сделать резервную копию базы данных.
2. Сделать резервную копию файлов.
3. Перезаписать все файлы содержимым новой версии
4. Вызвать http://www.tvoysait.ru/install/upgrade.php и пройти все шаги для обновления базы данных
5. Проверить config.php как описано выше.

[creator32]

Добрый день.

Вроде нормально обновляется, спасибо!

Вот только новая версия с модулем Cataloger не совместима...

Как быть? Может у кого есть решение проблемы - поделитесь, пожалуйста.

Спасибо!

[dexel]

SET NAMES 'utf8' в ядре это конечно хорошо. Это - прощай крокозяблы... и совместимость со старыми модулями типа GoogleMaps(или как он там), которые пишут мимо AdoDB, прямиком в базу! Это следует просматривать хотябы в method.install.php .
Вот маленькие грабли, на которые наткнулся. Без set names 'utf8', при записи в базу кириллицы, итог - кракозяблы, хотя и текстовый файл, передаваемый в запрос был в UTF-8  . Вобщем то был файл шаблона, который загонял отдельным скриптом, мимо CMS в таблицу templates.
Короче теперь перед установкой модулей, просматривайте их на предмет прямой записи в базу (мимо дров). Будем надеяться, что разработчики модулей теперь не забудут о методе MaximumCMSVersion().

[ZYV]

Чего ты там кубаторишь? Если PHP нормально настроено, то даже те модули, которые пишут в базу не через AdoDB, а через mysql_query напрямую, но НЕ создают отдельного идентификатора подключения при помощи mysql_connect (а авторов таких модулей надо сразу расстреливать в особо извращенной форме), всё равно пользуются тем подключением, которые было открыто через AdoDB и, соответственно, в SET NAMES уже не нуждаются.

Так что только если в модуле нет mysql_connect проблема в чем-то другом.

[ilia3d]

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

Что делать при обновлении, если база уже в utf-8?
Сразу же после обновления нужно изменить/проверить две настройки в файле config.php

Должно стоять на utf-8

Code: Select all

$config['default_encoding'] = 'utf-8';

Новый параметр, который отвечает за отправление set names перед каждым запросом должен стоять на true

Code: Select all

$config['set_names'] = true;

Больше НЕ трогаем include.php!!!

Что делать при обновлении, если база НЕ в utf-8?
Ничего не делать и не трогать, все должно работать как раньше.

что я только что заметил, на всех моих инсталляциях,  параметр

Code: Select all

$config['set_names'] = true;

установлен на

Code: Select all

false

и это несмотря на заверения что

Code: Select all

#This is a mysql specific option that is generally defaulted to true.  Only
#disable this for backwards compatibility or the use of non utf-8 databases.

т.е. по-умолчанию оно как раз таки на

Code: Select all

false 

... и спасибо за пост! Полезно было знать )

[ZYV]

Ну тут всё зависит от конкретного хостинга. Если, например, он по умолчанию установил кодировку сервера UTF8 никаких SET NAMES делать клиентам не надо. Поэтому, у тебя вполне могло всё работать итак. А злостный идиот, например, оставит клиентам latin1 с шведским сравнением или, что ещё хуже, cp1251 с русским сравнением. Поэтому в данном случае без SET NAMES никак.

А по поводу умолчаний, ты извини, конечно, но у меня true. Так что скорее всего у тебя не установки, а апгрейды, не надо народ путать.

[ilia3d]

Ну тут всё зависит от конкретного хостинга. Если, например, он по умолчанию установил кодировку сервера UTF8 никаких SET NAMES делать клиентам не надо. Поэтому, у тебя вполне могло всё работать итак. А злостный идиот, например, оставит клиентам latin1 с шведским сравнением или, что ещё хуже, cp1251 с русским сравнением. Поэтому в данном случае без SET NAMES никак.

А по поводу умолчаний, ты извини, конечно, но у меня true. Так что скорее всего у тебя не установки, а апгрейды, не надо народ путать.

т.е.? я же их сам ставил, значит когда-то это были установки )

Возможно 1.6 по дефолту ставит "true", я не проверял... но получается что ранние версии ставили этот параметр в  false. Что меня собсно и удивило.

[aka_44n]

Поможите люди добрые! Если везде стоит кодировка утф-8 откуда могут расти кракозяблы!?!

[ZYV]

т.е.? я же их сам ставил, значит когда-то это были установки )

Терминология: установка --- установка с нуля, апгрейд --- обновление версии до последней.

Возможно 1.6 по дефолту ставит "true", я не проверял... но получается что ранние версии ставили этот параметр в  false. Что меня собсно и удивило.

Не возможно, а точно стоит. А ранние версии вообще такого параметра не имели. И специально сделано, что при апгрейде он ставится на false, на случай если какая-нибудь интеллектуальная элита писала utf8 в базу latin1, тогда у них хотя бы не сломается всё. А таких, как ты видишь по этому форуму пруд пруди.

Поможите люди добрые! Если везде стоит кодировка утф-8 откуда могут расти кракозяблы!?!

Ты не поверишь, НИОТКУДА. Значит где-то не стоит (c) Если ты не можешь в отдельной теме членораздельно описать настройки хостинга (Apache, PHP, mySQL), последовательность установки и т.п., то сэкономь всем время --- тебе никто не сможет помочь даже при желании, потому, что телепаты на форуме давно перевелись --- или купи программиста, или думай про себя.

[aka_44n]

to :ZYV

Спасибо за науку! Все мы когда-то начинали с чего-то...
Если задел чьи-то чувства, прошу прощения.И за то, что не умею правильно формулировать вопрос тоже!(но я действительно не знаю, где брать логи и как их показывать)
Буду работать над собой.

Проблемы с кодировкой росли с хостинга. Вылечилось настройкой .htacceess.

Простите за офтоп.

[ZYV]

Ну вот видишь, если бы ты сказал: "Что за черт, везде поставил UTF8, а смотрю фаербагом --- сайт отдаёт заголовоки cp1251 и поэтому везде кракозябры. Что делать?" ты бы через 15 минут получил ответ от меня: "AddDefaultCharset UTF-8 в .htaccess". Но нет... А ты говоришь, что везде стояло.

[aka_44n]

Если б я сразу допер, то сказал бы.Опыта очень мало еще.

[dexel]

Чего ты там кубаторишь? Если PHP нормально настроено, то даже те модули, которые пишут в базу не через AdoDB, а через mysql_query напрямую, но НЕ создают отдельного идентификатора подключения при помощи mysql_connect (а авторов таких модулей надо сразу расстреливать в особо извращенной форме), всё равно пользуются тем подключением, которые было открыто через AdoDB и, соответственно, в SET NAMES уже не нуждаются.

Так что только если в модуле нет mysql_connect проблема в чем-то другом.

Да, внатуре, коннект ведь cms обеспечивает, прогнал.