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

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

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

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

Обзор возможностей компонента и информацию по установке вы найдете в данном видео-обзоре:

Пример работы компонента можно посмотреть на сайте codeplace.ru, а скриншоты вы найдете на странице компонента в каталоге дополнений.
Парсер контента для ICMS 2 - Обновление 1.3 | Пакет расширения для компонента «Парсер контента»
Комментарии (33)
AndroS 16 января 2017 в 08:31 +3
Неплохая вещь, но по сути дублирует функционал рейтинга материалов. Поправьте, если я неправ.
Что можно было бы добавить и улучшить:
1. Указать возможность подмены текста для разных типов контента "Оценить объявление", "Оценить товар" и т.д. (можно подхватывать переменную из настроек типа контента в соответствующем падеже)
2. При указании низкой оценки форму комментирования показать во всплывающем окне или же сделать якорную ссылку на комментарии. Даже я не сразу сообразил, что скрипт просит прокомментировать саму статью, а не свою оценку.
3. Пересмотреть возможность установки и настройки компонента без правок файлов сайта/шаблона. Я не кодер, но вроде как таковая возможность предусмотрена разработчиками в виде хуков.
AndroS 16 января 2017 в 08:32 +2
Да, еще забыл в качестве первого пункта указать - нужна поддержка микроразметки, дабы рейтинг статьи отображался в поисковых сниппетах.
dwd 16 января 2017 в 08:49 +1
Поправлю. Рейтинг это рейтинг. А тут речь совсем о другом. Я могу зайти на страницу с описанием свехкачественного, супердешевого и хорошо себя зарекомендовавшего себя товара, но не найти на ней ни внятного описания ни тех. характеристик ни фото. Хорош товар? Безусловно. Полезна страница - нет. Так что рейтинг тут ни при чем. Вы конечно и в качестве альтернативы рейтингу можете использовать компонент, но изначально его функция другая.
AndroS 16 января 2017 в 09:23 0
Я вас понял, просто сразу не особо вник в тему
vikont 16 января 2017 в 12:01 0
И все же принцип одинаковый. В том же, мертворожденном голосовании за статью, которое имеем в Инстанте, мы оцениваем полезность статьи! И в чем разница???
Другое дело, что в данном компоненте сделан упор на информативность, но мне было бы интересно видеть обе оценки, если они есть.
dwd 16 января 2017 в 13:19 0
Вы имеете в виду какие "обе оценки"? И полезность и рейтинг? Они и так между собой никак не связаны, используйте одновременно.
dwd 16 января 2017 в 08:51 +1
Можете считать этот компонент заменой банальному
Алексей Тимофеев 16 января 2017 в 09:04 +1
Александр + отлично.Только при наведении на прогрессбар показывайте % полезности, а то не видно при наведении на него, получается рулетка.
dwd 16 января 2017 в 09:31 +2
Спасибо, учтемс ...
Kreator 16 января 2017 в 09:43 +2
Большая просьба к разработчику: указывайте пожалуйста, если ваш компонент имеет привязку к домену или исходный код закрыт
Алексей Тимофеев 16 января 2017 в 10:41 0
Это да...
dwd 16 января 2017 в 13:16 +1
Спасибо, учтемс и это. Код данного компонента открыт и не имеет никаких привязок.
Kreator 16 января 2017 в 19:12 0
Чего не скажешь о компоненте вкладки. Удивился когда для работы потребовался ioncube loader. Желательно указать это в описании компонента. Иначе кто то из ваших покупателей попросту не сможет пользоваться компонентом.
WebMan 16 января 2017 в 21:18 +1
Можно обойтись без ручной вставки константы языка в файл констант. И тем более не выгодно её вставлять в стандартный файл, который слетит при обновлении. Проще сделать свои файлы констант (grades.php) для каждого языка и разместить их в system\languages\ru и \system\languages\ru - они подгрузятся оттуда автоматом на любой странице.
dwd 16 января 2017 в 21:28 0
и разместить их в system\languages\ru и \system\languages\ru
и еще где разместить?))))

