Совсем недавно немецкие коллеги с http://www.amxbans.de, выпустили новую версию этого достойного проекта. Но как всегда, поспешили и людей насмешили. Косяков и проблем в нем обнаружилось много. Оперативно убирать баги они не собираются, и обновление до сих пор не вышло. Русские добры молодцы выпустили свою версию AMXbans 6.

Взять сам дистрибутив можно здесь: http://www.gm-community.net/showthread.php?t=1851 называется он Исправленный дистрибутив AMXBans 6.0 GmAMXBans 1.2

Там же можно найти обновления и для AMX части:

amxbans_core версия 6.0.2
amxbans_main версия 6.0.2

Взять можно тут http://www.gm-community.net/showthread.php?t=1889

В скором времени обещают выпустить и более новую версию GmAMXBans 1.3.

Версия GmAMXBans 1.2, позволяет корректно работать с кодировкой UTF-8. Напомню что все таблицы и сама база данных должна быть в этой кодировке, чтобы все русские буквы отображались корректно. Тут есть небольшой косяк с датой , когда месяц отображался неверно (не в кодировке). Чтобы убрать этот косяк тупым способом, надо во всех файла .tpl изменить строку %d %b %Y на %d.%m.%Y , тогда дата будет отображаться в виде 22.06.2010.

Поскольку у меня стоит версия amxbans 5.0, импорт со старой на новую не захотел работать. По началу выдавалась ошибка Unknown column ‘imported’ in ‘order clause’, эта ошибка решается путем добавления дополнительных столбцов  в таблицу amx_bans старой базы данных

вот SQL запрос, которые необходимо выполнить применительно к старой базе данных:

ALTER TABLE amx_bans ADD imported INT(1);
ALTER TABLE amx_bans ADD expired INT(1);

ALTER TABLE amx_bans ADD ban_kicks INT(11);

CREATE TABLE IF NOT EXISTS `amx_modulconfig` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`menuname` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`name` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`index` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`activ` int(1) NOT NULL DEFAULT ’1′,
PRIMARY KEY (`id`)
)
INSERT INTO `amx_modulconfig` (`id`, `menuname`, `name`, `index`, `activ`) VALUES
(1, ‘_MENUIMPORTEXPORT’, ‘iexport’, », 1);

Но даже после этого импорт не происходил, писалось «неуспешно» для всех банов в базе. Поэтому пришлось вручную выдирать всю бд и переносить ее в новый. Проверено работает.

Но дальше сталкиваемся с проблемой, что причина бана может быть изменена, если «Автоматическая оптимизация базы данных (DB Prune)» разрешена. Лучше ее отключить, конечно старые записи (бан уже истек) не будут удалятся из базы, что не удобно. Пока эту проблему я не смог решить.

ЗЫ. Стоит отметить, что при большой базе данных (более 1000 записи банов), страница подробности бана открывается очень долго. Это решается коментированием строк в файле /include/user/user_bd.php:

//$smarty->assign(«ban_details_activ»,$ban_details_activ);
//$smarty->assign(«ban_details_exp»,$ban_details_exp);
//$smarty->assign(«ban_details_edits»,$ban_details_edits);
//$smarty->assign(«edit_count»,$edit_count);
//$smarty->assign(«activ_count»,$activ_count);
//$smarty->assign(«exp_count»,$exp_count);

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

Также я закоментировал строки:

//$smarty->assign(«msg_banedit»,$msg_banedit);
//$smarty->assign(«msg_demo»,$msg_demo);
//$smarty->assign(«msg_comment»,$msg_comment);

Поскольку от них идут только ошибки в логах.

Стоит отметить и проблемы засирания лог файла вебсервера различными ошибками при работе с amxbans.

Проблема сессий решается  комментированием функции session_start(); в тех файлах, на которые указывают логи. На работе это никак не сказывается.

остальные засеры лога пока не решены.