Адназначна! +1

Да, вот о том, как «помирить» несколько разработчиков, создающих разные расширения, я не подумал :(

Сходу не вижу, в каких случаях на поможет исключительно хук. Если брать пример топикстартера, то мы в классе Ext_LsTopic (который, как говорилось выше, является расширением стандартного LsTopic) объявляем свой метод:

public function AddTopic(TopicEntity_Topic $oTopic) {
  parent::AddTopic(TopicEntity_Topic $oTopic);
  mail('friend1@gmail.com,friend2@gmail.com','Новый топик',$oTopic->getTitle());
  return $oTopic;
}

На мой взгляд, гораздо проще и понятней. Но я допускаю, что в каких-то случаях (я просто не придумал еще, в каких) спасут только хуки. Но в любом случае, если ставить приоритеты, то кастомное расширение классов я бы поставил выше, чем хуки. Тут ведь и придумывать ничего не надо, работа чисто механическая (хоть и не маленькая) — добавить к каждому классу расширение и переписать рождение экземпляров объектов.

А что если с другого конца завернуть? Дать возможность попросту расширять классы, использовать всю мощь, которую дает ООП? Поясню на примере:

Есть класс, скажем, UserEntity_User, идущий в стандартной поставке. Сейчас экземпляры прямо от него и созаются. Я предлагаю так:
1. Есть некий класс (стандартное объявление):

class Std_UserEntity_User0 extends Entity {
  public function getId() {
    return $this->_aData['user_id'];
  }        
  public function getLogin() {
    return $this->_aData['user_login'];
  }
  // ...
  // объявление других методов и свойств
  // ...
}

2. Делаем его расширение (кастомное объявление):

class Ext_UserEntity_User extends Std_UserEntity_User {
  // в стандартной поставке оно "пустое", т.е. просто наследование от родителя и все
}

3. Все экземпляры создаем от этого — расширенного объявления класса

Файлы с описаниями кастомного (расширенного) класса кладем в отдельную папку. Если я хочу чего-то дописать, я не трогаю стандартных описаний (как это сейчас нередко делается), а дополняю описание кастомного класса, например так:

class Ext_UserEntity_User extends Std_UserEntity_User {
  public function getLogin() {
    return '['.parent::getLogin().']';
  }
}

Что это дает? Не нужно ничего дополнительно прописывать в конфигах или где-то еще. Не надо принудительно цеплять какие-то обработчики и проч. Переход к новой версии ЛС может проходить с минимальной головной болью (в лучшем случае просто заливается на хост весь код новой версии, кроме папки с кастомными классами).

Когда выложу в открытый доступ — кину, пока тестирую локально. Но общий принцип описан выше: если есть в сессии user_id — пляшу от него, нет — смотрю, нет ли в куках ключа. Если и ключа нет — даю форму для ввода логина-пароля, а сабмит формы идет на авторизацию ЛС.

Вы все про ВДС? Мне для ковыряния и экспериментов вполне хватает более простых и дешевых решений

Экспериментирую с ЛС на четырехбаксовом тарифе (4 долл.\мес), посмотрел сейчас, какой memory_limit стоит — 32М (функция phpinfo() такую инфу дает).

Не знаю, я испытываю сейчас ЛС на дешевом хостинге, подобных проблем не испытываю. Правда, я сам себе и посетитель пока, но, как я понял, ТС тоже только экспериментирует. Или есть уже какая-то серьезная посещаемость?

Писать специально экшн только для того, чтобы кастомные переменные передать в шаблон? Не знаю, мне кажется это слишком витиеватым.

С настоящей CMS не интегрировал, но к одному из сайтов прикрутил ЛС и использую авторизацию ЛС для разруливания прав юзеров по всему сайту.

А в чем разница — лезть в руками в стандартный экшн и там кидать массив для Смарти или делать это в конфиге? Если я буду таскать непомерно большой массив, то это в любом случае плохо, если он небольшой, то на прозводительности и сжираемых ресурсах практически не скажется. А вот с точки зрения кастомизации мой вариант мне кажется гораздо удобнее и практичнее.

Я недавно начал ковыряться с ЛС, и, возможно, есть уже какие-то решения, которые я пока не заметил, тогда киньте им в меня, плиз

Кстати, было бы лучше, если бы имя ключа в конфиге задавалось. А то мало ли — в исходном коде сайта, к которому ЛС прикручивается, могут уже использоваться куки с тем же именем.

Спасибо за замечание, коллеги! Ясень пень, SQL-инъекции никто не отменял, и явно так делать не стоит. Понятно, что я всего лишь показал ход мыслей, но не подумал, что кто-то может слишком буквально это воспринять. А поэтому дополнил топик предупреждением, что так делать нельзя. :)

А к чему такие сложности и выверты? Есть же Денвер, который специально под Винды сделан, установка занимает 5 минут от силы. Или он под 64 не работает?

Я так понимаю: IIS не умеет обрабатывать .htaccess, а это нужно для корректной работы

А меня даже более простой вариант интересует: есть уже работающий сайт, где регистрации нет вообще или она самая примитивная. Есть большое желание к этому сайту прикрутить ЛС. Вынести на любую существующую страницу форму регистрации или логина — это без проблем. Но как в извне получить инфу — хотя бы ИД только что зарегестрировавшегося (или залогинившегося) юзера? Остальное можно и напрямую из базы получить.