На этот раз чисто техническое - исправлена куча ошибок, сделаны небольшие улучшения в интерфейсе, но самое главное - изменена внутренняя структура.
Многие объекты движка могут принадлежать разным базовым объектам - например альбомы, файлы и опросы есть и в группах, и в событиях. Однако у авторов похоже были проблемы с пониманием объектной парадигмы, поэтому например номер группы в объекте это не просто ID, и даже не ITEM_ID - нет, это GROUP_ID! Поэтому невозможно создать объект и универсально обращаться к его "начинке" - обязательно нужно знать тип объекта :( В результате вместо
$parent_obj_id = $bp->current_item_id;
приходится писать
if($bp->current_component == 'groups')
$parent_obj_id = $bp->current_group->group_id;
elseif($bp->current_component == 'events')
$parent_obj_id = $bp->current_event->event_id;
И это безобразие - в КАЖДОМ дочернем объекте! Казалось бы - работает и ладно, но это пока не пытаешься добавить еще один базовый объект...
То же самое и в БД: для проверки разрешения для текущего участника на доступ к дочернему объекту, приходится проверять "если это группа, то запросить из этой таблицы, а если событие - то из той". Результаты таких вычислений в MySQL не оптимизируются индексами, так что скорости все это не добавляет...
Но сегодня этому ужасу положен конец! Правда, самое начало - но ведь "даже самая дальняя дорога начинается с первого шага" (С). В движке сделан нормализованный "близнец" текущего объекта, а в БД на триггерах собираются таблицы "все_объекты" и "участники_всех_объектов", так что проверка на разрешение делается единственным запросом. Форумы и альбом, которые давали наибольшую нагрузку, соответственно переработаны для использования этих новых возможностей. В результате например для отбора картинок галереи, доступных для данного участника и принадлежащих определенной категории, требуется в ~1000 раз меньше времени!