Если б константа нужна была для работы компонента она б и бралась из файла system/languages/ru/controllers/grades/grades.php, но если бы вы были более внимательны, то обратили бы внимание, где именно выводится данная константа. Лично у меня движок при редактировании типов контента отказывается брать константы с языкового файла компонента. Поделитесь секретом как это получается у вас?
WebMan 16 января 2017 в 21:53 0
в system\languages\en и \system\languages\ru - забыл исправить smile

dwd:
Лично у меня движок при редактировании типов контента отказывается брать константы с языкового файла компонента.
Вы знаете, это не только у Вас. smile Языковые файлы компонентов загружаются автоматом только на страницах этих компонентов. Во всех остальных местах их нужно подгружать вставкой строки кода в нужном месте (хаком) или обработкой хука, что не всегда удобно. Или, как я предложил, положить свой языковой файл с любым_именем.php в корень (ru, en) папок языков. Все языковые файлы из корневой папки загружаются при отображении любой страницы.
Loadырь 16 января 2017 в 21:53 0
dwd:
Поделитесь секретом как это получается у вас?
Вам же объяснили - кидаете файл grades.php с нужными для работы вне компонента константами в папку \system\languages\ru и радуетесь возможностям двойки. Единственное надо проследить, чтобы при работе самого компонента эти константы не задвоились (они не должны повторяться по названию, а по переводу могут).
dwd 16 января 2017 в 22:53 0
Языковые файлы компонентов загружаются автоматом только на страницах этих компонентов.
Именно об этом я собственно и писал.
Вам же объяснили - кидаете файл grades.php с нужными для работы вне компонента константами в папку \system\languages\ru
Плюс один подключаемый файл из-за одной константы это поистине королевская щедрость. Не хочу вдаваться в полемику по данному вопросу, но у себя на сайте я б этого не делал.
WebMan 16 января 2017 в 23:49 +7
Тогда просто спросите ваших покупателей, что они выберут:
1. Дополнительное увеличение времени работы скрипта с 50 миллисекунд до 50,1 мс (0,1 мс на загрузку дополнительного файла - это реальные цифры, которые Вы можете увидеть в "Расширенной отладке" на нормальном современном сервере с SSD) и при этом отсутствие необходимости править руками какие-то файлы при установке компонента и каждом обновлении + возможность обновлять ядро без риска забыть внести эти правки.
2. Экономия этой "королевской" 0,1 мс и лишняя работа руками и головой каждый раз + риск забыть что-то внести при обновлении + морока найти существующие константы этого компонента в файле, в котором их быть не должно и о котором забыл, при обновлении самого компонента, чтобы свериться, какие константы уже есть, какие нужно добавить, а какие изменить на другие значения.

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

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

Как страшно, рискую своим рейтингом. laugh
От меня сразу виртуальный +1, пусть за меня комп всё делает, его для этого и создавали. Жаль, в своём каменте поставить оценку нельзя. joke
dwd 17 января 2017 в 00:00 0
Я же сказал, я не хочу вступать в полемику по данному вопросу. Я предложил тот способ, который считаю наиболее оптимальным.
при этом отсутствие необходимости править руками какие-то файлы при установке компонента и каждом обновлении + возможность обновлять ядро без риска забыть внести эти правки.
Если уж на то пошло, можно и вовсе обойтись без всяких правок. Чем не вариант? Да, вариант №3. Вы как один раз настроите права так больше и не загляните никогда в них.)))))) И это вместо того, чтобы грузить ваш файл при каждой загрузке страницы. Одного трафика на сайте с приличной посещаемостью набежит 100Мб+)))))
- кто за вариант 2 (за экономию 0,1 мс и за свою дополнительную работу и риск что-то испортить при каждом обновлении движка или компонента) - поставьте минус.
Не вводите людей в заблуждение. Если у вас получится что-то сломать забыв разместить константу я вам лично поставлю памятник при жизни.
WebMan 17 января 2017 в 00:38 0
Можно и без правок, просто вписать русский текст в код или выводить имя константы, как на видео. Для себя можно, но не на продажу. Хотя я бы и для себя этот вариант не использовал просто из уважения к себе.
Одного трафика на сайте с приличной посещаемостью набежит 100Мб+
Если под "трафиком" Вы подразумеваете многократную загрузку текста файла с диска, то в Вашем первоначальном варианте всё равно загружается этот же объём, просто не из отдельного файла, а из общего языкового файла, в который Вы добавили код константы. Если про другой "трафик", то я не понял, поясните.
Если у вас получится что-то сломать забыв разместить константу я вам лично поставлю памятник при жизни.
Сломать весь движок (получить фатальную ошибку уровня компиляции) можно просто не поставив один знак или поставив лишний при вставке константы в языковой файл. Это особенно возможно для пользователей, не знающих ПХП и делающих вставку в простом "Блокноте" без подсветки синтаксиса и его ошибок. Да и я сам, имея немалый опыт в программировании и хорошие редакторы кода, иногда делал подобные ошибки/опечатки и получал неработающий скрипт с соответствующим поиском этой ошибки.

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

