Gallery: tab / закладка к каждой странице?
Возможно ли с Gallery в Revolution сделать так, как делается с EvoGallery в Evolution:
К каждой странице добавляется закладка EvoGallery, так что не надо ходить Модули --> EvoGallery --> [галерея на нужной странице]. А прямо при редактировании ресурса можно тут же зайти на вкладку EvoGallery и добавить или удалить (или еще что-то) картинки.
То есть, сейчас что-то в роде:
Document — Settings — Template Variables — Resource Groups
И что бы туда же добавился tab / закладка Gallery. Зайдя в который можно было бы добавлять и удалять картинки. А не ходить каждый раз: Extras --> Gallery --> некий Album. Когда страниц много, удобнее и нагляднее, чтобы картинки, относящиеся к конкретному ресурсу были тут же под рукой во вкладке этого самого конкретного ресурса.
Из rtfm.modx.com описание по EvoGallery ( rtfm.modx.com/extras/evo/evogallery ):
Since EvoGallery 1.1 in the distribution is an optional widget for the ManagerManager plugin that allows you to create a tab within document editing page
К каждой странице добавляется закладка EvoGallery, так что не надо ходить Модули --> EvoGallery --> [галерея на нужной странице]. А прямо при редактировании ресурса можно тут же зайти на вкладку EvoGallery и добавить или удалить (или еще что-то) картинки.
То есть, сейчас что-то в роде:
Document — Settings — Template Variables — Resource Groups
И что бы туда же добавился tab / закладка Gallery. Зайдя в который можно было бы добавлять и удалять картинки. А не ходить каждый раз: Extras --> Gallery --> некий Album. Когда страниц много, удобнее и нагляднее, чтобы картинки, относящиеся к конкретному ресурсу были тут же под рукой во вкладке этого самого конкретного ресурса.
Из rtfm.modx.com описание по EvoGallery ( rtfm.modx.com/extras/evo/evogallery ):
Since EvoGallery 1.1 in the distribution is an optional widget for the ManagerManager plugin that allows you to create a tab within document editing page
mm_widget_evogallery($moduleid, $title, $roles, $templates);- $moduleid is a custom variable specific to this function. It tells the function what module ID to use. To find out the ID of a module, simply copy the link to the module in the main menu. The ID will be part of the URL itself. E.g.: /manager/index.php?a=112&id=2. In this case, the $moduleid is 2.
- $title is display name of tab.
- $roles should be replaced with the IDs of the roles that should be affected or left empty to apply the rule to all roles.
- $templates contains the IDs of templates to apply the rule to, or can be left empty to apply to all templates.
Комментарии: 31
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
По моему скромному мнению, он в разы круче Gallery.
file.modx.pro/files/2/8/4/284872861db92da13d0cd33c7ebfed27.png
— Поля при картинке: Имя файла, Название и Описание. А поля для Тэгов вообще нет или нет только в примере, с которого сделан скриншот?
Мне-то хотелось бы, чтобы в самой Gallery, где есть поле для тэгов, было еще одно поле: пригодилось бы для разных видов сортировки. А в ms2Gallery нет и поля для тэгов?
Дополнительные свойства файлов, насколько я помню, никто пока не просил.
— Допустим, нужно сортировать картинки по какой-то теме. То есть, пользователь выбирает отображать на странице только картинки с каким-то тегом: картинки с «Картинки 1» либо с «Картинки 2» либо с «Картинки 3».
— На странице в нескольких местах нужно вставить по галерее. Допустим, три разной галереи / группы изображений с разным списком картинок — и все на одной странице.
Как это сделать в случае с ms2Gallery без тэгов?
Мы обычно группируем картинки по ресурсам (типа альбомам) и выводим также. К ресурсу можно прикрутить что угодно через ТВ.
Если нужен будет поиск файлов, то можно использовать их имя и описание, чтобы фильтровать при выводе через сниппеты.
Если будут запросы сделать теги от покупателей ms2Gallery — буду делать. Но пока не было.
— Наследие EvoGallery. Тэги удобны. Есть как бы лишнее, дополнительное поле (Описание, Название нужны для своих прямых дел), его содержимое можно выводить куда хочешь. И конечных пользователей легко научить: нужно вам две разной галереи на одной странице, поставте разные теги у двух соответствующих групп картинок.
В случае тегов, боюсь, многие покупатели скажут «ну и нафига нам это лишнее, мозолящее глаз поле?».
Создай новую тему, предложи свои изменения. Если сообщество их дружно поддержит — возьму в работу, как будет время. Если скажут, что оно никому кроме тебя не надо — так тому и быть.
Правда оригинальный автор Gallery её давно уже забросил — последнее обновление от него было 05 октября 2013 года, после чего проект пришлось подбирать и поддерживать основной команде MODX.
Также можно посмотреть откуда в Gallery пришло первое обновление для работы в MODX 2.3, когда выяснилось, что она в нём не работает.
В общем, уговаривать тебя мне смысла нет. Нравится Gallery и есть желание прикручивать её к ресурсам каждый раз — на здоровье.
— Именно, не бросили. Ибо уже как бы неотъемлемая часть MODX.
>>>Не, ну с такой логикой конечно, использовать нужно только дополнения от modx.com и ни в коем случае ничьи другие. Ни pdoTools, ни miniShop2, ни Tickets, ни даже ShopKeeper. Только то, что есть здесь.<<<
— Интернет-магазин, это не база. Его можно какой угодно использовать. pdoTools уже под вопросом. Не потому, что pdoTools не в базовом списке, а потому, что пока неясно сколько их будут развивать. Приводил пример из Linux, с основными пакетами дело сразу или давно поставлено так, что процесс не привязан жестко к конкретной личности. Надоест личности, подключатся другие личности.
>>>В общем, уговаривать тебя мне смысла нет. Нравится Gallery и есть желание прикручивать её к ресурсам каждый раз — на здоровье.<<<
— Не особеннно нравится, в том-то и дело. В Evolution есть база более готовая к использованию для создания простых и средних сайтов. Сейчас нахожусь в процессе второй попытки перейти на Revolution и сталкиваюсь, что то одно не эдак, то другое не так. Про какие-то вещи даже и не пишу на форумах, ибо вроде как уже чуть ли не неудобно, такая мелочь. Однако непонятно зачем она есть или оставлена быть.
Вообще было такое дело, как HomeSite. Пользователи, дизайнеры и верстальщики, сообщали свои пожелания, а разработчики после обсуждения их учитывали. Создатель, разработчик знает со своей стороны, а дизайнер и верстальщик, которые каждый день пользуются софтом, со своей. Некоторые вещи для разработчика вообще не вопрос, а для дизайнера или верстальщика это серьзно. Могу даже привести пример как раз из Gallery — непонятная, бессмысленная мелочь, которая осложняет.
А если серьёзно, то все мои дополнения лежат в свободном доступе на GutHub: и платные, и бесплатные. Случись чего — любой может продолжить, если возникнет желание. Как и произошло с Gallery, в своё время.
Ну и то, что эти дополнения приносят мне деньги является какой-никакой гарантией, что я их не брошу. Ибо у нас в магазине, если что, для всех покупателей обязательная техподдержка от автора.
А какие стимулы у авторов бесплатных дополнений?
— Есть разные способы монетизации своих усилий. Например, могу, не уточняя имя, фамилию и прочее, сказать про одного разработчика open source: он устроился на хорошую работу в хорошем географически месте и аргументом в пользу него было то, что он сообщил, а будущие работодатели могли проверить, что он один из разработчиков довольно широко используемого компонента.
Это же не основная работа. Скорее даже наоборот, она может мешать основной.
P.S. Вместо стрелочек >>> и <<< у нас есть тег
Здесь только pdoTools, Tickets, Jevix, mSearch2 и т.д.
ilyaut.ru/reposts/the-management-of-the-album-gallery-page-resource/
Интересно, как это решение будет вести себя при обновлениях Revolution и конкретно Gallery.
конечно, при обновлении gallery плагин GalleryCustomTV перезапишется, правда обновляется он редко
Вообще, удивительно почему разработчики Gallery давно не имеют встроенной схемы по прикреплению закладки к каждому ресурсу. Без этого не преставляю как можно — самому-то ладно, а вот конечным пользователям, заказчикам — вообще пользовать той или иной галереей.
я же больше склоняюсь к использованию ms2Gallery
А что будет со скриптами, которые разработал одиночный разработчик? Не передумает ли он лет через пять развивать свой компонент? И что делать тогда? В Linux, к примеру, касаемо основных пакетов никто не беспокоится, уйдет текущий разработчик или коллектив, значит их сменит кто-то другой — популярную и нужную вещь не бросят.