Компонент «Полезность страниц» для ICMS 2

Неплохая вещь, но по сути дублирует функционал рейтинга материалов. Поправьте, если я неправ.
Что можно было бы добавить и улучшить:
1. Указать возможность подмены текста для разных типов контента "Оценить объявление", "Оценить товар" и т.д. (можно подхватывать переменную из настроек типа контента в соответствующем падеже)
2. При указании низкой оценки форму комментирования показать во всплывающем окне или же сделать якорную ссылку на комментарии. Даже я не сразу сообразил, что скрипт просит прокомментировать саму статью, а не свою оценку.
3. Пересмотреть возможность установки и настройки компонента без правок файлов сайта/шаблона. Я не кодер, но вроде как таковая возможность предусмотрена разработчиками в виде хуков.

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

Поправлю. Рейтинг это рейтинг. А тут речь совсем о другом. Я могу зайти на страницу с описанием свехкачественного, супердешевого и хорошо себя зарекомендовавшего себя товара, но не найти на ней ни внятного описания ни тех. характеристик ни фото. Хорош товар? Безусловно. Полезна страница - нет. Так что рейтинг тут ни при чем. Вы конечно и в качестве альтернативы рейтингу можете использовать компонент, но изначально его функция другая.

Я вас понял, просто сразу не особо вник в тему

И все же принцип одинаковый. В том же, мертворожденном голосовании за статью, которое имеем в Инстанте, мы оцениваем полезность статьи! И в чем разница???
Другое дело, что в данном компоненте сделан упор на информативность, но мне было бы интересно видеть обе оценки, если они есть.

Вы имеете в виду какие "обе оценки"? И полезность и рейтинг? Они и так между собой никак не связаны, используйте одновременно.

Можете считать этот компонент заменой банальному

Александр + отлично.Только при наведении на прогрессбар показывайте % полезности, а то не видно при наведении на него, получается рулетка.

Спасибо, учтемс ...

Большая просьба к разработчику: указывайте пожалуйста, если ваш компонент имеет привязку к домену или исходный код закрыт

Это да...

Спасибо, учтемс и это. Код данного компонента открыт и не имеет никаких привязок.

Чего не скажешь о компоненте вкладки. Удивился когда для работы потребовался ioncube loader. Желательно указать это в описании компонента. Иначе кто то из ваших покупателей попросту не сможет пользоваться компонентом.

Можно обойтись без ручной вставки константы языка в файл констант. И тем более не выгодно её вставлять в стандартный файл, который слетит при обновлении. Проще сделать свои файлы констант (grades.php) для каждого языка и разместить их в system\languages\ru и \system\languages\ru - они подгрузятся оттуда автоматом на любой странице.

и еще где разместить?))))

Если б константа нужна была для работы компонента она б и бралась из файла system/languages/ru/controllers/grades/grades.php, но если бы вы были более внимательны, то обратили бы внимание, где именно выводится данная константа. Лично у меня движок при редактировании типов контента отказывается брать константы с языкового файла компонента. Поделитесь секретом как это получается у вас?

в system\languages\en и \system\languages\ru - забыл исправить

Вы знаете, это не только у Вас. Языковые файлы компонентов загружаются автоматом только на страницах этих компонентов. Во всех остальных местах их нужно подгружать вставкой строки кода в нужном месте (хаком) или обработкой хука, что не всегда удобно. Или, как я предложил, положить свой языковой файл с любым_именем.php в корень (ru, en) папок языков. Все языковые файлы из корневой папки загружаются при отображении любой страницы.

Вам же объяснили - кидаете файл grades.php с нужными для работы вне компонента константами в папку \system\languages\ru и радуетесь возможностям двойки. Единственное надо проследить, чтобы при работе самого компонента эти константы не задвоились (они не должны повторяться по названию, а по переводу могут).

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

