Косяки IBF. Версии форума 1.2++ (до 2.x)

[Song]

Я когда форум делаю часто натыкаюсь на то, что разработчики по элементарной забывчивости забыли строчку добавить или ещё что-то. Возможно в других версиях это пофиксено, но у меня в базовой (1.2) таких случаев много.

Обладателям других версий посмотрите у себя возможно, это и у вас есть

Просьба к другим: кто чего найдёт пишите сюда.

 

 

Добавлено в [mergetime]1099024337[/mergetime]

Косяк № раз.

Файл calendar.php

        $DB->query("SELECT * FROM ibf_calendar_events WHERE event_repeat=1
           AND ( repeat_unit IN ('w','m') OR (repeat_unit='y' AND month={$this->chosen_month}) )
           ");
        	 
       while ( $rec = $DB->fetch_row() )
       {
      	 $recurring[] = $rec;
       }

Здесь не учитывается что периодические события

1) могут быть частные по юзеру

2) могут быть ограниченные по группам

 

и в результате вы создаёте для себя лично напоминание ежемесячное например, а видят его все. ( http://forum.sources.ru/index.php?showtopic=70311 )

Решение.

Добавить

if ( $rec['priv_event'] == 1 )
      	 {
         if ($ibforums->member['id'] != $rec['userid'])
         {
        	 continue;
         }
      	 }

if ( $rec['read_perms'] != '*' )
      	 {
         if ( !preg_match( "/(^|,)".$ibforums->member['mgroup']."(,|$)/", $rec['read_perms'] ) )
         {
        	 continue;
         }
      	 }

 

внутрь цикла перед

$recurring[] = $rec;

[Song]

Косяк №2

 

Отсутствие важнейших индексов

 

Таблица ibf_posts. Поля:

ip_address - когда ваш модератор будет искать сообщения какого-то пользователя по ИП адресу, ваш форум будет лежать и ждать пока закончится поиск

 

Таблица ibf_sessions. Поля

running_time

member_id

По ним производится выборка сессии.

 

Таблица ibf_members. Поле

ip_address.

 

Также ip_address во многих других таблицах.

[ImUgh]

Косяк №3

 

В русской модиф 1.3 не работает повторный запрос кода авторизации при смене email в профиле.

Просто напросто разработчики забыли в этой части кода всего одну строчку - команду send_mail()

То же самое в версии 1.2 (точные параметры версии не помню), так что, возможно, это "глобальный" косяк.

 

Лекарство.

идем в sources/Register.php

ищем функцию revalidate_two()

там ищем "пункт"

else if ( $val['email_chg'] == 1 )

и в конце этого if-a ВМЕСТО

$this->email->to      = $email_one;

 

пишем

                        $this->email->to      = $member['email'];
                        $this->email->send_mail();

[Song]

ImUgh

пасиб. А откуда вообще взялась эта переменная $email_one? я даже в ф-ии её не нашёл.

 

Косяк №4.

 

Идём в Login.php, смотрим ф-ию:

    function markforum()

 

в ней запрос

        $DB->query("SELECT id, name, subwrap, parent_id FROM ibf_forums WHERE id=".$ibforums->input['f']);

Не знаю для чего разработчики перечислили столько параметров в запросе, потому как реально нужен только parent_id

По всему видно, что просто откуда-то скопировали (лень было набирать) и забыли убрать лишнее.

Ещё где-то подобное видел.

[Song]

Косяк №5.

Разработчики форума версии 1.3 для удаления юзера из админки выделили удаление в отдельную функцию, называется которая remove_member() из файл ad_massive.php,

в которой они забыли про добрую часть запросов по удалению, что привело к тому, что после удаления юзера из админки, он удаляется только из таблицы ibf_members и новый зарегистрировавшийся юзер, получив его id, обламывается зарегистрироваться в других таблицей с выдачей ошибки:

mySQL query error: INSERT INTO y_member_extra (id) VALUES (xxxxx) ** (см. ниже)

 

mySQL error: Duplicate entry 'xxxxx' for key 1

mySQL error code:

 

Решением данного глюка является добавление всех оставшихся запросов в эту функцию.

Добавьте туда после того бедненького одинокого запроса:

$DB->query("DELETE from ibf_members WHERE id='".$IN['mid']."'");

остальные:

// Convert their posts and topics into guest postings..

$DB->query("UPDATE ibf_posts SET author_id='0' WHERE author_id='".$IN['mid']."'");
 
$DB->query("UPDATE ibf_topics SET starter_id='0' WHERE starter_id='".$IN['mid']."'");

// Delete member...
 
$DB->query("DELETE from ibf_pfields_content WHERE member_id='".$IN['mid']."'");
$DB->query("DELETE from ibf_member_extra WHERE id='".$IN['mid']."'");
 
// Delete member messages...
 
$DB->query("DELETE from ibf_messages WHERE member_id='".$IN['mid']."'");
$DB->query("DELETE from ibf_contacts WHERE member_id='".$IN['mid']."' or contact_id='".$IN['mid']."'");
 
// Delete member subscriptions.
 
$DB->query("DELETE from ibf_tracker WHERE member_id='".$IN['mid']."'");
$DB->query("DELETE from ibf_forum_tracker WHERE member_id='".$IN['mid']."'");
$DB->query("DELETE from ibf_warn_logs WHERE wlog_mid='".$IN['mid']."'");
 
// Delete from validating..
 
$DB->query("DELETE FROM ibf_validating WHERE member_id='".$IN['mid']."'");

// Set the stats DB straight.
 
$DB->query("SELECT id, name FROM ibf_members WHERE mgroup <> '".$INFO['auth_group']."' ORDER BY joined DESC LIMIT 0,1");
 
$memb = $DB->fetch_row();
 
$DB->query("SELECT COUNT(id) as members from ibf_members WHERE mgroup <> '".$INFO['auth_group']."'");
$r = $DB->fetch_row();
// Remove "guest" account...
$r['members']--;
$r['members'] < 1 ? 0 : $r['members'];

$DB->query("UPDATE ibf_stats SET ".
           "MEM_COUNT={$r['members']}, ".
            "LAST_MEM_NAME='" . $memb['name'] . "', ".
           "LAST_MEM_ID='"   . $memb['id']   . "'");

 

В данное время (когда глюк уже имеет место быть) нужно удалаить запись с id=2 из таблицы ibf_member_extra вручную:

DELETE FROM ibf_member_extra WHERE id=xxxxx

где xxxxx - это id нового пользователя, вызвавшего ошибку (указано в скобках **)

[Song]

Косяк №6 с дополнительными полями при регистрации

 

Как мы знаем в создании доп. полей можно указать, чтобы это поле было обязательным (freq=1), включалось (fshowreg=1) в форму регистрации.

Имеет место быть такой косяк: ставим, что поле обязательное, но, чтобы не включалось в регистрационное форму.

И получаем: на экране регистрации поле не включается, поэтому юзер его заполнить не может.

Однако при проверке оно проверяется (т.к. оно freq=1) и форум пишет "Не все поля заполнены, повторите попытку).

 

Исправление. Файл Register.php:

Находим

$custom_fields = array();

$DB->query("SELECT * FROM ibf_pfields_data");

и меняем на

	$custom_fields = array();
$DB->query("SELECT * FROM ibf_pfields_data WHERE fshowreg=1");

[Song]

Косяк №7 при разрешении постов из премодерации.

 

При разрешении поста из премодерации, как мы знаем, пост участника становится видным всем участниками. Кроме того, если в данном разделе включен счётчик сообщений то он наращивается.

При этом, если группа у участника, чей пост наращивается, имеет g_promotion, т.е. группу, на которую происходит переключения после определённого поста, и этот определённый пост - это как раз тот, после которого производится переключением, имеет место глюк со следующим после этого юзера юзером. У него группа поменяется на такую же, хотя он вовсе может этого не заслуживать.

Кусок кода:

    $loopy_loo = $DB->query("SELECT id, mgroup, posts, disable_group FROM ibf_members

        WHERE id IN ($mstring)");

   

    while ( $member = $DB->fetch_row($loopy_loo) )

    {

 

    //-----------------------------------

    // Are we auto_promoting?

    //-----------------------------------

   

    if ( $groups[ $member['mgroup'] ]['g_promotion'] != '-1&-1' )

    {

      list($gid, $gposts) = explode( '&', $groups[ $member['mgroup'] ]['g_promotion'] );

     

      if ( $gid > 0 and $gposts > 0 )

      {

      if ( $member['posts'] + 1 >= $gposts )

      {

     

$mgroup = "mgroup='$gid', "; // <--- Назначается группа на которую переключаем

       

        if ( USE_MODULES == 1 )

        {

        $this->modules->register_class(&$class);

        $this->modules->on_group_change($ibforums->member['id'], $gid);

        }

      }

      }

    }

// для последующего после юзера после переключения предыдущего переменная $mgroup сброшена не будет и он и все остальные также будут переведены в "крутую" группу

   

    $newbie = $DB->query("UPDATE ibf_members SET ".$mgroup."posts=posts+1 WHERE id={$member['id']}");

 

Решение: внутрь цикла после

    while ( $member = $DB->fetch_row($loopy_loo) )

    {

вставляем очистку переменной:

				
			$loopy_loo = $DB->query("SELECT id, mgroup, posts, disable_group FROM ibf_members 
						 WHERE id IN ($mstring)");

			while ( $member = $DB->fetch_row($loopy_loo) )
			{
				$mgroup = "";

				//-----------------------------------
				// Are we auto_promoting?
				//-----------------------------------

[Song]

Косяк №8 при отображении администрации форума.

Файл misc/stat.php

Запрос:

//--------------------------------------------

    // Do we have any moderators?.

    //--------------------------------------------

   

    $DB->query("SELECT m.id, m.name, m.email, m.hide_email, m.location, m.aim_name, m.icq_number,

                        f.id as forum_id, f.read_perms, f.name as forum_name, c.state

                FROM ibf_members m, ibf_categories c

                  LEFT JOIN ibf_moderators mod ON((m.id=mod.member_id or (mod.is_group=1 and mod.group_id=m.mgroup)))

                  LEFT JOIN ibf_forums f ON(f.id=mod.forum_id)

                WHERE c.id=f.category AND c.state != 0");

 

В версиях форума старше 1.2 этот запрос может быть немного другим, но смысл проблемы заключается в выделенных строчках. В версиях 1.3.х также применён алиас mod.

При переходе на MySQL версии 4.х (или он у вас стоит если изначально) этот запрос будет выдавать ошибку, т.к. в MySQL версии 4.х появилась функция MOD (получение остатка от деления) и MySQL будет трактовать алиас mod как функцию.

 

Решение: поменять все выделеенные алиасы на другие уникальные алиасы, которых нет в этом запросе, например md:

//--------------------------------------------

    // Do we have any moderators?.

    //--------------------------------------------

   

    $DB->query("SELECT m.id, m.name, m.email, m.hide_email, m.location, m.aim_name, m.icq_number,

                        f.id as forum_id, f.read_perms, f.name as forum_name, c.state

                FROM ibf_members m, ibf_categories c

                  LEFT JOIN ibf_moderators md ON((m.id=md.member_id or (md.is_group=1 and md.group_id=m.mgroup)))

                  LEFT JOIN ibf_forums f ON(f.id=md.forum_id)

                WHERE c.id=f.category AND c.state != 0");

Изменено 8 Ноября 2005 пользователем Song

[Song]

Косяк №9 при голосовании.

Если у участника форума есть маска доступа к разделу, но нет маски отвечать или начинать темы, он всё-равно может голосовать в голосованиях в этом разделе.

 

Файл lib/add_poll.php

 

Найти строки

     $DB->query("SELECT f.allow_pollbump, t.*, p.pid as poll_id,p.choices,p.starter_id,p.votes from ibf_polls p, ibf_topics t, ibf_forums f WHERE t.tid='".$ibforums->input['t']."' and p.tid=t.tid and t.forum_id=f.id");
     
     $this->topic = $DB->fetch_row();

 

изменить на

     $DB->query("SELECT f.allow_pollbump, f.reply_perms, t.*, p.pid as poll_id,p.choices,p.starter_id,p.votes from ibf_polls p, ibf_topics t, ibf_forums f WHERE t.tid='".$ibforums->input['t']."' and p.tid=t.tid and t.forum_id=f.id");

    

     $this->topic = $DB->fetch_row();

 

  if ( $std->check_perms($this->topic['reply_perms']) == FALSE )

  {

   $std->Error( array( LEVEL => 1, MSG => 'no_permission') );

  }

[Song]

Косяк №10, опять индекса

В таблицах ibf_tracker и ibf_forum_tracker

отсутствуют важнейшие индекса, отсутствие которых приводит к перебору все таблицы подписок на топики и форумы при каждом посте.

Чтобы ускорить работу MySQL'я, выполните следующие запросы:

ALTER TABLE ibf_tracker ADD INDEX (member_id), ADD INDEX(topic_id)
ALTER TABLE ibf_forum_tracker ADD INDEX (member_id), ADD INDEX (forum_id)

[Song]

Косяк № 11 при запросе категории.

 

При запросе какой-то определённой категории форум обращается ко всей таблице ibf_forums дабы достать все разделы, вместо того, чтобы просто достать только те разделы, которые относятся к данной категории.

Дело в том, что при сборе данных со всей таблицы ibf_forums, форум не использует индекса. А если запрашивать только разделы определённой категории будет использован PRIMARY индекс таблиц ibf_forums и ibf_categories.

Таким образом, при запросе разделов, принадлежащих только одной конкретной категории мы будем иметь выйгрыш в скорости и в какой-то мере возможно снизим нагрузку на БД.

 

О том как это сделать:

 

Найдите в Boards.php

$DB->query("SELECT f.*, c.id as cat_id, c.position as cat_position....

Вставьте перед ним строки:

        if ( $ibforums->input['c'] ) $ibforums->input['c'] = intval($ibforums->input['c']);

$cat = ( $ibforums->input['c'] ) ? " and c.id='".$ibforums->input['c']."'" : "";

Чуть ниже находим

WHERE c.id=f.category

и исправляем на

WHERE c.id=f.category{$cat}

[Song]

Косяк №12.

Индекса в таблице ibf_contacts.

Как выяснилось таблица почти не индексирована. И БД перебирает её при работе с личными сообщениями например.

Чтобы добавить индекс выполните следующий запрос:

ALTER TABLE ibf_contacts ADD INDEX member_id (member_id, contact_id)

[Song]

house

Косяк №5.

Разработчики форума версии 1.3 для удаления юзера из

Добавлено в [mergetime]1110207920[/mergetime]

Косяк №13.

Аналогично косяку №5 (функция удаления одиночного аккаунта) также недобросовестно написана фукнция удаления многих юзеров. Не все данные удаляются и при регистрации выводится ошибка дублирования PRIMARY ключа.

 

Заменить функцию doprune() из файла ad_member.php на:

 

function doprune() {
global $IN, $INFO, $DB, $SKIN, $ADMIN, $std, $MEMBER, $GROUP;

//-----------------------------
// Make sure we have *something*
//------------------------------

$query = trim(urldecode($std->txt_stripslashes($IN['query'])));

$query = str_replace( "<", "<", $query );
$query = str_replace( ">", ">", $query );

if ($query == "")
{
 $ADMIN->error("Ошибка запроса удаления. Нет запроса на удаление.");
}

//-----------------------------
// Get the member ids...
//------------------------------

$ids = array();

$DB->query("SELECT id FROM ibf_members WHERE ".$query);

if ( $DB->get_num_rows() )
{
 while ($i = $DB->fetch_row())
 {
  $ids[] = $i['id'];
 }
}
else
{
 $ADMIN->error("Не найдено ни одного пользователя, соответствующего введённым критериям.");
}

$id_string = implode( "," , $ids );

$id_count = count($ids);

// Convert their posts and topics into guest postings..

$DB->query("UPDATE ibf_posts SET author_id='0' WHERE author_id IN(".$id_string.")");

$DB->query("UPDATE ibf_topics SET starter_id='0' WHERE starter_id IN(".$id_string.")");

// Delete member...

$DB->query("DELETE from ibf_members WHERE id IN(".$id_string.")");

$DB->query("DELETE from ibf_pfields_content WHERE member_id IN(".$id_string.")");

$DB->query("DELETE from ibf_member_extra WHERE id IN(".$id_string.")");
// Delete member messages...

$DB->query("DELETE from ibf_messages WHERE member_id IN (".$id_string.")");
$DB->query("DELETE from ibf_contacts WHERE member_id IN (".$id_string.") or contact_id IN (".$id_string.")");

// Delete member subscriptions.

$DB->query("DELETE from ibf_tracker WHERE member_id IN (".$id_string.")");
$DB->query("DELETE from ibf_forum_tracker WHERE member_id IN (".$id_string.")");
$DB->query("DELETE from ibf_warn_logs WHERE wlog_mid IN (".$id_string.")");

// Delete from validating..

$DB->query("DELETE FROM ibf_validating WHERE member_id IN (".$id_string.")");

// Set the stats DB straight.

$DB->query("SELECT id, name FROM ibf_members WHERE mgroup <> '".$INFO['auth_group']."' ORDER BY joined DESC LIMIT 0,1");

$memb = $DB->fetch_row();

$DB->query("SELECT COUNT(id) as members from ibf_members WHERE mgroup <> '".$INFO['auth_group']."'");
$r = $DB->fetch_row();
// Remove "guest" account...
$r['members']--;
$r['members'] < 1 ? 0 : $r['members'];

$DB->query("UPDATE ibf_stats SET ".
              "MEM_COUNT={$r['members']}, ".
              "LAST_MEM_NAME='" . $memb['name'] . "', ".
              "LAST_MEM_ID='"   . $memb['id']   . "'");
              
// Blow me melon farmer

$ADMIN->save_log("Удаление $id_count пользователей");

if ( USE_MODULES == 1 )
{
 $this->modules->register_class(&$this);
 $this->modules->on_delete($ids);
}

$ADMIN->done_screen("Пользователи удалены", "Управление пользователями", "act=mem&code=edit" );

}

[Song]

Косяк №14

 

в регулярном выражении "чистки" $HTTP_POST_VARS.

При употреблении в посте строки угл.скобкаSCRIPTугл. скобка она заменяется в маленький регистр, хотя совершенно голословно, постивший этого не заказывал.

Тест на данном форуме: <script> (при оформлении поста писалось большими буквами).

Не совсем правильно написано регулярное выражение.

Вообще оно даже не совсем нужно и оставлено в целях ещё одной проверки для безопасности, дабы не допустить постинг пользовательских скриптов. Как говорится "на всякий случай".

 

Файл functions.php

 

Находим функцию clean_value($val)

В ней находим строчку

     $val = preg_replace( "/<script/i"  , " 60;script"   , $val );

и заменяем на

$val = preg_replace( "/<(script)/i"  , " 60;\\1"   , $val );

 

Примечание: " 60;" пробела быть не должно.

 

Добавлено в [mergetime]1110391766[/mergetime]

ну как я и говорил

здесь тоже этот "баг" есть.

[Song]

Косяк №15

 

с фантастикой в коде.

Файлы post_reply_post.php, post_q_reply_post.php

 

Находим кодим:

  if ($this->topic['poll_state'] == 'closed' and $ibforums->member['g_is_supadmin'] != 1)
 {
	 $std->Error( array( LEVEL => 1, MSG => 'no_replies') );
 }

 

Вообще очень интересно, что такое g_is_supadmin.

Это вообще неизвестный мне зверь

Поэтому этот кусок нужно немного видоизменить на такой:

  if ( !$this->topic['approved'] or $this->topic['poll_state'] == 'closed' )
 {
	 $std->Error( array( LEVEL => 1, MSG => 'no_replies') );
 }

 

наверно всё же это задумывалось, чтобы оставить лазейку для ответов в закрытые голосования главным модераторам, но

1) ошиблись в написании

2) и мы не будем им давать спуску

[Hostem]

Косяк №16

 

Когда удаляем пользователя - удаляем его ПМ-ки, НО не удаляются те ПМ-ки которые он отправлял. Все хорошо, но ПМ-ки удаленных пользователей не отображаются, и пишет не точное количество отображаемых ПМ-ок. В результате ПМ-ки теряются и никто их не удалит и не просмотрит... (там дело в том что делается взаимное соответствие между ПМ-кой и отправителем, а не сначала берем ПМ-ку а потом достаем инфу об отправителе)

 

 

Решение. Файл messenger.php

 

Вариант 1: (Song)

 

if ($this->vid == 'sent')
               {
                       $ibforums->lang['message_from'] = $ibforums->lang['message_to'];

                       $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m, ibf_members mp WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' and mp.id=m.recipient_id ORDER BY $sort_key LIMIT $start, $p_end");

               }
               else
               {
                       $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m, ibf_members mp WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' and mp.id=m.from_id ORDER BY $sort_key LIMIT $start, $p_end");
               }

 

на

if ( $this->vid == 'sent' )
		{
			$ibforums->lang['message_from'] = $ibforums->lang['message_to'];

			$DB->query("SELECT m.*, IFNULL(mp.name,'Unknown member') as from_name FROM ibf_messages m 
			    LEFT JOIN ibf_members mp ON (mp.id=m.recipient_id) 
			    WHERE m.member_id='".$this->member['id']."' AND m.vid='".$this->vid."'
			    ORDER BY $sort_key LIMIT $start, $p_end");
		} else
		{
			$DB->query("SELECT m.*, IFNULL(mp.name,'Unknown member') as from_name FROM ibf_messages m 
			    LEFT JOIN ibf_members mp ON (mp.id=m.from_id) 
			    WHERE m.member_id='".$this->member['id']."' AND m.vid='".$this->vid."'
			    ORDER BY $sort_key LIMIT $start, $p_end");
		}

 

Вариант 2: (Hostem)

 

Заменить это:

                 if ($this->vid == 'sent')
                {
                        $ibforums->lang['message_from'] = $ibforums->lang['message_to'];

                        $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m, ibf_members mp WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' and mp.id=m.recipient_id ORDER BY $sort_key LIMIT $start, $p_end");

                }
                else
                {
                        $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m, ibf_members mp WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' and mp.id=m.from_id ORDER BY $sort_key LIMIT $start, $p_end");
                }

 

На это:

                 
                if ($this->vid == 'sent')
                {
                        $ibforums->lang['message_from'] = $ibforums->lang['message_to'];

                        $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m LEFT JOIN ibf_members mp ON (mp.id=m.recipient_id) WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' ORDER BY $sort_key LIMIT $start, $p_end");

                }
                else
                {
                        $DB->query("SELECT m.*, mp.name as from_name FROM ibf_messages m LEFT JOIN ibf_members mp ON (mp.id=m.from_id) WHERE member_id='".$this->member['id']."' AND vid='".$this->vid."' ORDER BY $sort_key LIMIT $start, $p_end");
                }

 

Ищем (чуть ниже предыдущего кода):

                                 if ($this->vid != 'sent')
                                {
                                        $row['add_to_contacts'] = "[ <a href='{$ibforums->base_url}act=Msg&CODE=02&MID={$row['from_id']}'>{$ibforums->lang[add_to_book]}</a> ]";
                                }
                                else
                                {
                                        $row['from_id'] = $row['recipient_id'];
                                }

 

Добавляем после:

                        
                                 if (!$row['from_name'])
                                {
                                   $row['from_name']="Unknown User";
                                   $row['add_to_contacts']="";
                                }

 

В результате ПМ-ка будет отображаться, а в поле "Отправитель" будет написано "Unknown User" без ссылки добавить в контакты.

[Song]

Косяк №17

файл Topics.php

 

Это я вообще кроме как бредом (то что здесь написано) назвать не могу:

  if ( ! $DB->get_num_rows() )
 {
	 if ($first >= $ibforums->vars['display_max_posts'])
	 {
   // Get the correct number of replies...
   
   $newq = $DB->query("SELECT COUNT(pid) as pcount FROM ibf_posts p, ibf_members m WHERE p.topic_id=".$this->topic['tid']." and p.queued !=1 AND p.author_id=m.id");
   $pcount = $DB->fetch_row($newq);
   
   $pcount['pcount'] = $pcount['pcount'] > 0 ? $pcount['pcount'] - 1 : 0;
   
   // Update the post table...
   
   if ($pcount['pcount'] > 1)
   {
  	 $DB->query("UPDATE ibf_topics SET posts=".$pcount['pcount']." WHERE tid='".$this->topic['tid']."'");
   }
   
   $std->boink_it($ibforums->base_url."act=ST&f={$this->forum['id']}&t={$this->topic['tid']}&view=getlastpost");
   exit();
	 }
 }

 

Этот кусок кода надо заменить на

	if ( !$DB->get_num_rows() and $this->first >= $ibforums->vars['display_max_posts'] )
{
 $DB->query("SELECT COUNT(pid) as pcount FROM ibf_posts WHERE topic_id='".$this->topic['tid']."' and queued != 1");

 $pcount = $DB->fetch_row();

 $pcount['pcount'] = ( $pcount['pcount'] ) ? $pcount['pcount'] - 1 : 0;
	 
 $DB->query("UPDATE ibf_topics SET posts='".$pcount['pcount']."' WHERE tid='".$this->topic['tid']."'");

 $std->boink_it($ibforums->base_url."showtopic=".$this->topic['tid']."&view=getlastpost");

 exit();
}

 

Сей глюк проявляется в том, что безпричинно пропадают страницы в топике, хотя на самом деле в БД посты присутствуют. "Портится" поле posts в таблице ibf_topics.

[NvG]

Косяк №18

 

В админке ipb 1.3 редактирование шаблонов.

 

Апострофы там экранируются с помощью str_replace("'","\'",...); но если в шаблоне написать что-то вроде

var test = 't\'est';

то вылезет ошибка sql. Если же

var test = 't\\'est';

— то всё работает как и задумано.

 

Фиксим

Открываем sources/Admin/ad_templates.php.

 

Ищем:

  //+-------------------------------
 // Process my bits :o
 //+-------------------------------
 
 foreach( $ids as $id )
 {
 
	 $text = stripslashes($HTTP_POST_VARS['txt_'.$id]);
 
	 //+-------------------------------
	 // Sw(o|a)p back < & >
	 //+-------------------------------
	 
	 $text = preg_replace("/</", "<", $text);
	 $text = preg_replace("/>/", ">", $text);
	 $text = preg_replace("/&/", "&", $text);
	 
	 $text = str_replace( '\\n' , '\\\\\\n', $text );
	 
	 //+-------------------------------
	 // Convert \r to nowt
	 //+-------------------------------
	 
	 $text = preg_replace("/\r/", "", $text);
	 
	 $text = $this->unconvert_tags($text);
	 
	 //+-------------------------------
	 // Update the DB
	 //+-------------------------------
	 
	 $string = $DB->compile_db_update_string( array (
               'section_content' => $text,
               'updated'         => time(),
              )       );
	 
	 $DB->query("UPDATE ibf_skin_templates SET $string WHERE suid=$id");
 
 }

заменяем на:

  //+-------------------------------
 // Process my bits :o
 //+-------------------------------
 
 foreach( $ids as $id )
 {
 
	 $text = stripslashes($HTTP_POST_VARS['txt_'.$id]);
 
	 //+-------------------------------
	 // Sw(o|a)p back < & >
	 //+-------------------------------
	 
	 $text = preg_replace("/</", "<", $text);
	 $text = preg_replace("/>/", ">", $text);
	 $text = preg_replace("/&/", "&", $text);
	 
	 $text = str_replace( '\\n' , '\\\\\\n', $text );
	 
	 //+-------------------------------
	 // Convert \r to nowt
	 //+-------------------------------
	 
	 $text = preg_replace("/\r/", "", $text);
	 
	 $text = $this->unconvert_tags($text);
	 
	 //+-------------------------------
	 // Update the DB
	 //+-------------------------------
	 
	 $string = $DB->compile_db_update_string( array (
               'section_content' => str_replace("\'","'",mysql_escape_string($text)),
               'updated'         => time(),
              )       );
	 
	 $DB->query("UPDATE ibf_skin_templates SET $string WHERE suid=$id");
 
 }

[Vic'er]

Косяк №19

 

NvG:

 

Поиском вроде не нашел, если не так, удалите пост

 

Вчера в очередной раз оптимизировал запросы и вышел на запрос, выдающий кол-во сообщений в темах с последнего визита

SELECT COUNT(DISTINCT(p.pid)) as posts, COUNT(DISTINCT(p.topic_id)) as topics FROM ibf_posts p WHERE p.post_date > 'NNNNNNNN' AND queued <> 1 AND forum_id IN ( 0,1,2,3,4,5,6,7,9,8,10,NN)

, который обрабатывался непозволительно долго - на локальной тачке время рендеринга страницы было до 3х секунд(после комментирования оного страница обрабатывалась 0,2 с.)

 

В итоге выяснилось, что проверка p.post_date > 'NNNNNNN' вызывает эти тормоза. В таблице присутствовал индекс forum_id (forum_id , post_date), но видать такого мало. После создания отдельного индекса по post_date

ALTER TABLE `ibf_posts` ADD INDEX ( `post_date` )

все нормализовалось

 

Song, Hostem:

 

Также индекса и структура таблиц.

 

ibf_voters:

 

Поле member_id типа varchar(32), а не int!

 

+ только один индекс, хотя запросы делаются так:

SELECT member_id from ibf_voters WHERE member_id=2461 and tid=990

 

Добавить индекс и сменить тип поля:

ALTER TABLE ibf_voters MODIFY member_id mediumint(8) unsigned NOT NULL default 0, ADD INDEX (tid, member_id)

 

ibf_polls:

 

ALTER TABLE ibf_polls ADD UNIQUE KEY (tid)

 

ibf_topics:

ALTER TABLE ibf_topics DROP COLUMN rating, DROP COLUMN total_votes

Вот с полем типа TEXT они просчитались Это же не VARCHAR

Висит в таблице и не используется

 

ibf_members:

ALTER TABLE ibf_members DROP COLUMN misc

Правда, у себя я его не нашёл, видимо давно грохнул.

 

ibf_posts:

Ещё есть одно бесполезное поле в ibf_posts:

ALTER TABLE ibf_posts DROP COLUMN post_title

 

ibf_admin_sessions

С варчарами-то, оказалось, беда

Ещё некоторые запросы:

ALTER TABLE ibf_admin_sessions MODIFY MEMBER_ID mediumint(8) unsigned NOT NULL default 0

 

ibf_categories:

ALTER TABLE ibf_categories MODIFY state TINYINT(1) unsigned NOT NULL default 0

 

ibf_forumtracker:

ALTER TABLE ibf_forum_tracker MODIFY member_id mediumint(8) unsigned NOT NULL default 0

 

ibf_forums:

ALTER TABLE ibf_forums MODIFY status TINYINT(1) unsigned NOT NULL default 0

 

ibf_members:

ALTER TABLE ibf_members MODIFY hide_email TINYINT(1) unsigned NOT NULL default 0

 

Запросы по индексам:

-- лишний индекс:
ALTER TABLE ibf_forums DROP INDEX id

-- если смайлов много, может помочь:
ALTER TABLE ibf_emoticons ADD INDEX (clickable)

-- убыстрение функции "Слежение за письмами"
ALTER TABLE ibf_messages ADD INDEX (from_id)

 

Не говоря уж о том, что в ibf_posts почти все поля NULL, хотя должны быть NOT NULL default 0.

Но это я уже давно исправил, не помню запросы.

Изменено 8 Сентября 2005 пользователем Song

[Song]

Косяк №20

 

При отмене постов, находящихся на премодерации, в которых есть прикреплённые файлы, последние не удаляются.

 

Файл mod_cp.php

 

В функции

function domod_topics()

находим

  if ( count($delete_ids) > 0 )
 {
	 // Sort out the approved bit
	 
	 $tids = implode( ",", $delete_ids );
	 // Delete 'dem postings
	 
	 $DB->query("DELETE FROM ibf_topics WHERE tid IN ($tids)");
	 
	 $DB->query("DELETE FROM ibf_posts WHERE topic_id IN ($tids)");
	 
	 
 }

заменяем на

  if ( count($delete_ids) > 0 )
 {
	 $tids = implode(",", $delete_ids);
	 
	 //------------------------------------
	 // Remove the topics
	 //------------------------------------

	 $DB->query("DELETE FROM ibf_topics WHERE tid IN (".$tids.")");
	 
	 //------------------------------------
	 // Remove the attachments
	 //------------------------------------

	 $DB->query("SELECT pid, attach_id FROM ibf_posts WHERE topic_id IN (".$tids.") and attach_id != ''");

	 if ( $DB->get_num_rows() )
	 {
   while ( $r = $DB->fetch_row() )
   {
  	 if ( is_file($this->upload_dir."/".$r['attach_id']) )
  	 {
     @unlink($this->upload_dir."/".$r['attach_id']);
  	 }
   }
	 }

	 //------------------------------------
	 // Remove the posts
	 //------------------------------------

	 $DB->query("DELETE FROM ibf_posts WHERE topic_id IN (".$tids.")");

 }

 

В функции

function mod_domodposts()

 

Находим

  if ( count($delete_ids) > 0 )
 {
	 // Sort out the approved bit
	 
	 $pids = implode( ",", $delete_ids );
	 
	 // Delete 'dem postings
	 
	 $DB->query("DELETE FROM ibf_posts WHERE pid IN ($pids)");
	 
 }

и заменяем на

  if ( count($delete_ids) > 0 )
 {
	 // Sort out the approved bit
	 
	 $pids = implode(",", $delete_ids);
	 
	 $DB->query("SELECT attach_id FROM ibf_posts WHERE pid IN (".$pids.") and attach_id != ''");

	 if ( $DB->get_num_rows() )
	 {
   while ( $r = $DB->fetch_row() )
   {
  	 if ( is_file($this->upload_dir."/".$r['attach_id']) )
  	 {
     @unlink($this->upload_dir."/".$r['attach_id']);
  	 }
   }
	 }

	 // Delete 'dem postings
	 $DB->query("DELETE FROM ibf_posts WHERE pid IN (".$pids.")");

 }

[Dekker]

при просмотре топика в FF 1.0.6 (win) в JS косоли выдаёт:

Error: event is not defined

Source File: http://crimea-board.net/html/UBBC/ubbc.js Line: 430

там соотвественно:

/////////////////////////////
// Access Keys
//
 var keys = new Array('b','i','u','s','g','q','m','h','e','l','k');
 function checkKey() {
   if (event.ctrlKey) {
     for (i = 0; i < keys.length; i++) {
       if (String.fromCharCode(event.keyCode) == keys[i].toUpperCase()) {
         var found = keys[i]; break;
       }
     }
...

а надо скорее всего так:

/////////////////////////////
// Access Keys
//
 var keys = new Array('b','i','u','s','g','q','m','h','e','l','k');
 function checkKey(e) {
   if(!e){ e = window.event };
   if (e.ctrlKey) {
     for (i = 0; i < keys.length; i++) {
       if (String.fromCharCode(e.keyCode) == keys[i].toUpperCase()) {
         var found = keys[i]; break;
       }
     }
...

 

прав или не прав, бить или не бить ?

[PALADIN+]

Song

Что-то не нашёл у себя файла ad_massive.php из косяка №5. Это откуда*? У меня 1.3

 

 

К пачке исправлений из Косяка №19

ibf_members:

 

ALTER TABLE ibf_members DROP COLUMN misc

 

Правда, у себя я его не нашёл, видимо давно грохнул.

 

А почему тогда идёт обращение к ней в базе при попытке залогиниться?

Соответственно выдаёт ошибку

 

mySQL query error: SELECT id, name, password, misc FROM ibf_members WHERE LOWER(name)='Логин-нейм'

 

mySQL error:

mySQL error code:

 

ibf_forums:

 

ALTER TABLE ibf_forums MODIFY status TINYINT(1) unsigned NOT NULL default 0

Сделав по рекомендации, все форумы приобрели статус "только чтение", причём обычным способом из админки вернуть их не удалось.

 

По умолчанию там стояло `status` varchar(10) default NULL всё было ок.

 

ibf_topics:

 

ALTER TABLE ibf_topics DROP COLUMN rating, DROP COLUMN total_votes

 

Вот с полем типа TEXT они просчитались  Это же не VARCHAR

Висит в таблице и не используется

На моём форуме видимо используется =)

 

mySQL query error: UPDATE ibf_topics SET poll_state='', last_vote='', total_votes='' WHERE tid='1029'

 

mySQL error: Unknown column 'total_votes' in 'field list'

mySQL error code:

Date:

 

ALTER TABLE `ibf_posts` ADD INDEX ( `post_date` )

 

все нормализовалось

и др. запросы к ibf_posts.

Было бы неплохо сразу предупредить, что если ibf_posts большой (у меня 35 метров) ждать придётся до зелёных веников.

(Думал что сглючило, запустил его три раза подряд)

[Song]

Что-то не нашёл у себя файла ad_massive.php из косяка №5. Это откуда*? У меня 1.3

У меня тоже нет.

В разных модификациях видимо по-разному.

Вероятно в 1.3.1 от Игорька.

 

А почему тогда идёт обращение к ней в базе при попытке залогиниться?

вообще перый раз слышу про такой запрос.

Просьба: посмотри дальше по тексту где-нить оно ещё используется или нет? Если нет, то смело удаляй из таблицы и из исходника.

 

Сделав по рекомендации, все форумы приобрели статус "только чтение", причём обычным способом из админки вернуть их не удалось.

По умолчанию там стояло `status` varchar(10) default NULL всё было ок.

 

ничего страшного.

Сделай

UPDATE ibf_forums SET status=1

 

На моём форуме видимо используется =)

это на моём форуме тоже есть.

Но это "использование" этим и ограничивается.

Убери из исходника эти ненужные запросы.

 

Было бы неплохо сразу предупредить, что если ibf_posts большой (у меня 35 метров)

ну эт разве большой

[replicant]

Было бы неплохо сразу предупредить, что если ibf_posts большой (у меня 35 метров) ждать придётся до зелёных веников.

(Думал что сглючило, запустил его три раза подряд)

<{POST_SNAPBACK}>

 

640 Mb - это большой, а у вас боюсь действительно сглючило.

 

Просьба:

 

Можно помечать в будущем для какой версии форума или хотя бы на какой версии форума все пробовалось ? Зная, конечно что товарищ Song в основном работает с 1.2-1.3 пришлось все равно сверять почти все совету в ветке на предмет совместимости или похожести на 2.0.х ...

 

оч. не удобно, но в целом многие вещи, особенно с оптимизацией БД и индексами подходят и для двойки

[Song]

Можно помечать в будущем для какой версии форума или хотя бы на какой версии форума все пробовалось ? Зная, конечно что товарищ Song в основном работает с 1.2-1.3 пришлось все равно сверять почти все совету в ветке на предмет совместимости или похожести на 2.0.х ...

 

Название темы прочитай !!!