Абсолютно с вами согласен. По поводу удобства для пользователей вы меня убедили, пожалуй это действительно так. Но вот версия Инстанта скоро упрется в 3.0, а ввиду отсутствия в коробке хоть какого-нибудь компонента управления правами доступа мы с вами до сих пор добавляем правила доступа SQL-запросами и рассуждаем на тему куда втыкать константы этих самых правил. Это равносильно рассуждениям на тему какой костыль лучше - деревянный или аллюминиевый.))))))
WebMan 17 января 2017 в 11:02 0
Честно говоря, не понял Вашей мысли про неудобство добавления правил. Вроде так и должно быть: разработчик запросами и/или скриптами добавляет нужный функционал при установке своего компонента.
Если Вам есть что предложить, создайте отдельную тему на форуме с пояснением. С интересом прочитаю.
dwd 17 января 2017 в 11:49 +1
Я о том, что не мешало бы в таблицу perms_rules добавить парочку столбцов - title и options и сделать простой компонент, позволяющий любому пользователю добавлять собственные правила. Это сделает систему гораздо гибче. Я даже не буду приводить в пример тот же древний VBulletin, где кастомизация настолько шикарна, что для каждого раздела можно настроить десятки правил. Любой пользователь сможет открыть компонент, ввести название правила, тип контента, и другие опции(например, категорию в которой оно будет действовать) и нажав кнопочку сохранить получить желаемое.

Если ну аж очень совсем ни разу такие возможности инстанту не нужны(возможно это я один такой извращенец) то стоит добавить просто поле title. Да, разработчики все также будут добавлять нужный функционал при установке своего компонента, но вопросы про то, куда куда вставлять константы отпадут сами собой. Все будет культурно храниться в одной табличке - и правила и их названия. Если честно не совсем понимаю что заставило разработчиков системы хранить названия правил в виде констант.
Fuze 17 января 2017 в 13:03 0
Если честно не совсем понимаю что заставило разработчиков системы хранить названия правил в виде констант.
Очевидно для мультиязычности интрефейса.
позволяющий любому пользователю добавлять собственные правил
А обрабатывать правила кто будет?