Тогда просто спросите ваших покупателей, что они выберут:
1. Дополнительное увеличение времени работы скрипта с 50 миллисекунд до 50,1 мс (0,1 мс на загрузку дополнительного файла - это реальные цифры, которые Вы можете увидеть в "Расширенной отладке" на нормальном современном сервере с SSD) и при этом отсутствие необходимости править руками какие-то файлы при установке компонента и каждом обновлении + возможность обновлять ядро без риска забыть внести эти правки.
2. Экономия этой "королевской" 0,1 мс и лишняя работа руками и головой каждый раз + риск забыть что-то внести при обновлении + морока найти существующие константы этого компонента в файле, в котором их быть не должно и о котором забыл, при обновлении самого компонента, чтобы свериться, какие константы уже есть, какие нужно добавить, а какие изменить на другие значения.

Вот голосование просто ради интереса:

+ кто из прочитавших этот камент за вариант 1 (за экономию своего труда и за надёжность ценой увеличения времени страницы на 0,1 мс) - поставьте плюс,
- кто за вариант 2 (за экономию 0,1 мс и за свою дополнительную работу и риск что-то испортить при каждом обновлении движка или компонента) - поставьте минус.

Как страшно, рискую своим рейтингом.
От меня сразу виртуальный +1, пусть за меня комп всё делает, его для этого и создавали. Жаль, в своём каменте поставить оценку нельзя.

Я же сказал, я не хочу вступать в полемику по данному вопросу. Я предложил тот способ, который считаю наиболее оптимальным.
Если уж на то пошло, можно и вовсе обойтись без всяких правок. Чем не вариант? Да, вариант №3. Вы как один раз настроите права так больше и не загляните никогда в них.)))))) И это вместо того, чтобы грузить ваш файл при каждой загрузке страницы. Одного трафика на сайте с приличной посещаемостью набежит 100Мб+)))))
Не вводите людей в заблуждение. Если у вас получится что-то сломать забыв разместить константу я вам лично поставлю памятник при жизни.

Можно и без правок, просто вписать русский текст в код или выводить имя константы, как на видео. Для себя можно, но не на продажу. Хотя я бы и для себя этот вариант не использовал просто из уважения к себе.
Если под "трафиком" Вы подразумеваете многократную загрузку текста файла с диска, то в Вашем первоначальном варианте всё равно загружается этот же объём, просто не из отдельного файла, а из общего языкового файла, в который Вы добавили код константы. Если про другой "трафик", то я не понял, поясните.
Сломать весь движок (получить фатальную ошибку уровня компиляции) можно просто не поставив один знак или поставив лишний при вставке константы в языковой файл. Это особенно возможно для пользователей, не знающих ПХП и делающих вставку в простом "Блокноте" без подсветки синтаксиса и его ошибок. Да и я сам, имея немалый опыт в программировании и хорошие редакторы кода, иногда делал подобные ошибки/опечатки и получал неработающий скрипт с соответствующим поиском этой ошибки.

Речь не об этом. А о том, что кодом по возможности максимально должен заниматься программист. И желательно избавлять пользователей от любых действий с редактированием кода, если это возможно и не несёт за собой серьёзных затрат ресурсов. ИМХО.
У Вас интересный компонент, dwd, Вы проделали хорошую работу. Исходя из всего этого я и предложил Вам вариант, упрощающий Вашим покупателям установку Вашего продукта. Вы можете иметь иной взгляд и предлагать пользователям свой вариант с ручной правкой - имеете право. Какой вариант предпочтительней для основной массы пользователей - оценить могут лишь они. Хотя уже в первом же комментарии AndroS в пункте 3 дал Вам чёткий ответ про выбор пользователей.

Абсолютно с вами согласен. По поводу удобства для пользователей вы меня убедили, пожалуй это действительно так. Но вот версия Инстанта скоро упрется в 3.0, а ввиду отсутствия в коробке хоть какого-нибудь компонента управления правами доступа мы с вами до сих пор добавляем правила доступа SQL-запросами и рассуждаем на тему куда втыкать константы этих самых правил. Это равносильно рассуждениям на тему какой костыль лучше - деревянный или аллюминиевый.))))))

