Комментарии / Публикации aVadim / Alto CMS

+62.91

154.072

Вадим

Исправлено и выложена обновленная версия.

В принципе, для решения этой проблемы достаточно обновить только один файл: engine/include/Func.php

В вашем случае можно сделать так:

class PluginDummy_WidgetFoo extends Widget {

    public function Exec() {
        // Получаем шаблонную переменную из вьюера
        $oTopic = E::ModuleViewer()->getTemplateVars('oTopic');
        if ($oTopic) {
            // Получаем автора топика
            $oUser = $oTopic->getUser();
            // Получаем доп. информацию, вызывая метод getSomeInfo() модуля Foo плагина Other
            $xSomeInfo = E::Module('PlugineOther\Foo')->getSomeInfo($oUser->getId);
            // Передаем значение в шаблон для вывода
            E::ModuleViewer()->Assign('xSomeInfo', $xSomeInfo);
        }
    }
}

Вот тут решение проблемы: altocms.ru/1314.html#comment23548

Категории проверю. А поиск — да, он не работает по этому типу блогов

Совсем не то, мне нужно ограничить функционал пользователям, например...

Вот это еще раз подтверждает, насколько важна конкретика и четкое описание конечной задачи. Что значит «например»? То, как можно использовать «группы» в принципе? Или это именно то, что нужно непосредственно Вам в конкретном проекте?

Сразу хочу отметить, что полноценной премодерации в движке нет. Но есть плагин «Песочница», который позволяет весь контент новичков изолировать от остального контента. Плюс плагин Magic Rules, который позволяет задавать довольно сложные правила на запрет или право публикования контента. Вам не подходит это функционал или его даже не смотрели?

Что касается отсылки к другим движкам, то вариант «хочу здесь как там», к сожалению, не работает по определению, потому что «здесь вам не там» :)

Ага, теперь стало понятней. Буду смотреть

Да, есть такое. Исправлено: github.com/altocms/altocms/commit/e666dd03a62b930235434cb7955377ed1a4bbad0

Так правки прямо в базе что ли выполнялись или как? Можете описать пошагово, как получить ошибку? Я не из праздного любопытства спрашиваю. Мне важно понять, можно ли как-то на уровне движка предотвратить ошибку или тут сугубо «человеческий фактор» и с этим уже ничего не поделаешь

В результате форматирование сайта сломалось (что очевидно).

Да вот как-то не очень очевидно. Вот, попробовал воспроизвести проблему:
demo.altocms.com/new/39.html

Не получилось. Т.е. сам текст топика, конечно, сломался, но верстка страницы в целом не пострадала. Испробованные варианты:


<video>https://www.youtube.com/watch?v=uT3SBzmDxGk</video>
<video>https://www.youtube.com/watch?v=uT3SBzmDxGk/video>
<video>https://www.youtube.com/watch?v=uT3SBzmDxGk video>
<video>https://www.youtube.com/watch?v=uT3SBzmDxGk >
<video>https://www.youtube.com/watch?v=uT3SBzmDxGk

Возможно, там не просто тег был не закрыт, а какая-то особая комбинация, которая все сломала

Ок, давайте с малого :)

Вывод разговоров выполняется в экшене ActionTalk. Поэтому стандартное расположение файлов шаблонов для этого экшена стоит искать в папке common/templates/skin/[skin_name]/tpls/actions/talk/.

Конкретно вывод одной беседы реализуется через action.talk.message.tpl. В конце этого файла идет подключение комментариев, вот этот код:

{if !$bNoComments}
         {include
         file='comments/comment.tree.tpl'
         iTargetId=$oTalk->getId()
         sTargetType='talk'
         iCountComment=$oTalk->getCountComment()
         sDateReadLast=$oTalkUser->getDateLast()
         sNoticeCommentAdd=$aLang.topic_comment_add
         bNoCommentFavourites=true}
{/if}

Т.е. тут идет подключение файла comments/comment.tree.tpl. Это значит, что если никаких переопределний не было сделано, то будет подключен файл common/templates/skin/[skin_name]/tpls/comments/comment.tree.tpl.

Если хочется сделать свой собственный вывод комментариев к беседе, то лучше всего создать новый шаблонный файл для вывода комментариев, например, comment.talk.tpl и подключать в action.talk.message.tpl его. И, соответственно, его и править.

