Jump to content

Потерялось 80% пользователей после конвертации

kanv1s
kanv1s
in Техническая поддержка IP.Board

Featured Replies

Posted
comment_3944

Здравствуйте.

Начну с предыстории.

Был форум на 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
https://ipbmafia.ru/topic/839-poteryalos-80-polzovatelej-posle-konvertacii/
Share on other sites
comment_3950

Это проблема не с конвертером, раз все было на месте.

Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли?

comment_3959

а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали?

  • Author
comment_3960

Это проблема не с конвертером, раз все было на месте.

Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли?

Пользователи не исчезли. IP Converter их "видел".

post-4072-0-06513400-1358172952_thumb.jp

Local Rows 453

Source Rows 3228

Видел, но не перенес. Стоит отметить что все остальное (темы, посты, статусы, лс (тех пользователей что перенеслись), аттачи и т.д) перенес без ошибок. Возможно тут замешан Dumper, но даже не знаю как проверить.

Вообщем что имеем:

1. БД в плачевном состоянии. Которую форум (3.2) читает нормально, а после обновления до 3.3 - кракозябры

post-4072-0-69634000-1358172953_thumb.jp

2. Исправлял кодировку по инструкции на сайте самого dumper'а

__sypex.net/encoding/

3. Проверил наличие пользователей в БД после исправления - все на месте =_=

После конвертирования в 3.3 - большая часть пропала (phpmyadmin, таблица members - 16 страниц, когда было 108).

Возможно какая нибудь предварительная настройка поможет конвертеру их "переварить"..

а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали?

И по статистике и в БД. Сообщения есть, темы есть, имя прописано как Гость-* (именно так, не маска, а именно Гость-*). Скрин сделать к сожалению не могу. Все пересчеты делал (естественно о_О).

  • Author
comment_3988

Ну что ребят. Идей нет никаких?

comment_4001

Скажи мне пожалуйста, каким <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

post-4072-0-61484700-1358172955_thumb.jp

Соль генерируется рандомно при регистрации юзеров и при проверке пароля юзера берется из таблицы.

comment_4007

На счет кодировки, вы перешли с английской версии IPB 3.2 на русскую версию IPB 3.3, а у них разные кодировки.

Вам достаточно заставить русский форум читать БД в формате ISO-8859-1, а не в UTF-8.

  • Author
comment_4008

Так.. Вот не понимаю.

Конвертация phpbb > ipb 3.2 - все гладко.

А конвертация ipb 3.2 > ipb 3.3 - fail..

Уххх... умел бы я скрипты писать то наверно тут ничего не спрашивал...

А переходим в русской ipb 3.2 на русскую ipb 3.3

В любом же случае нужно базу поправлять, что бы в ней кракозябр не было. Не вижу смысла пытаться заставлять форум их читать.

comment_4047

Конвертация phpbb > ipb 3.2 - все гладко.

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

  • Author
comment_4052

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

Вы ошибаетесь.. Стандартный конвертер перенес всех пользователей (в том числе их пароли), все темы и все сообщения.

Вопрос однако не в этом. Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3...

Да и черт бы с этими паролями, по почте все восстановят.. Возможно скажу глупость, если всплывают ошибки связанные с паролями, может вообще очистить соответствующие поля в БД? =_=

comment_4054

Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3...

Кто он?

Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ?

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

IPS

Выберите там phpBB 3.x и посмотрите, что возможно, а что нет.

    •
    • Author
    comment_4155

    Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ?

    Не то чтобы обновляюсь.. Именно обновится не получилось. Конвертером адаптирую БД от 3.2 к форуму 3.3.

    Все отлично, но с пользователями косяк :'(

    comment_4182

    Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД.

    • Author
    comment_4195

    Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД.

    Пробовал.. Форум ошибку выдает и посылает к администратору.

    comment_4200

    Так, давайте разберемся.

    У вас есть работающий IPB 3.2, все нормально, все цело.

    Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так?

    • Author
    comment_4222

    Так, давайте разберемся.

    У вас есть работающий IPB 3.2, все нормально, все цело.

    Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так?

    Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок.

    После обновления до IPB 3.3, крякозябры возникают на форуме.

    Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно.

    comment_4225

    Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок.

    После обновления до IPB 3.3, крякозябры возникают на форуме.

    Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно.

    Попробуйте написать хостеру, что не меняется кодировка соединения с MySQL и что это говорит о серьезных проблемах в настройке сервера Базы Данных.

    comment_4231

    Посмотри свои значения, у тебя должно быть так:

    • Author
    comment_4269

    Вот что у меня.... мда...

    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 настроим +_+

    comment_4310

    Для начала необходимо все таблицы привести в сравнение с генералом, далее уже пропускать их например через 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, возможно кому будет интересно.

    •
    comment_4314

    Так, если у вас стоит сам сервер MySQL и можете его самостоятельно настроить это лучше.

    Google. Там по самой первой ссылке смотрите, только вместо 

    cp1251
    подставляйте 
    ut8_general_ci[/code]
    .
    
Если не получится, то все равно смотрите в этом направлении.
    • Author
    comment_4317

    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?...

    comment_4320

    Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке latin1?

    comment_4322

    Откройте файл conf_global.php и посмотрите, что у вас там в

    $INFO['sql_charset'][/CODE]
    • Author
    comment_4326

    Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке 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]

    Guest
    This topic is now closed to further replies.
    Go to topic listing

    Последние посетители 0

    • No registered users viewing this page.