Честно говоря, не понял Вашей мысли про неудобство добавления правил. Вроде так и должно быть: разработчик запросами и/или скриптами добавляет нужный функционал при установке своего компонента.
Если Вам есть что предложить, создайте отдельную тему на форуме с пояснением. С интересом прочитаю.

Я о том, что не мешало бы в таблицу perms_rules добавить парочку столбцов - title и options и сделать простой компонент, позволяющий любому пользователю добавлять собственные правила. Это сделает систему гораздо гибче. Я даже не буду приводить в пример тот же древний VBulletin, где кастомизация настолько шикарна, что для каждого раздела можно настроить десятки правил. Любой пользователь сможет открыть компонент, ввести название правила, тип контента, и другие опции(например, категорию в которой оно будет действовать) и нажав кнопочку сохранить получить желаемое.

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

Очевидно для мультиязычности интрефейса.
А обрабатывать правила кто будет?

Правила доступа это прерогатива разработчика компонента, а не администратора сайта. Администратор лишь настраивает правила. Мне кажется вы вводите окружающих в заблуждение или неверно доносите свою мысль.
Это не гибкое управление правами доступа?
А рассуждать как делать правила не нужно, есть документация. А если вы делаете дополнение, при разработке которого нужно править файлы движка - это явная ошибка подхода к разработке. Но даже при этом, как уже выше отметили, ничто не мешает положить свой lang файл в директорию /system/languages/ru/controllers/content/you_file.php в вашем случае и проблем нет. Или вы хотите сэкономить на спичках? Подключаемые файлы и проверки при подключении кэшируются php, а в последних версиях кешируется в бинарник, поэтому мне категорически непонятно в чём собственно проблема.
Делать дополнение, которое правит кучу файлов движка - это неверно. Не хватает хуков - всегда можно написать нам на гитхабе или тут на форуме поднять тему о нехватке хуков, где обсудить где и что не мешало бы добавить.

Все что я напишу ниже более чем реально и при этом не трудозатратно. Не примите это как камень в ваш огород, но я считаю что система такого уровня должна обладать гораздо большими возможностями и гибкостью настройки прав. Я рад что вы прочли прошлое сообщение и буду рад если вы прочтете это. И еще больше буду рад если прислушаетесь. Возможно даже форма в которой это будет реализована будет отличаться от той, которую я сейчас предложу.
Вариант en => Title, ru => Заголовок преобразованные в Yaml не подходят? Вам виднее, я только предложил. Да и воообще хранение констант в БД и их удобное редактирование в админке на мой взгляд в разы удобнее. Больше сотни языковых файлов превращаются в 1 таблицу, мультиязычность реализуется одним $model->filterEqual('lang', $lang) и пользователи получают полный контроль над константами/языками.
Вот в этом моменте абсолютно с вами не согласен о чем напишу ниже.
Нет, это пародия. Простейший пример: имеем 2 категории в типе контента. Надо разрешить оценку/просмотр записей только для одной из двух и запретить для другой. Как? А ведь это вопрос админа.
Я никого не ввожу в заблуждение. Существуют настройки типов контента, компонентов по умолчанию. Существуют их обработчики. Со временем добавите новые. А для начала не надо ничего глобально дописывать/переделывать. просто дайте пользователям возможность переопределять данные правила в зависимости от ряда условий. Как в примере выше(про категории). А еще я хочу показывать наборы(datasets) одной группе пользователей и не показывать другой, разрешать поиск только в определенных категориях сайта и т.д. И таких примеров привести можно миллион. Вот тогда это будет поистине гибкое управление правами доступа. На данный момент оно является удовлетворительным и позволяет решить большинство задач. Но гибкости в нем нет.

Я не претендую на истину первой инстанции, а просто высказываю свое мнение. Вам решать как и в какую сторону развивать систему.

Ну и чисто для справки:
Поверьте, я много чего написал под вторую ветку и для себя и для знакомых и по личным просьбам в ЛС на вашем сайте. И у меня нет ни одной разработки кроме компонента "Языки", которая бы затрагивала файлы движка.

