Возникла необходимость инъекции кода в некоторые фалы движка. Есть ли возможность реализовать это из плагина?
Например, надо немного изменить (без влияния на общую логику работы)

\engine\lib\external\Smarty\libs\sysplugins\smarty_internal_templatecompilerbase.php

Есть 2 плагина. Из каталога, и мой, разрабатываемый. Оба плагина используют переопределение с помощью
$aInherits. Переопределяются одни и теже классы.

Соответственно, если активировать оба плагина — возникает конфликт:

Warning: Class 'PluginChronos_ModuleTopic_MapperTopic' not found in /Users/xxxxx/Sites/xxxxx.local/xxxxx.loc/engine/classes/Engine.class.php on line 1105

Fatal error: Class 'PluginChronos_Inherit_ModuleTopic_MapperTopic' not found in /Users/xxxxx/Sites/xxxxx.local/xxxxx.loc/plugins/chronos/classes/modules/topic/mapper/Topic.mapper.class.php on line 24

По-одиночке — плагины работают корректно. Как быть в такой ситуации?
Подскажите, пожалуйста.

Читать дальше →

По-умолчанию, в LS сортировка при выборке по тегу выполняется по полю topic_id таблицы topic_tag.
Хочу сделать сортировку по одному из полей таблицы topic (у меня там дополнительное поле).

Подскажите, пожалуйста, какой из способов будет оптимальным:

1. Выполнить сортировку полученного массива $data в методе GetTopicsByTag модуля Topic
2. Изменить (переопределить или наследовать) сортировку в методе GetTopicsAdditionalData модуля Topic?


Подскажите, пожалуйста, как правильно составить SQL запрос для метода

public function GetTopicsByTag($sTag,$aExcludeBlog,&$iCount,$iCurrPage,$iPerPage)

Маппера топиков.

Читать дальше →

Подскажите, пожалуйста, что нужно сделать, что бы с LS можно было комфортно работать в IDE PhpStorm?
Спасибо.

Помогите, пожалуйста, разобраться в следующем вопросе:

1. Создаю в плагине с помощью хука дополнительное поле для ввода данных типа дата:

<input required id="topic_realdate" name="topic_realdate" type="text" value="{$_aRequest.topic_real_date|date_format:"%d.%m.%Y"}" class="date-picker input-text" readonly="readonly" />

2. Так как ввод даты будет предполагаться не совсем в стандартном формате, то пытаюсь валидировать это поле с помощью своего метода:
— дополняю массив правил валидации в сущностях своим полем с вызовом обработчика ValidateRealdate

$this->aValidateRules[]=array('topic_realdate','realdate','on'=>array('topic','link','photoset'));

— Дополняю обработчик валидации:

public function ValidateRealdate($sValue,$aParams){
        print "<script>alert('$sValue')</script>";
        if (проверка валидности) { return true; }
        return  'Ошибка валидации';
}

При публикации поста — обработчик валидации вызывается, но в него не передается значение валидируемого поля. Все остальные, стандартные поля топика — передаются успешно.

День добрый.

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

Пример поля:

<input name="topic_realdate" type="text" value="" class="date-picker" readonly="readonly" />

Спасибо за подсказки!

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

Стоит задача — с помощью JS визуально подсветить места расположения хуков на страницах сайта. И получить их идентификатор, например, template_header_banner_begin

Как бы решение проблемы в лоб — догадываюсь, отпарсить шаблоны — получить список хуков, зарегистрировать все хуки с визуально пустым содержимым, присвоить неотображаемым элементам — желаемый id… но мне кажется, это неправильно…

Спасибо за идеи, мысли и тп. по этому поводу.

Рейтинг и сила в сообществах, создаваемых на базе LS являются одной из основных социальных составляющих, опрделяющих возможности пользователей на сайте, основными характеристиками «героев».

Все замечательно для адвинистрации сайта и старожителей. Но для нового пользователя нигде не объяснено про зависимости возможностей его действий на сайте от рейтинга и силы. И наоборот.

Обычно, объяснение взаимосвязей рейтинга, силы и возможностей — ложиться на администрацию сайта, и выглядит как статическая страница с описанием правил сообщества, зависимостей рейтинга, силы и тп…
Если по какойто причине администрация не завела эту страничку, и не объяснила доходчиво пользователю о его возможностях, люди, зачастую, впадают в ступор. Данный сайт, к примеру, не исключение.
Не зная лимитов на действия, мне, например, приходится каждый раз кликать по голосам за топик и тп, и видеть красный информер, напонимающий, что я пока не могу оценить пост. Но не говорится ничего о том, что нужно сделать, что бы оценить пост, какое значение силы нужно набрать для этого и тп… с каждым новым баллом, ты опть идешь, и пробуешь — можешь ли проголосовать или нет. Это бесит. Понятно, что в контесте этого информационного сайта, все равно, но представьте реакцию пользователей на своих сайтах… Особенно, пользователей, далеких от IT, Хабра и аналогичных сообществ. Пользователь, если и не уходит, то не реализовывает для себя всю сущьность движка LS, идеологию и фичи. Так не должно быть.

Предложение:

1. На странице профиля указывать не только текущее значение силы/рейтинга пользователя, но и минимально необходимые значения для действий на сайте — голосования за топики, пользователей, создание блога и тп. Это совсем не сложно — всего лишь вывести данные из конфига LS, добавив небольшие текстовые комментарии.

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

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

А вы как считаете, разработчики и активные пользователи LS?

Вопрос скорее к разработчикам этого отличного движка/разработчикам плагинов.
Подскажите, пожалуйста, нет ли уже встроенной реализации вывода списка топиков, по аналогии с RSS, в виде объектов json?

Если нет, то как проще реализовать (нужен полный аналог существующих RSS лент, только выдача в формате json):
— переделать плагином классы, отвечающие за rss
— создать свой плагин с реализацией json, по аналогии с RSS?

Спасибо большое за помощь и наводки!