LiveStreet CMS

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

От этой маловероятной ситуации не спасёт отдельная таблица для типов топиков.

Такого не будет никогда с вероятностью 99,99999999999% :)

Если одинаковый тип топика «event» добавить хоть в отдельную таблицу, хоть в перечисление enum — будет коллизия.

Если меняем один модуль на другой, в БД ничего менять не нужно. Вы же меняете логику работы, зачем же менять «event» на «event» в базе? :)

Благодарю.

Уязвимость связки PHP + nginx

Сорри, не в тот топик коммент оставил.

Уязвимость связки PHP + nginx

Вопрос снимается. :)

Config::Set('block.rule_topic_type.action.test', array('add','edit'));

Хм. А как это сделать в конфиге плагина?

$config['block']['rule_topic_type'] = array(
	'action'  => array(
		'link'     => array('add','edit'),
		'question' => array('add','edit'),
		'topic'    => array('add','edit'),
		'photoset' => array('add','edit'),
		'test'     => array('add','edit') // Как это сделать в конфиге плагина?
	),
	'blocks'  => array( 'right' => array('block.blogInfo.tpl') ),
);

Неплохо было бы добавить правило относительно времени пребывания на сайте с момента регистрации, чтобы можно было вывести, к примеру, как на хабре «старожил», если пользователь столько-то лет с нами. На дром.ру — тоже медальки за время дают, 1 год — бронзовая медаль, 3 года — серебряная медаль, 5 лет — золотая медаль, 7 лет — георгиевский крест. :)

Тебе кажется, что это правильным, когда меняющйся набор загоняется в ENUM

Перечисление типов топиков не меняется в движке. Это мы, те, кому нужны новые типы топиков, его меняем. Я не вижу смысла создавать отдельную таблицу в БД для этого перечисления, ибо меняется оно в одностороннем порядке — только добавляются новые элементы. Ведь если ты создал новый тип топика, то будешь им пользоваться, а раз будешь пользоваться — всё, удалять тип нельзя. Млм, что архитектурное решение верно по части enum.

Зачем так? Когда можно так:

Один пишет:

$this->addEnumType(Config::Get('db.table.topic'),'topic_type','foo');

Другой:

$this->addEnumType(Config::Get('db.table.topic'),'topic_type','moo');

Третий:

$this->addEnumType(Config::Get('db.table.topic'),'topic_type','hru');

И никаких проблем!

Вот пример обновления convert_0.4.2_to_0.5.1.sql:

-- Добавляет новый тип топика 'photoset', этот запрос автоматически выполняется через инсталлятор при конвертации БД (для сохранения ваших кастомных типов топиков)
-- ALTER TABLE  `prefix_topic` CHANGE topic_type topic_type ENUM('topic','link','question','photoset') NOT NULL DEFAULT 'topic';
-- 

Так что никаких проблем с текущим положением дел.

Если оставить структуру такой как сейчас то сомневаюсь что можно будет установить эти 2 плагина одновременно

Список ENUM в MySQL может содержать максимум 65535 различных величин. Так что установятся без проблем и ещё вагон других.

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

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

Единственный нюанс с этим полем может возникнуть при обновлении структуры таблицы топиков, если таковая будет иметь место в будущих релизах Livestreet. Но, я думаю, ort сделает всё красиво, как всегда. Да и сами при обновлении можете код update.sql проверить.

Спасибо!

Сделал class PluginTest_ActionTest extends ActionTopic, всё проверил — работает. Перезалил.
В общем и целом, меня лично каркас устраивает. Пошёл делать основной функционал…
Спасибо!

topic_extra? Тоже хотелось бы разобраться, что там к чему.

Можно ссылку или что искать?

public $aDelegates = array(
        'template' => array(
            'topic_test.tpl' => '_topic_test.tpl'
        ),
    );

Оно?

Ну да, можно было так class PluginTest_ActionTest extends ActionPlugin, но тогда пришлось бы ActionTopic целиком забирать в PluginTest. А зачем, к примеру, трогать EventDelete, если он одинаков для любых типов топиков. Я мог неправильно что-то сделать, научите.