Дак какой разговор. У нас есть форум, есть пожелания/пулреквесты на гитхабе. Можно же все неудобства обсудить, более того, многие именно так и делают. Но для этого как минимум нужно, чтобы кто-то поднял тему (ибо вы сами разработчик и знаете, что с телепатией нынче туго) и предложил варианты реализации. Я случайно прочел комментарии к вашему компоненту, было много букв и стало интересно, о чём речь) А мог бы и не прочесть и ваш посыл в очередной раз канул бы известно куда.
Вы писали про то, что нужно добавлять правила, а не гибко их обрабатывать. Насчет гибкости обработки, с учетом назначения действия правил, никто не спорит, что это было бы неплохо. Но это никак не вяжется с созданием самого правила в админке. Оно, правило, по прежнему должно создаваться разработчиком, а вот на что его действие распространяется (некая наследственность), это уже другой вопрос.
Так что мешало предложить добавить новые хуки?

Всё решаемо, если обсуждается адресно, а спорные моменты выносятся сообществу.

Я у вас человек новый, еще толком не освоился, но со временем доберусь и до форума и до гитхаба.))))
Вот то, что я писал, то же самое пишу еще раз. Я за возможность именно создавать правила. По умолчанию мы имеем набор родительских правил, которые работают во всем типе контента. Я предлагаю ввести возможность создавать правила, работающие только при выполнении определенных условий. К примеру мы для категории с ID=5 создаем правило запрещающее оценку статей в данной категории. Данное правило использует те же обработчики, что и глобальные правила, но работает исключительно в данной категории. В случае отсутствия правил для данной категории срабатывают глобальные правила типа контента. Как-то так.
Во-первых там не только в хуках дело, многие моменты и хуками не исправишь. Во вторых это все время, а его у меня не было. Пока я предложу, пока вы обмозгуете, пока выйдет релиз и т.д. А магазин с полной мультиязычностью человеку нужен "вчера".

Так правила то создавать получается из текущих. Т.е. получается то, что я и написал: некий механизм переопределения существующих правил. Не получится просто так создать в админке правило, скажем "Скрывать рекламу в типе контента", если функционала рекламы нет вовсе.
А вот изменять субъект действия правил в дочерних к компоненту разделах/экшенах - это уже другой вопрос.

Мы с вами как-то же здесь общаемся

Ну так я про это и не говорю. Я говорю про то, что надо создать механизм управления существующими правилами. Чтобы на базе существующих в системе/компоненте правил пользователь мог создавать свои. Я ж выше так и писал:
"Существуют их обработчики. Со временем добавите новые. А для начала не надо ничего глобально дописывать/переделывать. просто дайте пользователям возможность переопределять данные правила в зависимости от ряда условий.".
При создании типа контента или разработчиком стороннего компонента изначально создается базовый набор правил. А гибкость заключается в возможности их дифференциального использования в разных участках типа контента/компонента. В этой категории хочу, в этой не хочу. Общий ход моей мысли вижу вы уже поняли.

Кажется, я начинаю понимать ваше предожение... Вот есть уже связи типов контента, и нужен еще функционал "Логические связи полей". К примеру, это может быть просто визуально невидимое поле в типе контента, которое позволяло бы заполнять другие поля в зависимости от значений/их диапазонов (соответствий определенным условиям)других полей.
Пример:
Тип контента - товар:
Создаем логическое поле - "Если поле (выбираем из имеющихся в типе контента, например, вес) < или равно 1, то поле Доставка равно 0"
Примеров может быть множество и в самых различных интерпретациях, тема очень интересная!...
А к самим полям не хватает в настройках возможности редактировать доступ к редактированию полей, пока есть только доступ к чтению. Иногда бывает нужно, чтобы юзер мог добавить какой-то материал, но не мог изменить одно конкретное поле при редактировании, например, ссылку источника материала или дату или еще что-то

В системе есть такая возможность. При создании поля вы можете указать какие группы пользователей будут видеть его при добавлении/редактировании записи:

Упс, и правда, почему-то не разглядел! А ведь проверял перед отправкой сообщения этот факт!