а ввиду отсутствия в коробке хоть какого-нибудь компонента управления правами доступа мы с вами до сих пор добавляем правила доступа SQL-запросами и рассуждаем на тему куда втыкать константы этих самых правил.
Правила доступа это прерогатива разработчика компонента, а не администратора сайта. Администратор лишь настраивает правила. Мне кажется вы вводите окружающих в заблуждение или неверно доносите свою мысль.
Это не гибкое управление правами доступа?
А рассуждать как делать правила не нужно, есть документация. А если вы делаете дополнение, при разработке которого нужно править файлы движка - это явная ошибка подхода к разработке. Но даже при этом, как уже выше отметили, ничто не мешает положить свой lang файл в директорию /system/languages/ru/controllers/content/you_file.php в вашем случае и проблем нет. Или вы хотите сэкономить на спичках? Подключаемые файлы и проверки при подключении кэшируются php, а в последних версиях кешируется в бинарник, поэтому мне категорически непонятно в чём собственно проблема.
Делать дополнение, которое правит кучу файлов движка - это неверно. Не хватает хуков - всегда можно написать нам на гитхабе или тут на форуме поднять тему о нехватке хуков, где обсудить где и что не мешало бы добавить.
dwd 17 января 2017 в 14:22 +1
Все что я напишу ниже более чем реально и при этом не трудозатратно. Не примите это как камень в ваш огород, но я считаю что система такого уровня должна обладать гораздо большими возможностями и гибкостью настройки прав. Я рад что вы прочли прошлое сообщение и буду рад если вы прочтете это. И еще больше буду рад если прислушаетесь. Возможно даже форма в которой это будет реализована будет отличаться от той, которую я сейчас предложу.
Очевидно для мультиязычности интрефейса.
Вариант en => Title, ru => Заголовок преобразованные в Yaml не подходят? Вам виднее, я только предложил. Да и воообще хранение констант в БД и их удобное редактирование в админке на мой взгляд в разы удобнее. Больше сотни языковых файлов превращаются в 1 таблицу, мультиязычность реализуется одним $model->filterEqual('lang', $lang) и пользователи получают полный контроль над константами/языками.
Правила доступа это прерогатива разработчика компонента, а не администратора сайта.
Вот в этом моменте абсолютно с вами не согласен о чем напишу ниже.
Это не гибкое управление правами доступа?
Нет, это пародия. Простейший пример: имеем 2 категории в типе контента. Надо разрешить оценку/просмотр записей только для одной из двух и запретить для другой. Как? А ведь это вопрос админа.
Администратор лишь настраивает правила. Мне кажется вы вводите окружающих в заблуждение или неверно доносите свою мысль.
Я никого не ввожу в заблуждение. Существуют настройки типов контента, компонентов по умолчанию. Существуют их обработчики. Со временем добавите новые. А для начала не надо ничего глобально дописывать/переделывать. просто дайте пользователям возможность переопределять данные правила в зависимости от ряда условий. Как в примере выше(про категории). А еще я хочу показывать наборы(datasets) одной группе пользователей и не показывать другой, разрешать поиск только в определенных категориях сайта и т.д. И таких примеров привести можно миллион. Вот тогда это будет поистине гибкое управление правами доступа. На данный момент оно является удовлетворительным и позволяет решить большинство задач. Но гибкости в нем нет.

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

Ну и чисто для справки:
А если вы делаете дополнение, при разработке которого нужно править файлы движка - это явная ошибка подхода к разработке.
Поверьте, я много чего написал под вторую ветку и для себя и для знакомых и по личным просьбам в ЛС на вашем сайте. И у меня нет ни одной разработки кроме компонента "Языки", которая бы затрагивала файлы движка.
Fuze 17 января 2017 в 16:20 0
Дак какой разговор. У нас есть форум, есть пожелания/пулреквесты на гитхабе. Можно же все неудобства обсудить, более того, многие именно так и делают. Но для этого как минимум нужно, чтобы кто-то поднял тему (ибо вы сами разработчик и знаете, что с телепатией нынче туго) и предложил варианты реализации. Я случайно прочел комментарии к вашему компоненту, было много букв и стало интересно, о чём речь) А мог бы и не прочесть и ваш посыл в очередной раз канул бы известно куда.
Нет, это пародия. Простейший пример: имеем 2 категории в типе контента. Надо разрешить оценку/просмотр записей только для одной из двух и запретить для другой. Как? А ведь это вопрос админа.
Вы писали про то, что нужно добавлять правила, а не гибко их обрабатывать. Насчет гибкости обработки, с учетом назначения действия правил, никто не спорит, что это было бы неплохо. Но это никак не вяжется с созданием самого правила в админке. Оно, правило, по прежнему должно создаваться разработчиком, а вот на что его действие распространяется (некая наследственность), это уже другой вопрос.
И у меня нет ни одной разработки кроме компонента "Языки", которая бы затрагивала файлы движка.
Так что мешало предложить добавить новые хуки?

