Предложения для следующих версий joostina - страница 8 - Joostina

Еще одно пожелание: доработать JCE или написать отдельный мамбот для WYSIWYG редакторов, позволяющий вставлять ссылку на статью. Т.е. кликаем в кнопочку и выбираем статью из списка (также нужно учитывать и статичное содержимое) и... вуаля - в редактор вставляется ссылка. Это весьма сэкономит время при работе с контентом.

Также можно включить плагин, удаляющий пользователей, не подтвердивших регистрацию (Митрич писал такой - J1.5)

Очень не хватает в ядре аналога $database->loadAssocList, но что-бы он на выходе давал массив, где ключом выступало одно поле, а значением - второе.

Поддерживаю, иногда приходится специально объектлист в массив перегонять.

а можно чтоб при инсталяции можно было указать имя суперадмина - а то admin - какая некакая а потенциальная угроза

ps про функции  - а что никто не додумался написать свой function.php и запихать туда все так нужные ему функции?

Написать-то не сложно, но вот каждый раз в новом компоненте нужно ее повторять.
А о данной функции обмолвился даже Бостон.

Функция, нужная всем должна быть в системе. По этому она будет там. Если Николай не опередит, то я напишу.

С удовольствием обнаружил в свежих коммитах две новых функции вывода результата запроса - loadAssocList и loadAssocRow. Николай Молодец! Пока я на праздниках ломал а потом восстанавливал компьютер он уже все сделал.

>не хватает в ядре аналога $database->loadAssocList
добавлено: http://joomlaforum.ru/index.php/topic,104914.msg749329.html#msg749329

>loadAssocList и loadAssocRow
они там давноооо )

Вчера адаптировал модуль аякс-голосований и понял - чтобы запустить AJAX без связки модуль - компонент надо обойти много ограничений (в т.ч. и ухудшить безопасность), как-то загрузить майнфрейм и т.п., а чтобы сделать правильно, надо обратиться к компоненту для подгрузки данных. Предлагаю сделать одну простую фичу, которая позволит модулям работать правильно и автономно:
- обращаемся через AJAX за данными с помощью гет-запроса ну или аналогично через пост
- в AJAX.index.php проверяем с чего начинается option, если с mod_ - то отправляем в папку этого модуля, допустим к файлу mod_sdfsf.ajax.php, ну а если com_, то к компоненту.

Вот, написал, в файле AJAX.index.php после строки
получается легко, просто и очень полезно для модулей.

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

Вот, написал, в файле AJAX.index.php после строки

Код

// проверяем, какой файл необходимо подключить, данные берутся из пришедшего GET запроса

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

Тогда надо еще сделать проверку на реальное существование данного модуля.

Ну да, а еще проверять, какой группе принадлежит пользователь, и есть ли у него права доступа к этому модулю. Особенно интересно будет, когда будет опубликовано два экземпляра одного модуля, но у одного из них доступ Special, и нужно будет как-то проверять, к какому из них идет ajax-запрос.

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

Нисколько не опаснее чем подключать компоненты, но они почему-то подключаются . C помощью этого кода можно подключить только файл внутри папки /modules, а если такого там нет, то ничего не подключишь.

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

Ну да, а еще проверять, какой группе принадлежит пользователь, и есть ли у него права доступа к этому модулю. Особенно интересно будет, когда будет опубликовано два экземпляра одного модуля, но у одного из них доступ Special, и нужно будет как-то проверять, к какому из них идет ajax-запрос.

По регулировке доступа пользователей к модулям первый раз слышу. А она там есть?

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

Можне еще добавить проверку на существование папки

Подключать аякс-файлы модулей - это как-то спорно... Тогда модули совсем мало будут отличаться от компонентов. Да и путаницы может создаться немало.

Могу предложить альтернативный вариант - компонент com_ajaxmodules, обращение к которому и будет вызывать файлы модулей.

Еще в системе уже есть компонент - com_modules, но он как вижу только загружает указанный модуль. Хотя тоже вариант

Я-же предлагал только самое очевидное решение, если лучше через отдельный компонент, тогда com_modules, там уже есть modules.ajax.php, который выполняет функции modules.php, переписать код из modules.ajax.php в modules.php, а modules.ajax.php использовать для аяксовых дел.