Только прежде, чем вносить любые изменения в шаблонные файлы, надо сначала создать собственный скин. Например, скопировать common/templates/skin/experience в common/templates/skin/myskin и там уже править.

«Плоский» вывод комментариев — это надо просто шаблон править.

А вот «склеивание» переписки — это нужно плагин писать. Но мне не очень понятна логика. Допустим, при создании письма, где один получатель, можно сделать запрос, чтоб найти, нет ли уже разговора между двумя. А если получатель не один? Движок ведь это позволяет. А если число участников меняется в процессе общения (добавляются новые участники или исключаются имеющиеся)? Не очень понятно, как в этом случае должно работать.

Не вполне понял насчет «Ленты»: что значат «режимы»? Нет, логика понятна, но что это с точки зрения интерфейса? Четыре кнопки? А так, если я верно понял, предлагается фид разбить на два потока — посты и комменты, выделяя в каждом новые.

Что касается подписки, то предложения понятны. Только вот не уверен я, что подписка на контент обязательно должна автоматически совмещаться с подпиской на активность. Более того, не раз уже я слышал, что отслеживание активности не особо и востребованная фича. Давно зреет у меня мысль под термином «подписка» понимать именно подписку на контент: подписка на комменты в топике, подписка на блог (весь контент в этом блоге), подписка на юзера (весь контент, генерируемый этим юзером). А отслеживание активности оставить между френдами.

А вот по поводу новых — тут полностью согласен. Должно быть «Все» — это все топики в обратной сортировке по дате, и «Новые» — это то, что юзер еще не читал. И тогда для неавторизованного юзера списка новых просто не будет.

Транзакции в движке, к сожалению, не используются. Печально, но факт. Со всеми вытекающими. Да и вообще работа с доп.полями спроектирована неудачно и совершенно однозначно требует переделки.

Может его в папку app перетащить лучше?

Нет, не получится. Он подгружается ДО базового конфига engine/config.php, когда еще неизвестен путь к папке приложений.

Можно автоматом включать, если включен дебаг.

А вот это, пожалуй, стоит делать

Причем, на этапе активной разработки и отладки я бы советовал и первый параметр отключать, т.е. задавать:

$config['compress']['css']['merge'] = false;

Чтоб не тратилось время на сборку в один файл. А когда все более-менее устаканится, то его уже включить.

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

Я обычно делаю так: если расширения/дополнения для конкретного сайта делаются, то я создаю плагин для этого сайта и все, что нужно для данного сайта, пишу в этот плагин.

Что касается групп — я не понял из объяснения, для чего нужны группы. Задача какая? Группы нужны, чтобы что? Зачем юзеру нужно попадать в ту или иную группу?

Пример 1: Я хочу группу наподобие групп во вконтактике — юзеры могут туда вступать, что-то писать в группу, получать уведомления о новых записях в группу.

Решение: создаем новый тип блога, называем этот тип «Группа», задаем в настройках типа, что писать туда и комментировать могут только участники (подписанты). Заодно можете задать, кто может создавать эти блоги-группы — все юзеры или только с определенным рейтингом.

Пример 2: Я хочу, чтоб у меня на сайте была «группа читателей» и «группа писателей».

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

Ну, и т.д. Плюс тут уже посоветовали Magic Rules, с помощью которого можно добавить новые правила — по дате регистрации, по числу написанных комментов и/или топиков («из коробки» работают правила только по рейтингу).

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

Через админку реализован минимум настроек, львиная доля настроек выполняется с помощью редактирования конфиг-файлов. Берутся нужные настройки из common/config/config.php и добавляются а app/config/config.local.php.

Например, чтобы включить наложение водяного знака на загружаемые картинки нужно в app/config/config.local.php добавить такой код:

$config['module']['uploader']['images']['topic'] = array(
    'transform' => array(
        'watermark' => array(
            'enable' => true,
        ),
    )
);

Могу предположить, что до этого было что-то некорректно записано в конфиг (либо в базу, либо в кеш), а при отключении/включении плагина конфиг перезаписался корректно и все заработало

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

Во-первых, это не так, и далеко не «в любой другой cms» они имеются.

Во-вторых, водяной знак картинкой в данной CMS есть.

В-третьих, про «группы пользователей» все ж придется рассказать — что Вы понимаете под этим. Возможно, и это в Альто уже есть, и нужно только настроить.

aVadim

О себе