Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Монстра → Разработка → Предложения по функционалу
Было бы неплохо, чтобы при создании пункта меню, во всплывающем окошке были не только созданные страницы, но и slug активных плагинов.
Маялся тут с организацией аплоада и наткнулся на это - http://www.plupload.com/example_queuewidget.php
Было бы неплохо иметь такой загрузчик встроенным в монстру как хелпер.
Было бы неплохо, чтобы при создании пункта меню, во всплывающем окошке были не только созданные страницы, но и slug активных плагинов.
Сделано. будет в следующем релизе эта фича.
Ещё интересен функционал проверки целостности цмс - с сайта цмс скачивается файл с хешами всех файлов требуемой версии и скриптом сверяется с хешами файлов на хостинге. при не совпадении - предупреждение о повреждении и возможном взломе.
А будет ли вставка снипетов и чанков в редактируемый шаблон прямо из админки??
Думал про отличия тцмс и монстры, и пришла в голову идея - многим действительно бывает нужно ограничить функционал админки для редакторов и т.п. Но часто бывает, что нужна какая-то одна функция за пределами доступа редактора.
Так может сделать возможность задавать в конфиге доступ к функциям для ещё одной настраиваемой роли?
El'Drako
Распределение доступа в Monstra
if (Session::exists('user_role') && in_array(Session::get('user_role'), array('admin', 'editor'))) {
// some code here...
}это в своём коде, я же про функционал цмс. или я не понял приведённый кусок?
El'Drako
Нету конфигов или какого либо функционала в админке по управлению правами.
Этом можно сделать в самом коде используя такую конструкцию.
if (Session::exists('user_role') && in_array(Session::get('user_role'), array('admin', 'editor'))) {
// Это код будет доступен админу и редактору
}дык я не про свой код, а про предложение по расширению функционала цмс и админки. я знаю, что нет сейчас такого 
иначе бы не предлагал.
например над сайтом работает несколько человек.
1. Редактор - он создаёт новые материалы. Ему доступ дальше материалов, sitemap и меню не нужен.
2. Дизайнер. Ему кроме шаблонов, блоков и снипетов тоже ничего не надо.
3. Админ. Ему нужно всё и побольше
Это минимальный простой пример. Возможны в реале так же сочетания функционала этих ролей между собой.
Вот и предлагаю подумать всё же над реализацией как минимум конфига с параметром роли, а в идеале полноценной авторизации юзеров на основе ролей, которые были бы максимально подробны (как минимум по разделам админки).
El'Drako
Когда я делал роль "редактор" то и роль дизайнера обдумывал тоже. Но роль дизайнера невозможна при такой системе шаблонизации которая есть сейчас. т.к. Дизайнер запросто может тогда выполнить любой php код.
Если вводить роль дизайнер, то нужно использовать шаблонизатор 
а не голый php.
Про настраиваемые роли.. да можно будет еще чего нить подумать..
редактор тоже, при включённом теге пхп...
Для этого php тег и выключен) Редактор может работать только с текстом и стеми снипетами (кодом) которые создал админ.
но его же можно и включить
я это к тому, что если человеку дали доступ в админку, значит по идее он не будет её ломать, а будет работать.
и наличие возможности исполнить пхп код нужно рассматривать как дополнительный функционал для дизайнера, а не дыру чтоб нагадить.
El'Drako
> возможности исполнить пхп код нужно рассматривать как дополнительный функционал для дизайнера
Эм.. вообще то дизайнер и php - это не совместимые вещи) даже верстальщик не должен знать php чтобы писать какую ту логику в шаблонах. Т.к. типовой набор верстальщика: html, css и любой из шаблонизаторов (Smarty, Twig и др.)
В том то фишка шаблонизаторов. Они создают своеобразный абстрактный слой для верстальщиков-дизайнеров. Верстальщик-дизайнер не сможет выполнить опасный php код. Например: удалить админов и стать самому админом)
>но его же можно и включить
Владелец хостинга, да) Но включать не желательно. т.к. как это позволит редактору творить все что угодно...
как бы шаблонизаторы для монстры немного лишние - её достоинства в простоте и минимализме. вставлять лишнюю прослойку ради абстрактных мер безопасности имхо лишнее.
Awilum, я тут как-то писал, но ответа что-то не нашёл. Как ты смотришь на то, что бы на страницу установки monstra добавить строчку выбора языка?
И второй вопрос, тоже повторюсь, почему по умолчанию не сделать возможным создавать расширения страниц? Т.е. символы . и _?
что бы на страницу установки monstra добавить строчку выбора языка?
Поддерживаю было бы удобно.
Если так хочется установку на Русском, то можно один раз в файле options.table.xml (storage\database\options.table.xml) заменить en на ru
Если так хочется установку на Русском, то можно один раз в файле options.table.xml (storage\database\options.table.xml) заменить en на ru
Тут вопрос не в хочется, а в удобнее))) Если представить, что я человек 0 в cms, зашёл на сайт, скачал monstra, мне намного удобнее будет сразу на этапе установки выбрать язык, чем потом лазить по панели администратора....) Ну это лично моё мнение)
Святобор пишет:Если так хочется установку на Русском, то можно один раз в файле options.table.xml (storage\database\options.table.xml) заменить en на ru
Тут вопрос не в хочется, а в удобнее))) Если представить, что я человек 0 в cms, зашёл на сайт, скачал monstra, мне намного удобнее будет сразу на этапе установки выбрать язык, чем потом лазить по панели администратора....) Ну это лично моё мнение)
Поддержу
Сделал переключение языка Монстра при инсталляции. Выглядит это сейчас так:
Awilum, а может лучше сделать выбор как у timezone ? Мне кажется будет удобней
угу, и с учётом всех языков в системе - ведь уже есть не только два базовых...
Хотелось бы, чтобы в следующей сборке были изменения в классе для работы с БД. А именно
monstra/engine/xmldb.php класс Table метод select строка~666.
// Convert from XML object to array
if ( ! $one_record) {
$count = 0;
foreach ($_records as $xml_objects) {
$vars = get_object_vars($xml_objects);
foreach ($vars as $key => $value) {
if(is_array($value))
$records[$count][$key] = $value;
else
$records[$count][$key] = (string)$value;
}
$count++;
}
} else {
$vars = get_object_vars($_records[0]);
foreach ($vars as $key => $value) {
$records[$key] = (string)$value;
}
} Это для возможности получать массив атрибутов или нескольких элементов. Для написания плагинов очень удобно. А на текущий функционал не влияет.
Монстра → Разработка → Предложения по функционалу
Форум работает на PunBB, при поддержке Informer Technologies, Inc