Dayver |
|
---|---|
#46306 Kabak: По большому счёту если тащить всё подобные изменения в коробку то она быстро превратится в очень сложную систему разобратся в которой будет черезвычайно сложно. А поскольку код движка из-за своей простоты является очень надёжным и быстрым то это путь в другую сторону. Но решать подобные задачи можно и нужно немного другим методом.
Опишу свой подход как бы решал эту конкретную задачу я в своих проектах. Допустим есть у вас сайт APC ... и нужно вам делать изменения конкретно под этот проект. Тогда создаём плагин с именем например apc и складываем в него все решения которые руки норовят запихнуть в код движка или стандартных модулей и расширений. Так же и с этой конкретной задачей - добавляете новый параметр в конфигурацию своего плагина apc. Дале используя хуки (конкретно по теме обсуждения подойдёт page.add.tags ) создаёте альтернативный тегу 'PAGEADD_FORM_TEXT' свой , например 'PAGEADD_FORM_TEXT_APC' и используете в шаблоне его вместо стандартного. Тогда обновление движка не спровоцирует ситуацию что все ваши внедрения в системные файлы пропадут, а сама настройка и генерация тега по прежнему будут работать из вашего сайто-плагина так как вы ожидаете. // в вашем случае вместо cot::$cfg['page']['minimaxieditor'] // сипользуйте конфигурацию из плагина cot::$cfg['plugin']['apc']['minimaxieditor'] При таком подходе все индивидуальные доработки под конкретно ваш сайт или задачи будут хранится в уникальном плагине ... если задачи от проекта к проекту однотипные то можете выделить сборник подобных решений в одном плагине (и загружать его во все свои сайты), а совсем уникальные задачи решать в индивидуальном сайтовом плагине. При таком подходе и движок не загромождается решениями которые возможно нужны будут только вам и процес обновления будет доступен в ваших проектах. Pavlo Tkachenko aka Dayver
|
|
Отредактировано: Dayver (03.04.2023 10:44, 2 года назад) |