По моему, это только чрезмерно усложнит систему.

Да вовсе нет, там нужно-то пару строчек кода.

Что-то меня возмутил JCE в последней версии (не знаю как раньше) - так насрал в форматирование, что переплюнул весь написанный текст. Вот что он создает вместо простого парагафа без форматирования: Такое не только с параграфами, а с любыми контейнерами. Что сделать чтобы заткнуть этот фонтан?  Очистка кода (стирательная резинка в панели) от этой срани не помогает.

Второе - после редактирование HTML все буквы пропадают, но после сохранения пустого редактора все нормализуется.

Не, обманул, очистка помогает, но надо сначала выделить очищаемое.

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

Предлагая ввести дополнительно два параметра в XML файлы

1. Возможность отображения картинки рядом с radio-кнопками.

например:


2. Дополнительный параметр который будет проверять наличие новой версии

Например:

и ещё пару

не помешало бы сделать кроме выпадающих списков разделов и категорий форму для мультивыбора


ЗЫ
Народ, что думаете? Или это только мне интересно?

и ещё пару

не помешало бы сделать кроме выпадающих списков разделов и категорий форму для мультивыбора


ЗЫ
Народ, что думаете? Или это только мне интересно?

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

Arkadiy, полностью тебя поддерживаю.. никаких разделов, а исключительно многоуровневое категорийность(!)
НО(!) когда это будет реализовано? хотя бы примерные сроки? полгода, год, два? Может проще сейчас добавить две функции не думаю что сложность возникнет.. Могу попробовать сам сделать обработчик, а вдруг приживётся

И тем более, сейчас можно считать тоже есть мультикатегории, только с одноуровневым вложением

Не, мультикатегорий тоже нет. Такая доработка была-бы нам на пользу, ведь пока мы догоняем 1.5, а они делают 1.6, в которой по-моему многоуровневость уже заложена, хотя надо ставить цель дальше чем уже есть в Joomlaх, только тогда мы можем хоть в чем-то ее обогнать.

очень плохо, что Николай не принимает участие в обсуждении данной темы. Интересуют мысли по поводу модулей и ком-контента.

За темой слежу, постоянно сюда заглядываю

Почти все указанные предложения уже были ранее озвучены, причем помногу раз. Но суть не в этом, сейчас не могу 100% сказать что то или иное предложение будет реализовано, это как-то не совсем честно обещать то в чем не уверен.
Вообще "улучшать" и "расширять" ком-контент - самая маловероятная задача, этого монстра надо вообще полностью выпиливать и забывать как страшный сон.

Дальнейшие фишки, плюшки и интересные решения можно сделать только если очень хорошо расширить внутреннее ядро. А если расширять ядро - то тогда уже делать сразу нормальный SEF, который вообще по взрослому стоит называть роутингом. Дальнейшее развитие Joostina возможно, и на мой взгляд лучше если оно будет без оглядки на 1.5 и перегонялок с 1.6. Но эволюционное развитие заведёт в тупик, тут и неудобный SEF, и многословность конструкций, и тонны устаревшего кода, оставшегося еще со времён Mambo.
Если развивать систему в правильном направлении - чего то придётся лишиться, от чего-то избавиться и получить новые несовместимости со старыми расширениями, а говорить про это вслух уже побаиваюсь...

Добавлять все предложенные возможности в текущую ( 1.3.0.* ) версию конечно можно, это даст какие-то плюсы, возможно где-то добавит удобства или новые возможности для разработчиков. Но это так же может породить несовместимости, а в 1.3.0.* версии не стоит с этим баловаться, опасно.

Все предложения периодически прочитываю, есть хорошие и полезные, безусловно. Но внедрять их сразу, без указания реальной пользы - думаю не очень хорошо. Если уж и вносить правки - то они должны быть очень важные и полезными не только тому кто предложил, но хотя бы десяти пользователям.

Про ту же мультивложенность и многокатегорийность - навешивать такое на ком-контент - смертельно. С другой стороны есть JoiBOSS, которые это без особых проблем умеет.