kanv1s Posted May 8, 2012 Report Share Posted May 8, 2012 Здравствуйте. Начну с предыстории. Был форум на phpbb 3.x. Решили переехать на ipb 3.2.. Собственно переехали, с помощью офф. конвертера перенесли все темы и всех пользователей т.д., вобщем все было ок. Потом хотел форум обновить до версии 3.3, но всплыла проблема с БД, а точнее с кодировкой.. Данные в таблицах и сами таблицы в utf, а кодировка соединения в latin1. В БД была сплошная абракадабра, однако форум читал все нормально.. До обновления.. После обновления, абракадабра переехала на страницы форума.. Решил поступить следующим образом: - Поправить кодировку средствами dumper'а - Установить новый 3.3* - И переконвертировать исправленную БД с 3.2 под 3.3 *Исправленную БД, подружить с действующим форумом v.3.2 никак не получалось. Все хорошо, за исключением одного момента, вместо 3500+ пользователей, стало 400+... Конвертер, после конвертации пользователей, отрапортовал следующее: The following errors occurred: 2002: No password provided 2003: No password provided 2005: No password provided 2006: No password provided 2007: No password provided 2008: No password provided 2009: No password provided ...... 3084: No password provided Можете ли что нибудь посоветовать? p/s Все манипуляции проводились на Тестовом сайте. Link to comment Share on other sites More sharing options...
_Dark_ Posted May 8, 2012 Report Share Posted May 8, 2012 Это проблема не с конвертером, раз все было на месте. Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли? Link to comment Share on other sites More sharing options...
€ mylipetsk Posted May 8, 2012 Report Share Posted May 8, 2012 а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали? Link to comment Share on other sites More sharing options...
kanv1s Posted May 8, 2012 Author Report Share Posted May 8, 2012 Это проблема не с конвертером, раз все было на месте. Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли? Пользователи не исчезли. IP Converter их "видел". Local Rows 453 Source Rows 3228 Видел, но не перенес. Стоит отметить что все остальное (темы, посты, статусы, лс (тех пользователей что перенеслись), аттачи и т.д) перенес без ошибок. Возможно тут замешан Dumper, но даже не знаю как проверить. Вообщем что имеем: 1. БД в плачевном состоянии. Которую форум (3.2) читает нормально, а после обновления до 3.3 - кракозябры 2. Исправлял кодировку по инструкции на сайте самого dumper'а __sypex.net/encoding/ 3. Проверил наличие пользователей в БД после исправления - все на месте =_= После конвертирования в 3.3 - большая часть пропала (phpmyadmin, таблица members - 16 страниц, когда было 108). Возможно какая нибудь предварительная настройка поможет конвертеру их "переварить".. а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали? И по статистике и в БД. Сообщения есть, темы есть, имя прописано как Гость-* (именно так, не маска, а именно Гость-*). Скрин сделать к сожалению не могу. Все пересчеты делал (естественно о_О). Link to comment Share on other sites More sharing options...
kanv1s Posted May 9, 2012 Author Report Share Posted May 9, 2012 Ну что ребят. Идей нет никаких? Link to comment Share on other sites More sharing options...
Nexon Posted May 10, 2012 Report Share Posted May 10, 2012 Скажи мне пожалуйста, каким <censored> IP.Convert тебе хеши паролей юзеров сконвертирует? На phpbb у тебя был один метод хеширования, а на IPB уже другой, следовательно конвертация невозможна. Сейчас у тебя только один выход и он возможен, только если ты делаешь бекапы БД. 1. Пишешь на PHP скрипт конвертации юзеров таблицы phpbb в таблицу IPB. 2. Конвертируешь. 3. Меняешь метод хеширования пароля в PHP скрипте своего форума в регистрации, логине и восстановлении пароля на тот, что у тебя был на phpbb (только ты можешь знать какой). 4. Тестишь всё это дело, если работает, то ты молодец, если же нет, то рой скрипт конвертации. Оригинальный метод шифрования в IPB: $cryptPass = md5(md5(<соль>).md5(<пароль>)); Пароль и соль: Таблица members > поле memders_pass_hash и поле memders_pass_salt Соль генерируется рандомно при регистрации юзеров и при проверке пароля юзера берется из таблицы. Link to comment Share on other sites More sharing options...
Nexon Posted May 10, 2012 Report Share Posted May 10, 2012 На счет кодировки, вы перешли с английской версии IPB 3.2 на русскую версию IPB 3.3, а у них разные кодировки. Вам достаточно заставить русский форум читать БД в формате ISO-8859-1, а не в UTF-8. Link to comment Share on other sites More sharing options...
kanv1s Posted May 10, 2012 Author Report Share Posted May 10, 2012 Так.. Вот не понимаю. Конвертация phpbb > ipb 3.2 - все гладко. А конвертация ipb 3.2 > ipb 3.3 - fail.. Уххх... умел бы я скрипты писать то наверно тут ничего не спрашивал... А переходим в русской ipb 3.2 на русскую ipb 3.3 В любом же случае нужно базу поправлять, что бы в ней кракозябр не было. Не вижу смысла пытаться заставлять форум их читать. Link to comment Share on other sites More sharing options...
Nexon Posted May 11, 2012 Report Share Posted May 11, 2012 Конвертация phpbb > ipb 3.2 - все гладко. Это ложь. Я уже писал, что это НЕВОЗМОЖНО. Link to comment Share on other sites More sharing options...
kanv1s Posted May 11, 2012 Author Report Share Posted May 11, 2012 Это ложь. Я уже писал, что это НЕВОЗМОЖНО. Вы ошибаетесь.. Стандартный конвертер перенес всех пользователей (в том числе их пароли), все темы и все сообщения. Вопрос однако не в этом. Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3... Да и черт бы с этими паролями, по почте все восстановят.. Возможно скажу глупость, если всплывают ошибки связанные с паролями, может вообще очистить соответствующие поля в БД? =_= Link to comment Share on other sites More sharing options...
_Dark_ Posted May 11, 2012 Report Share Posted May 11, 2012 Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3... Кто он? Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ? Это ложь. Я уже писал, что это НЕВОЗМОЖНО. IPS Выберите там phpBB 3.x и посмотрите, что возможно, а что нет. Respected 1 Link to comment Share on other sites More sharing options...
kanv1s Posted May 13, 2012 Author Report Share Posted May 13, 2012 Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ? Не то чтобы обновляюсь.. Именно обновится не получилось. Конвертером адаптирую БД от 3.2 к форуму 3.3. Все отлично, но с пользователями косяк :'( Link to comment Share on other sites More sharing options...
€ WinsanT Posted May 13, 2012 Report Share Posted May 13, 2012 Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД. Link to comment Share on other sites More sharing options...
kanv1s Posted May 13, 2012 Author Report Share Posted May 13, 2012 Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД. Пробовал.. Форум ошибку выдает и посылает к администратору. Link to comment Share on other sites More sharing options...
_Dark_ Posted May 13, 2012 Report Share Posted May 13, 2012 Так, давайте разберемся. У вас есть работающий IPB 3.2, все нормально, все цело. Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так? Link to comment Share on other sites More sharing options...
kanv1s Posted May 13, 2012 Author Report Share Posted May 13, 2012 Так, давайте разберемся. У вас есть работающий IPB 3.2, все нормально, все цело. Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так? Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок. После обновления до IPB 3.3, крякозябры возникают на форуме. Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно. Link to comment Share on other sites More sharing options...
_Dark_ Posted May 13, 2012 Report Share Posted May 13, 2012 Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок. После обновления до IPB 3.3, крякозябры возникают на форуме. Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно. Попробуйте написать хостеру, что не меняется кодировка соединения с MySQL и что это говорит о серьезных проблемах в настройке сервера Базы Данных. Link to comment Share on other sites More sharing options...
Respected Posted May 13, 2012 Report Share Posted May 13, 2012 Посмотри свои значения, у тебя должно быть так: Link to comment Share on other sites More sharing options...
kanv1s Posted May 14, 2012 Author Report Share Posted May 14, 2012 Вот что у меня.... мда... character_set_client latin1 character_set_connection latin1 character_set_database utf8 character_set_results latin1 character_set_server latin1 character_set_system utf8 collation_connection latin1_swedish_ci collation_database utf8_general_ci collation_server latin1_swedish_ci Значит из за этого исправленную БД не принимает?.. Пишет: Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists. This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance. Как эти значения исправить? Попробуйте написать хостеру, что не меняется кодировка соединения с MySQL и что это говорит о серьезных проблемах в настройке сервера Базы Данных. Хостинг VDS.. Предустановленное ПО: FreeBSD-8-ISPmanager Apache 2.2 MySQL 5 PHP 5 Perl (+еще много чего) Что в БД может быть не так настроено... Щаc настроим +_+ Link to comment Share on other sites More sharing options...
Doogle Posted May 14, 2012 Report Share Posted May 14, 2012 Для начала необходимо все таблицы привести в сравнение с генералом, далее уже пропускать их например через Sypex Dumper. Я использую Sypex Dumper 2.0.9. Вот пхпшечка, которую необходимо скинуть в корень нужного форума. Назовем ее php.php <?php $db = mysql_connect('localhost','myuser_mydbuser','mypassword'); if(!$db) echo "Cannot connect to the database - incorrect details"; mysql_select_db('myuser_mydbname'); $result=mysql_query('show tables'); while($tables = mysql_fetch_array($result)) { foreach ($tables as $key => $value) { mysql_query("ALTER TABLE $value COLLATE utf8_general_ci"); }} echo "The collation of your database has been successfully changed!"; ?> Надеюсь не нужно говорить про изменение myuser_mydbuser, mypassword и т.д., на свои значения. Если сравнение прошло успешно, то должна появиться надпись: The collation of your database has been successfully changed! (Операция по сравнению может занять от нескольких секунд до нескольких минут. Зависит от размера таблиц). Далее необходимо пройтись по адресу http://сайт.ru/php.php Как это будет сделано, нужно установить Sypex Dumper 2.0.9., например в папку dump на форуме. Во вкладке экспорт указать дефолтную кодировку, отметить необходимые таблицы для экспорта и собственно экспортнуть их (без сжатия). Во вкладке Импорт, выставить кодировку utf-8, выбрать коррекция кодировки и импортировать дамп. Если все сделано правильно, таблицы должны быть в правильной кодировке и отображать русские символы. P.S. Вот это просто самое важное, делайте всегда перед какими-либо сложными операциями бекап бд, над которой вы работаете. Потому, что испортить легко, а восстановить тяжело. Вполне возможно, что перекодировать не удастся, будут например знаки ????? место русских букв, тогда пиши сюда, будем разбираться дальше. Скоро создам тему на форуме с информацией по пользованию программой Sypex Dumper, возможно кому будет интересно. neqste 1 Link to comment Share on other sites More sharing options...
_Dark_ Posted May 14, 2012 Report Share Posted May 14, 2012 Так, если у вас стоит сам сервер MySQL и можете его самостоятельно настроить это лучше. Google. Там по самой первой ссылке смотрите, только вместо cp1251 подставляйте ut8_general_ci[/code]. Если не получится, то все равно смотрите в этом направлении. Link to comment Share on other sites More sharing options...
kanv1s Posted May 14, 2012 Author Report Share Posted May 14, 2012 Doogle Спасибо за совет, однако вопрос не в этом. Как исправить кодировку в самой таблицы я уже в курсе. А трабла в том что ipb 3.2 ее не читает.. То есть вот новая БД, Collation - utf8_general_ci; все содержимое таблиц так же в utf8, киррилица читается, косяков нет. Кодировку в таблице исправлял тоже через Dumper, экспортировал в latin1, импортировал в utf8 с коррекцией. Но форум ее, читать не хочет.. Что действующий, что копия на денвере.. Одно и тоже: FATAL ERROR Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists. This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance. Насколько я понял, форум настроен на работу с БД в latin1.. Как его перенастроить на БД в utf8?... Link to comment Share on other sites More sharing options...
Doogle Posted May 14, 2012 Report Share Posted May 14, 2012 Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке latin1? Link to comment Share on other sites More sharing options...
_Dark_ Posted May 14, 2012 Report Share Posted May 14, 2012 Откройте файл conf_global.php и посмотрите, что у вас там в $INFO['sql_charset'][/CODE] Link to comment Share on other sites More sharing options...
kanv1s Posted May 14, 2012 Author Report Share Posted May 14, 2012 Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке latin1? Экспортировал в latin1.. Извините ошибся при написании.. Исправил.. Откройте файл conf_global.php и посмотрите, что у вас там в $INFO['sql_charset'][/CODE] Там пусто.. $INFO['sql_charset'] = ''; Ставил там ut8_general_ci.. Менялся текст ошибки. Вместо [size=2]Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists.[/size] [size=2]This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance.[/size] Выдавал [size=2]There appears to be an error with the database.[/size] [size=2]If you are seeing this page, it means there was a problem communicating with our database. Sometimes this error is temporary and will go away when you refresh the page. Sometimes the error will need to be fixed by an administrator before the site will become accessible again. You can try to refresh the page by clicking here[/size] Link to comment Share on other sites More sharing options...
Recommended Posts