Всё решаемо, если обсуждается адресно, а спорные моменты выносятся сообществу.
dwd 17 января 2017 в 17:02 0
У нас есть форум, есть пожелания/пулреквесты на гитхабе. Можно же все неудобства обсудить, более того, многие именно так и делают. Но для этого как минимум нужно, чтобы кто-то поднял тему
Я у вас человек новый, еще толком не освоился, но со временем доберусь и до форума и до гитхаба.))))
Вы писали про то, что нужно добавлять правила, а не гибко их обрабатывать.
Вот то, что я писал, то же самое пишу еще раз. Я за возможность именно создавать правила. По умолчанию мы имеем набор родительских правил, которые работают во всем типе контента. Я предлагаю ввести возможность создавать правила, работающие только при выполнении определенных условий. К примеру мы для категории с ID=5 создаем правило запрещающее оценку статей в данной категории. Данное правило использует те же обработчики, что и глобальные правила, но работает исключительно в данной категории. В случае отсутствия правил для данной категории срабатывают глобальные правила типа контента. Как-то так.
Так что мешало предложить добавить новые хуки?
Во-первых там не только в хуках дело, многие моменты и хуками не исправишь. Во вторых это все время, а его у меня не было. Пока я предложу, пока вы обмозгуете, пока выйдет релиз и т.д. А магазин с полной мультиязычностью человеку нужен "вчера".
Fuze 17 января 2017 в 17:11 0
Я за возможность именно создавать правила. По умолчанию мы имеем набор родительских правил, которые работают во всем типе контента. Я предлагаю ввести возможность создавать правила, работающие только при выполнении определенных условий.
Так правила то создавать получается из текущих. Т.е. получается то, что я и написал: некий механизм переопределения существующих правил. Не получится просто так создать в админке правило, скажем "Скрывать рекламу в типе контента", если функционала рекламы нет вовсе.
А вот изменять субъект действия правил в дочерних к компоненту разделах/экшенах - это уже другой вопрос.

Во вторых это все время, а его у меня не было.
Мы с вами как-то же здесь общаемся smile
dwd 17 января 2017 в 17:24 0
Не получится просто так создать в админке правило, скажем "Скрывать рекламу в типе контента", если функционала рекламы нет вовсе.
Ну так я про это и не говорю. Я говорю про то, что надо создать механизм управления существующими правилами. Чтобы на базе существующих в системе/компоненте правил пользователь мог создавать свои. Я ж выше так и писал:
"Существуют их обработчики. Со временем добавите новые. А для начала не надо ничего глобально дописывать/переделывать. просто дайте пользователям возможность переопределять данные правила в зависимости от ряда условий.".
При создании типа контента или разработчиком стороннего компонента изначально создается базовый набор правил. А гибкость заключается в возможности их дифференциального использования в разных участках типа контента/компонента. В этой категории хочу, в этой не хочу. Общий ход моей мысли вижу вы уже поняли.
AndroS 18 января 2017 в 07:35 0
Кажется, я начинаю понимать ваше предожение... Вот есть уже связи типов контента, и нужен еще функционал "Логические связи полей". К примеру, это может быть просто визуально невидимое поле в типе контента, которое позволяло бы заполнять другие поля в зависимости от значений/их диапазонов (соответствий определенным условиям)других полей.
Пример:
Тип контента - товар:
Создаем логическое поле - "Если поле (выбираем из имеющихся в типе контента, например, вес) < или равно 1, то поле Доставка равно 0"
Примеров может быть множество и в самых различных интерпретациях, тема очень интересная!...
А к самим полям не хватает в настройках возможности редактировать доступ к редактированию полей, пока есть только доступ к чтению. Иногда бывает нужно, чтобы юзер мог добавить какой-то материал, но не мог изменить одно конкретное поле при редактировании, например, ссылку источника материала или дату или еще что-то
dwd 18 января 2017 в 20:03 0
А к самим полям не хватает в настройках возможности редактировать доступ к редактированию полей, пока есть только доступ к чтению.
В системе есть такая возможность. При создании поля вы можете указать какие группы пользователей будут видеть его при добавлении/редактировании записи:
AndroS 19 января 2017 в 04:03 0
Упс, и правда, почему-то не разглядел! А ведь проверял перед отправкой сообщения этот факт!