Механизм авторизации ботов (роботов поисковых систем) выполняется несколько иначе чем механизм авторизации и работы с форумом участников форума или гостей. Это сделано по той причине, что боты не могут сохранять у себя куки.
При авторизации роботов-поисковиков из таблицы ibf_session сначала удаляется прошлая сессия (если она присутствовала), далее создаётся новая с ID в формате "Названиеробота_session".
Экспериментально выяснено, что часто в результе каких-то внутренних кеширований запросов СУБД MySQL прошлая сессия не удаляется и в этот момент уже начинает исполняться запрос по вставке в новой. А т.к. в таблице ibf_session на поле ID поставлен первичный ключ (PRIMARY KEY), происходит дублирование последнего и новая сессия не вставляется.
Как это выяснено?
Закономерный вопрос. Дело в том, что мы не знаем как роботы ходят на форум, соответственно не можем видеть те ошибки что им выдаёт или не выдаёт форум. Данный факт был обнаружен вследствие установки модификации, которая отсылает на email админку все запросы, которые вызывают ошибки.
Эта модификация была задумана совсем для другого (узнавать в первую очередь об ошибках в запросах и предупреждать sql-inj нападения), но в результате её работы выяснилась эта проблема.
Чем это плохо?
Дело в том, что при такой ошибке Яндекс-робот например вместо ожидаемой им страницы вашего форума для её индексации получит страницу с ошибкой драйвера IPS. В принципе здесь ничего страшного нет.
НО. Если он будет получать такую ошибку (т.е. "такой экран", такую страницу) часто, со временем он может посчитать ваш сайт малоинформативным (закономерно, т.к. мало оригинальной информации), будет ходить к вам реже, а может и вовсе выбросить ваш сайт из индекса. Всё зависит от того, насколько часто будет происходить ситуация дублирования первичного клича.
Вы можете проверить свой форум на предмет возникания таких "ошибок". Страдают обычно хостинги, т.е. когда на сервере находится не только ваш один сайт.
[color=#048284]$DB[/color]->query("INSERT INTO ibf_sessions ({$db_str['FIELD_NAMES']}) VALUES({$db_str['FIELD_VALUES']})");
на:
[color=#048284]$DB[/color]->query("REPLACE INTO ibf_sessions ({$db_str['FIELD_NAMES']}) VALUES({$db_str['FIELD_VALUES']})");
Суть сего изменения заключается в том, что мы заменяем два запроса (удаление и вставка) на один, который внутри СУБД выполнит два, но это уже не наше дело.
Song:
Описание проблемы:
Механизм авторизации ботов (роботов поисковых систем) выполняется несколько иначе чем механизм авторизации и работы с форумом участников форума или гостей. Это сделано по той причине, что боты не могут сохранять у себя куки.
При авторизации роботов-поисковиков из таблицы ibf_session сначала удаляется прошлая сессия (если она присутствовала), далее создаётся новая с ID в формате "Названиеробота_session".
Экспериментально выяснено, что часто в результе каких-то внутренних кеширований запросов СУБД MySQL прошлая сессия не удаляется и в этот момент уже начинает исполняться запрос по вставке в новой. А т.к. в таблице ibf_session на поле ID поставлен первичный ключ (PRIMARY KEY), происходит дублирование последнего и новая сессия не вставляется.
Как это выяснено?
Закономерный вопрос. Дело в том, что мы не знаем как роботы ходят на форум, соответственно не можем видеть те ошибки что им выдаёт или не выдаёт форум. Данный факт был обнаружен вследствие установки модификации, которая отсылает на email админку все запросы, которые вызывают ошибки.
Эта модификация была задумана совсем для другого (узнавать в первую очередь об ошибках в запросах и предупреждать sql-inj нападения), но в результате её работы выяснилась эта проблема.
Чем это плохо?
Дело в том, что при такой ошибке Яндекс-робот например вместо ожидаемой им страницы вашего форума для её индексации получит страницу с ошибкой драйвера IPS. В принципе здесь ничего страшного нет.
НО. Если он будет получать такую ошибку (т.е. "такой экран", такую страницу) часто, со временем он может посчитать ваш сайт малоинформативным (закономерно, т.к. мало оригинальной информации), будет ходить к вам реже, а может и вовсе выбросить ваш сайт из индекса. Всё зависит от того, насколько часто будет происходить ситуация дублирования первичного клича.
Вы можете проверить свой форум на предмет возникания таких "ошибок". Страдают обычно хостинги, т.е. когда на сервере находится не только ваш один сайт.
Исправление:
1.x:
Найдите:
[color=green]//-------------------------------------------[/color] [color=green]// Creates a BOT session[/color] [color=green]//-------------------------------------------[/color] [b]function[/b] create_bot_session([color=#048284]$bot[/color]) { [b]global[/b] [color=#048284]$DB[/color], [color=#048284]$INFO[/color], [color=#048284]$std[/color], [color=#048284]$ibforums[/color]; [color=#048284]$db_str[/color] = [color=#048284]$DB[/color]->compile_db_insert_string( [b]array[/b]( 'id' => [color=#048284]$bot[/color].'_session', 'member_name' => [color=#048284]$ibforums[/color]->vars['sp_'.[color=#048284]$bot[/color]], 'member_id' => 0, 'member_group' => [color=#048284]$ibforums[/color]->vars['spider_group'], 'in_forum' => intval([color=#048284]$ibforums[/color]->input['f']), 'in_topic' => intval([color=#048284]$ibforums[/color]->input['t']), 'login_type' => [color=#048284]$ibforums[/color]->vars['spider_anon'], 'running_time' => [color=#048284]$this[/color]->time_now, 'location' => [color=#048284]$ibforums[/color]->input['act'].",".[color=#048284]$ibforums[/color]->input['p'].",".[color=#048284]$ibforums[/color]->input['CODE'], 'ip_address' => [color=#048284]$this[/color]->ip_address, 'browser' => [color=#048284]$this[/color]->user_agent, ) ); [color=#048284]$DB[/color]->query("INSERT INTO ibf_sessions ({$db_str['FIELD_NAMES']}) VALUES({$db_str['FIELD_VALUES']})"); }Замените:
[color=#048284]$DB[/color]->query("INSERT INTO ibf_sessions ({$db_str['FIELD_NAMES']}) VALUES({$db_str['FIELD_VALUES']})");на:
[color=#048284]$DB[/color]->query("REPLACE INTO ibf_sessions ({$db_str['FIELD_NAMES']}) VALUES({$db_str['FIELD_VALUES']})");Суть сего изменения заключается в том, что мы заменяем два запроса (удаление и вставка) на один, который внутри СУБД выполнит два, но это уже не наше дело.