Тэги к тикетам
Хотелось бы почитать, что предложит многоуважаемое сообщество, а в конце обсуждения я напишу свои «хотелки». Всем спасибо.
Заранее благодарен за участие.
Заранее благодарен за участие.
Комментарии: 49
Не обижайтесь, но по-моему, уже начиная с кармы и заканчивая тэгами, страницами пользователя и прочими наворотами уводит дополнение все дальше от того, чем оно, на мой взгляд, изначально задумывалось — легким и минимальным набором инструментов, которое можно по-желанию допилить до чего угодно без особых проблем.
Тэги для любой страницы, а не только тикетсов в Modx'e реализуется посредством добавления 1 tv специально предусмотренного в Modx'e вида, 1 сниппета для преобразования результатов и одной страницы для поиска ресурсов по ним.
Страница профиля для пользователей — 2-мя строчками в .htaccess и ~2мя сниппетами, один из которых уже заточен под это — pdousers.
Для чего делать из легкого инструмента еще один битрикс — искренне непонятно.
P.s. поймите меня правильно, это здорово, что сообщество хочет и может вливать валюту в развитие дополнений и оплату труда разработчику, но приоритеты, на мой взгляд, выбраны не слишком удачно, особенно учитывая тот факт, что для тех, кому данные инновации не нужны, все равно будут подгружаться лишние таблицы и обработчики.
Тэги для любой страницы, а не только тикетсов в Modx'e реализуется посредством добавления 1 tv специально предусмотренного в Modx'e вида, 1 сниппета для преобразования результатов и одной страницы для поиска ресурсов по ним.
Страница профиля для пользователей — 2-мя строчками в .htaccess и ~2мя сниппетами, один из которых уже заточен под это — pdousers.
Для чего делать из легкого инструмента еще один битрикс — искренне непонятно.
P.s. поймите меня правильно, это здорово, что сообщество хочет и может вливать валюту в развитие дополнений и оплату труда разработчику, но приоритеты, на мой взгляд, выбраны не слишком удачно, особенно учитывая тот факт, что для тех, кому данные инновации не нужны, все равно будут подгружаться лишние таблицы и обработчики.
Я вот кстати тоже не совсем догоняю для чего конкретно теги вшивать в tikets? Потом теже теги нужно будет вшивать в минишоп. В репозитории modx есть дополнение tagLister разве оно уже не реализовало все что нужно для тегов? если нет то может его форкнуть и допилить до нужного состояния нежели вшивать все в кучу?
Если честно, я и прелести tagLister'a не оценил — он уж на случай крайней лени, как по мне.
Вот как реализованы теги у меня (может, кому пригодится):
1. Дополнительное поле «tags»
Параметры ввода: Авто-метка (можно и простой строкой, по желанию)
2. Сниппет «tags», делающий теги ссылками (для последующего поиска по ним)
3. Вывод в чанке
Ну и дополнительно, для «полного спектра услуг»:
4. Создаем страницу "Поиск по тегам" с псевдонимом tag, где будем выводить все теги, удовлетворяющие запросу:
GET
5. Дописываем .htaccess, чтобы адресная строка поиска приняла вид site.ru/tag/Название_тега
Вот как реализованы теги у меня (может, кому пригодится):
1. Дополнительное поле «tags»
Параметры ввода: Авто-метка (можно и простой строкой, по желанию)
2. Сниппет «tags», делающий теги ссылками (для последующего поиска по ним)
<?php
if ($input == ''){
return;
}
$tags = explode(',',$input);
foreach ($tags as $key => $value){
$output[] = '<a href="'.$modx->makeurl($tagsPage, '').'/'.$value.'" itemprop="keywords">'.$value.'</a>';
}
return implode(', ',$output);
3. Вывод в чанке
[[*tags:notempty=`
<div class="tagList" itemscope itemtype="http://schema.org/CreativeWork">
[[!tags? &tagsPage=`91` &input=`[[*tags]]`]]
</div>
`]]
— где &tagsPage — параметр, определяющий айди страницы поиска по тегам для формирования ссылкиНу и дополнительно, для «полного спектра услуг»:
4. Создаем страницу "Поиск по тегам" с псевдонимом tag, где будем выводить все теги, удовлетворяющие запросу:
[[!pdoPage &parents=`0` &includeContent=`1` &where=`{"tags:LIKE":"%[[!GET? &get=`tag`]]%"}` &includeTVs=`tags` &limit=`10` &sortby=`createdon` &sortdir=`DESC` &depth=`1` &tpl=`tag.Item`]]
— где сниппет GET перехватывает выбранный тег в адресной строке.GET
<?php
return $_GET[$get];
5. Дописываем .htaccess, чтобы адресная строка поиска приняла вид site.ru/tag/Название_тега
RewriteRule ^tag/([^/]+)$ /tag?tag=$1 [L]
в tagLister все тоже самое. Только чутка побольше. И как же нужно быть в лени что бы вшивать теги в сам компонент.
Могу ошибаться, но по-моему в нем где-то жестко использовался getResource в отображении, поэтому и написал свой модуль (повторяюсь, могу ошибаться — дело было давно) =)
Так я и говорю, может просто его допилить до нужного состояния.
Спасибо! Просто и понятно!
А че там допиливать? сформировать строчку запроса where из гета (для запроса поиска реурсов по тегам)- дело не хитрое. Я ее в маленьком ленивом сниппете сделал и в pdoResource отправил. Делов-то. А то видишь ли качай ему getResource и getPage. Важный какой )
Но я вот о чем хочу сказать. Тиккеты подхватывают при установке пдо-тулз. Отдельный пакет. И как выше сказано, они обладают уже мощным функционалом. Вот допустим я хочу комментарии на сайте. Чеб мне не скачать только соответствующий сниппет тиккетов без расширенных ресурсов, например… Отдельным пакетом. Ну короче идея в том, чтобы при увеличении функционала в тиккетах он становился более модульным, чтобы можно было скачать то, что нужно и не качать остального. Но это так, размышления на тему.
Но я вот о чем хочу сказать. Тиккеты подхватывают при установке пдо-тулз. Отдельный пакет. И как выше сказано, они обладают уже мощным функционалом. Вот допустим я хочу комментарии на сайте. Чеб мне не скачать только соответствующий сниппет тиккетов без расширенных ресурсов, например… Отдельным пакетом. Ну короче идея в том, чтобы при увеличении функционала в тиккетах он становился более модульным, чтобы можно было скачать то, что нужно и не качать остального. Но это так, размышления на тему.
Много критики, но хотелось бы уточнить смысл отдельного дополнения на мой обывательский взгляд. Постоянно в сообществе были жалобы на скорость работы с ТВ, в комментах описали такой логичный простой вариант, но вопрос какая будет скорость и возможности такого решения для более-менее крупной блого-платформы? Может все таки лучше сразу делать все в отдельных таблицах? Ну допустим (мульти)выборка тега и отображение всех ресурсов, или исключение какого-нибудь тега. Мне кажется здесь отношения теги к ресурсам, вроде многое ко многим через отдельную таблицу. Ну и конкретные перспективные хотелки в сниппетах, вроде мультивыбора тегов, исключения тега, какая-нибудь фронт-энд подгрузка, нормализация, чтобы не было вариантов с различными окончаниями и т.п.
По поводу все большей монструозности в тикетах, это имхо проблема нахождения баланса между универсальностью и модульностью дополнений. Если можно, то было бы логично делать в отдельном дополнении и ничего не вшивать, впрочем как и ТикетМета, да и ТикетКомментс, ничего плохого нет и в допиливании Таглистер, единственная проблема тут возможна будет с использованием библиотек Pdotools. Вообще грамотное ТЗ половина дела, тут думать надо.
По поводу все большей монструозности в тикетах, это имхо проблема нахождения баланса между универсальностью и модульностью дополнений. Если можно, то было бы логично делать в отдельном дополнении и ничего не вшивать, впрочем как и ТикетМета, да и ТикетКомментс, ничего плохого нет и в допиливании Таглистер, единственная проблема тут возможна будет с использованием библиотек Pdotools. Вообще грамотное ТЗ половина дела, тут думать надо.
Да, это справедливо. Помнится, Agel Nash даже выявлял довольно неприятные уязвимости tv-полей.
Другое дело, что отдельным сниппетом можно реализовать вывод, да. Но, в отличие от тех же комментариев, теги вряд ли логично выставлять отдельно со стороны бэкэнда.
Нормализация — тут уже придется подключать словари и не только. Вообще, если нужен будет морфологический анализ, имхо, это очень серьезный и сложный вопрос реализации, заслуживающий полноценного и отдельного дополнения.
А что имелось ввиду под «исключением тега»?
Другое дело, что отдельным сниппетом можно реализовать вывод, да. Но, в отличие от тех же комментариев, теги вряд ли логично выставлять отдельно со стороны бэкэнда.
Нормализация — тут уже придется подключать словари и не только. Вообще, если нужен будет морфологический анализ, имхо, это очень серьезный и сложный вопрос реализации, заслуживающий полноценного и отдельного дополнения.
А что имелось ввиду под «исключением тега»?
С тегами есть возможность реализации каких-нибудь подписок для пользователя или вывода лент. Исключение, например исключение тега 18+ для безопасной ленты. Тут наверное можно было бы подключить pdopage с переданными условиями.
Все комментарии про «незачем уводить дополнение от минимума, потому что его можно допилить» — считаю довольно странными. Зачем вам тогда готовое дополнение, если можно взять с нуля и допиливать, и допиливать, допиливать заново под каждый новый проект? Это просто мысли вслух — у каждого своя правда.
Для тех, кто радеет за минимализм и отсутствие «лишних таблиц» — вы и так подгружаете с тикетами все компоненты из пакета Тикетс, pdoTools, Jevix и Minifyx. Главное, обходиться без утрирования.
Что касается самих Тикетс в нынешнем виде, с кармой, комментариями и прочими фишками, — ребята, которые строят хорошие «юзер-френдли» ресурсы, — оценивают это дополнение, как одно из самых удобных, функциональных и быстрых на фоне аналогов в друпале и вордпресе.
Для тех, кто радеет за минимализм и отсутствие «лишних таблиц» — вы и так подгружаете с тикетами все компоненты из пакета Тикетс, pdoTools, Jevix и Minifyx. Главное, обходиться без утрирования.
Что касается самих Тикетс в нынешнем виде, с кармой, комментариями и прочими фишками, — ребята, которые строят хорошие «юзер-френдли» ресурсы, — оценивают это дополнение, как одно из самых удобных, функциональных и быстрых на фоне аналогов в друпале и вордпресе.
Ну, на мой взгляд, годные программисты и так стараются писать все дополнения под себя, за исключением pdotools, tickets и аналогичных, которые написаны слишком уж хорошо +на реализацию которых самим просто нет возможностей/времени.
Ну и да, к слову: большого ума, как по мне, чтобы реализовать более быстрый аналог друпалу и вордпрессу в текущей их ипостасти и не требуется. Ровно до тех пор, пока легкие дополнения Modx'a не стали «универсальным решением на все случаи жизни из коробки для ленивых»
Что же до подгружаемых элементов с пакетами tickets — повторюсь, вопрос в востребованности и максимальной необходимости для большинства. И теги ими, на мой взгляд, не являются.
ребята, которые строят хорошие «юзер-френдли» ресурсы, — оценивают это дополнение, как одно из самых удобных, функциональных и быстрых на фоне аналогов в друпале и вордпресе.— к чему это сказано? С тем же успехом можно было сказать что-то в духе: «ребята, которые работают на битриксе, оценивают битрикс как один из самых удобных и быстрых функционалов», но вряд ли от их мнения он таким становится.
Ну и да, к слову: большого ума, как по мне, чтобы реализовать более быстрый аналог друпалу и вордпрессу в текущей их ипостасти и не требуется. Ровно до тех пор, пока легкие дополнения Modx'a не стали «универсальным решением на все случаи жизни из коробки для ленивых»
Что же до подгружаемых элементов с пакетами tickets — повторюсь, вопрос в востребованности и максимальной необходимости для большинства. И теги ими, на мой взгляд, не являются.
Еще раз, Максим, хочу подвести к тому, что большинству нужно решение из коробки. Программистам оно не нужно и с этим я согласен.
Про большой ум и битрикс — я рад за тех, кто все это может. Допиливать, переделывать и прочее. Я не могу. Мне нужно готовое дополнение. И мне нужно мнение, которое поможет сделать его удобным. Вопрос целесообразности для меня не стоит.
Было бы здорово, чтобы годные программисты писали и допиливали для себя.
Про большой ум и битрикс — я рад за тех, кто все это может. Допиливать, переделывать и прочее. Я не могу. Мне нужно готовое дополнение. И мне нужно мнение, которое поможет сделать его удобным. Вопрос целесообразности для меня не стоит.
Было бы здорово, чтобы годные программисты писали и допиливали для себя.
Странный подход, на мой взгляд modx намного больше cmf, чем cms — поэтому и воспринимается как платформа, в первую очередь, для программистов.
Готовое дополнение (без морфологии) — tagLister. Со всеми наворотами — разве что писать с нуля и, на мой взгляд, на порядок целесообразнее отдельным дополнением, т.к. те же теги потенциально пригодятся не только в тикетах (галереи, фото-видео и пр пр).
Готовое дополнение (без морфологии) — tagLister. Со всеми наворотами — разве что писать с нуля и, на мой взгляд, на порядок целесообразнее отдельным дополнением, т.к. те же теги потенциально пригодятся не только в тикетах (галереи, фото-видео и пр пр).
С отдельным дополнением — согласен. Спасибо за мнение!
Хочу добавить — спасибо всем за высказанные мнения.
Я тут долго расписывал чем вредны теги, но надоело, если честно, и я забил)
Поэтому просто расскажу, как _надо_ делать тегирование.
Нужны:
1. Тикетс;
2. 2 tv;
3. 1 плагин;
4. 1 таблица.
Создаём раздел с тикетами. Называем его, к примеру «Теги» :-)
Создаём tv. В него будем записывать теги для страницы.
На сохранение ресурса (у которого д.б. теги), в плагине, смотрим в этот tv, разбираем теги и на каждый создаём тикет в нашем разделе «Теги». У этих тикетов-тэгов д.б. tv-шка, в которую мы в исходном виде записываем текст тега.
Потом записываем в нашу таблицу id ресурса и id тикета-тега (сколько тегов, столько и записей в таблице), не забывая перед этим очистить все прошлые записи для этого ресурса (ну вдруг мы отредактировали ресурс и какой-то тег удалили. Чтобы не заморачиваться с логикой — просто удаляем все записи для этого ресурса, а потом сохраняем текущие).
Выборку статей с данным тегом делать pdoResource'ом.
Собственно всё.
Я бы собрал пакетик на днях, да только болею я.
В общем, в чём профит.
На каждый тег будет отдельный ресурс. Да, если тегов 1000, то и ресурсов будет 1000. Если кого-то такой вариант не устраивает, то… не мои это проблемы)
Смысл в том, что у каждой страницы-тега можно редактировать урлы, контент, тайтлы, дескрипшены, да и вообще что душа пожелает — это же обычный ресурс. Это просто рай для любого более-менее грамотного сеошника. Вы в своих интернет-магазинах (и не только) сможете просто нереально расширить семантику, поднять траффика и позиции по куче низкочастотников. Достаточно небольшого уникального текста символов на 300, уникального тайтла и дескрипшена на каждой легированной странице. Вот и всё.
Все остальные варианты тегирования, в большинстве случаев, будут только во вред.
Между прочим, такие темы на платных закрытых вебинарах задвигают. А я вам готовый инструмент практически дал. Не упускайте шанс, как говорится.
Всем добра :-)
Поэтому просто расскажу, как _надо_ делать тегирование.
Нужны:
1. Тикетс;
2. 2 tv;
3. 1 плагин;
4. 1 таблица.
Создаём раздел с тикетами. Называем его, к примеру «Теги» :-)
Создаём tv. В него будем записывать теги для страницы.
На сохранение ресурса (у которого д.б. теги), в плагине, смотрим в этот tv, разбираем теги и на каждый создаём тикет в нашем разделе «Теги». У этих тикетов-тэгов д.б. tv-шка, в которую мы в исходном виде записываем текст тега.
Потом записываем в нашу таблицу id ресурса и id тикета-тега (сколько тегов, столько и записей в таблице), не забывая перед этим очистить все прошлые записи для этого ресурса (ну вдруг мы отредактировали ресурс и какой-то тег удалили. Чтобы не заморачиваться с логикой — просто удаляем все записи для этого ресурса, а потом сохраняем текущие).
Выборку статей с данным тегом делать pdoResource'ом.
Собственно всё.
Я бы собрал пакетик на днях, да только болею я.
В общем, в чём профит.
На каждый тег будет отдельный ресурс. Да, если тегов 1000, то и ресурсов будет 1000. Если кого-то такой вариант не устраивает, то… не мои это проблемы)
Смысл в том, что у каждой страницы-тега можно редактировать урлы, контент, тайтлы, дескрипшены, да и вообще что душа пожелает — это же обычный ресурс. Это просто рай для любого более-менее грамотного сеошника. Вы в своих интернет-магазинах (и не только) сможете просто нереально расширить семантику, поднять траффика и позиции по куче низкочастотников. Достаточно небольшого уникального текста символов на 300, уникального тайтла и дескрипшена на каждой легированной странице. Вот и всё.
Все остальные варианты тегирования, в большинстве случаев, будут только во вред.
Между прочим, такие темы на платных закрытых вебинарах задвигают. А я вам готовый инструмент практически дал. Не упускайте шанс, как говорится.
Всем добра :-)
Смысл в том, чтобы собрать пакет, который дает «тегирование» из коробки. То, как это делать, в теории, я и сам могу написать :) Спасибо и добра тебе :)
Ты не уловил посыл)
Главное не «тегирование из коробки», а «правильное тегирование». Правильное в коробку завернуть как раз не проблема, было бы оно правильным :-)
Может быть на следующей неделе соберу. Хз когда выздоровлю.
Главное не «тегирование из коробки», а «правильное тегирование». Правильное в коробку завернуть как раз не проблема, было бы оно правильным :-)
Может быть на следующей неделе соберу. Хз когда выздоровлю.
С этим посылом согласен. Но с опасением отношусь к использованию ТВ-полей как классу, тем более при возможном масштабировании до нескольких тысяч тэгов-наименований.
Плюс проверка слова, для предотвращения повторения одних и тех же слов с разными окончаниями (машина, машину, машины) и подставление уже имеющихся.
Плюс проверка слова, для предотвращения повторения одних и тех же слов с разными окончаниями (машина, машину, машины) и подставление уже имеющихся.
В этом и вся фишка — в этом алгоритме твшки в выборках практически не учавствуют.
Единственное место, где они будут нужны — это вывод списка тегов на странице. И здесь вопрос решается очень и очень просто — pdoResource.
В pdoTools'е всё уже предусмотрено. Так что скорости будут максимальными
Единственное место, где они будут нужны — это вывод списка тегов на странице. И здесь вопрос решается очень и очень просто — pdoResource.
В pdoTools'е всё уже предусмотрено. Так что скорости будут максимальными
Ну разные окончания — тут уж пусть каждый сам решает что ему важнее. Можно сделать событие, в котором каждый сам будет исправлять теги как ему нужно — хоть через phpMorphy к начальной форме слова приводить.
Но лично я подразумевал, что процесс создания тегов контролируется администратором сайта, а не пользователями. Пользователям вообще нельзя теги давать, иначе они в них нах*есосят. Либо по-умолчанию эти теги делать неопубликованными, а потом постоянно в ручную проверять на корректность
Но лично я подразумевал, что процесс создания тегов контролируется администратором сайта, а не пользователями. Пользователям вообще нельзя теги давать, иначе они в них нах*есосят. Либо по-умолчанию эти теги делать неопубликованными, а потом постоянно в ручную проверять на корректность
Модерировать — нужно, но в уже имеющемся списке. Проверять (премодерация) каждый тег — при большом объеме практически невозможно. Поэтому, проверка на окончания и подстановка уже имеющегося.
Ну так по смыслу это ни чем не отличается от того же выбора секции в форме добавления тикетов с фронта. Тот же заранее заданный список. Только вместо комбобокса — pillbox с автокомплитом. Надо просто это в одну кучу собрать.
Просто сделать такой интерфейс универсальным несколько сложнее. Из коробки будет заточенность только под бутстрап.
Просто сделать такой интерфейс универсальным несколько сложнее. Из коробки будет заточенность только под бутстрап.
Алексей, а сможешь собрать этот пакет, но без использования ТВ-полей? Писать значения можно в имеющееся поле.
Я пока температурю. До рабочего компьютера не знаю когда доберусь
Поправляйся.
Спасибо)
А какое поле ты подразумеваешь, говоря «имеющееся»? Какое-нибудь наименее используемое у ресурса? Я из таких знаю только Атрибут ссылки. Но у него длина ограничена 255 символами.
А какое поле ты подразумеваешь, говоря «имеющееся»? Какое-нибудь наименее используемое у ресурса? Я из таких знаю только Атрибут ссылки. Но у него длина ограничена 255 символами.
Description или Introtext — не помню, какой из них не ограничен по длине. Если учесть, что страница будет заточена под отображение тега или множества тегов, то для прочего нужен только заголовок и контент. Остальное можно дописать через MIGx, если будет необходимость. Или по-простому — ТВ-поля. :)
Так в итоге пакет собирали или нет? Реализация с точки зрения сео самая правильная.
Вот только сами теги надо создавать=заполнять самостоятельно, а пользователю давать их выбирать. + добавлять с премодерацией было бы правильно. Проще 1 раз промодерировать — дополнив необходимой информацией, склонениями, описанием.
Вот только сами теги надо создавать=заполнять самостоятельно, а пользователю давать их выбирать. + добавлять с премодерацией было бы правильно. Проще 1 раз промодерировать — дополнив необходимой информацией, склонениями, описанием.
Не, руки не дошли. Да и хз когда дойдут)
Просто пока они мне не нужны были, а понадобятся тогда, когда свой интернет-магазин делать буду. А этого в ближайших планах нету
Просто пока они мне не нужны были, а понадобятся тогда, когда свой интернет-магазин делать буду. А этого в ближайших планах нету
Здравствуйте, получилось реализовать или все еще не пригодилось? Задумываюсь, очень нужная штука.
Вывод тега в урл с транслитом букв или нумеровать.
Задавал такой вопрос уже однажды, хотел реализовать на своем проекте.
Ответ Василия был прост — запили и накидай реквесты на гитхабе.
Начал думать что надо и как это реализовать. Понял, что нет смысла вставлять теги в тикетс, потому что туда можно вставить только ущербные теги, иначе получится тикетс-монстр.
Например, теги нужны для того, что бы в сообществе выводить похожие статьи, но теги надо модерировать, хорошо бы запилить морфологический анализ статей для автотегирования, нужен словарь тегов с модерацией, нужен удобный отдельный интерфейс что бы все это рулить.
Вывод напрашивается сам собой — просто нужен отдельный мощный инструмент для тегов, которого для MODx пока что нет.
Как реализовать необходимый минимум описали выше.
Ответ Василия был прост — запили и накидай реквесты на гитхабе.
Начал думать что надо и как это реализовать. Понял, что нет смысла вставлять теги в тикетс, потому что туда можно вставить только ущербные теги, иначе получится тикетс-монстр.
Например, теги нужны для того, что бы в сообществе выводить похожие статьи, но теги надо модерировать, хорошо бы запилить морфологический анализ статей для автотегирования, нужен словарь тегов с модерацией, нужен удобный отдельный интерфейс что бы все это рулить.
Вывод напрашивается сам собой — просто нужен отдельный мощный инструмент для тегов, которого для MODx пока что нет.
Как реализовать необходимый минимум описали выше.
Т.е., твое мнение — это отдельный компонент?
Определённо, да.
Поразмышляв на эту тему, готов согласиться. Спасибо за мнение.
может с помощью mSearch2
Может быть. Никогда его не пробовал. Возможно, проще и удобнее его допилить, чем писать новый компонент.
modx.com/extras/package/tagger буду пробовать это.
Мне кажется, при расширении Tickets двигаться надо в сторону miniShop2 — создавать отдельные дополнения, хочешь — расширяй, но отдельными компонентами. Как пример, TicketMessages. Т.е. по сабжу например TicketTags.
Хорошая мысль, только miniShop2 изначально создавался под расширение, а Tickets — нет.
Боюсь, там слишком многое нужно переработать, чтобы можно было делать дополнения как для MS2.
Боюсь, там слишком многое нужно переработать, чтобы можно было делать дополнения как для MS2.
Хорошая мысль, только miniShop2 изначально создавался под расширение, а Tickets — нет.Это да. Но можно попробовать с минимальными затратами. Например, вот это шаг в сторону расширения.
На будущее, тем кто найдет эту тему через поиск. Цитата:
Wassi Wassinen 15 февраля 2015, 19:31 # ↑ 0
Чтобы были тэги — иcпользуй Tagger. Чтобы работало с Тикетами нужно реквест автору Таггера отправить. Кстати, Василий, почему в Тикетах может не отображаться еще одна вкладка с тегами?
ответить
Tim Yusupov 30 минут назад # ↑ 0
Удалось подружить Tagger с Тикетами? Или может другое решение использования тегов в тикетах есть?
ответить
Wassi Wassinen 10 минут назад # ↑ 0
Нет, не удалось. Нашел решение, которое мне показалось более изящным и масштабируемым — публикую товары minishop2 через вот этот чудесный компонент
modstore.pro/packages/users/ms2form
Умеет публиковать категории товаров (раздел тикетов) и сами товары (тикет). Поддерживает тэги, мультикатегории, крутой редактор и т.д. Вместе с автором всё еще шлифуем компонент. На выходе, надеюсь, получится интересно.
ответить
Tim Yusupov 6 минут назад # ↑ 0
Супер! Благодарю за подсказку!
ответить
Wassi Wassinen 1 минута назад # ↑ 0
Не за что :) Чем еще нравится это решение — можно давать пользователям (всем или группе избранных) создавать свои блоги (категория MS2) и постить туда заметки (товары).
И по этой схеме можно делать все, что угодно. Каталог мест и событий, Людей и их действий и т.д. Нужные поля добавляются через плагины и можно собрать любого «монстра». :)
Я использовал компонент tvSuperSelect.
Чтобы с фронта добавлять тэги добавил плагин, который заполняет ТВ поле и таблицу компонента значениями:
Может кому пригодится =)
Чтобы с фронта добавлять тэги добавил плагин, который заполняет ТВ поле и таблицу компонента значениями:
<?php
// tvssTagsSave
$tvss = $modx->getService('tvsuperselect', 'tvsuperselect', $modx->getOption('core_path').'components/tvsuperselect/model/tvsuperselect/');
if (!($tvss instanceof tvSuperSelect)) {
return '';
}
switch ($modx->event->name) {
case 'OnDocFormSave':
if (is_object($resource) && is_array($resource->_fields)) {
$data = $resource->_fields;
$resource_id = $data['id'];
// $modx->log(1, print_r($data, 1));
$flds = $tv_values = array();
foreach ($data as $key => $value) {
if ($key == 'tags') {
$tv_id = 1;
$array = array_diff($value, array(''));
if (!empty($array)) {
$flds[] = array(
'resource_id' => $resource_id,
'tv_id' => $tv_id,
'data' => $array,
);
$tv_values[$tv_id] = $modx->toJSON($array);
}
}
}
// пишем в таблицу пакета
if (!empty($flds)) {
// $modx->log(1, print_r($flds, 1));
$table = $modx->getTableName('tvssOption');
foreach ($flds as $fld) {
$sql = 'DELETE FROM '.$table.' WHERE `resource_id` = '.$fld['resource_id'].' AND `tv_id` = '.$fld['tv_id'];
$stmt = $modx->prepare($sql);
$stmt->execute();
$stmt->closeCursor();
$values = array();
foreach ($fld['data'] as $value) {
if (!empty($value)) {
$values[] = '('.$fld['resource_id'].',"'.$fld['tv_id'].'","'.addslashes($value).'")';
}
}
if (!empty($values)) {
$sql = 'INSERT INTO '.$table.' (`resource_id`,`tv_id`,`value`) VALUES '.implode(',', $values);
$stmt = $modx->prepare($sql);
$stmt->execute();
$stmt->closeCursor();
}
}
}
// пишем в таблицу modTemplateVarResource
if (!empty($tv_values)) {
//$modx->log(1, print_r($tv_values, 1));
foreach ($tv_values as $tv_id => $values) {
if (!$tv_obj = $modx->getObject('modTemplateVarResource', array(
'tmplvarid' => $tv_id,
'contentid' => $resource_id,
))) {
$tv_obj = $modx->newObject('modTemplateVarResource');
}
$tv_obj->fromArray(array(
'tmplvarid' => $tv_id,
'contentid' => $resource_id,
'value' => $values,
));
$tv_obj->save();
// $modx->log(1, print_r($tv_obj->toArray(), 1));
unset($tv_obj);
}
}
}
break;
}
Чтобы выводить во фронте поле добавил сниппет:<?php
// tvssTagsOptions
/* @var pdoFetch $pdoFetch */
$fqn = $modx->getOption('pdoFetch.class', null, 'pdotools.pdofetch', true);
$path = $modx->getOption('pdotools_class_path', null, MODX_CORE_PATH.'components/pdotools/model/', true);
if ($pdoClass = $modx->loadClass($fqn, $path, false, true)) {
$pdoFetch = new $pdoClass($modx, $scriptProperties);
} else {
return false;
}
$pdoFetch->addTime('pdoTools loaded');
if (!$modx->addPackage('tvsuperselect', MODX_CORE_PATH.'components/tvsuperselect/model/')) {
return false;
}
$tv = $modx->getOption('tv', $scriptProperties, ''); // TV name or...
$tvid = $modx->getOption('tvId', $scriptProperties, ''); // ... TV id
$tvInput = $modx->getOption('tvInput', $scriptProperties, ''); // TV input name
$res = $modx->getOption('res', $scriptProperties, 0); // Resource id
$tpl = $modx->getOption('tpl', $scriptProperties, 'tpl.tvssTagsOptions');
$tv_where = $tv ? array( 'name' => $tv ) : '';
$tv_where = $tv_where ?: ( $tvid? array( 'id' => $tvid ) : '' );
// print_r($tv_where);
if( empty($tv_where) ) { return; }
if( $tv_obj = $modx->getObject('modTemplateVar', $tv_where) )
{
$value = '';
if( $res != 0 && $tv_val_obj = $modx->getObject('modTemplateVarResource', array(
'tmplvarid' => $tv_obj->id,
'contentid' => $res,
))) {
$value = $tv_val_obj->value;
}
$value_arr = $modx->fromJSON($value); // Массив со значениями тэгов конкретного ресурса
// Массив, который мы передадим в процессор, там его ловить в $scriptProperties
$processorProps = array(
'tv_id' => $tv_obj->id,
);
// Массив опций для метода runProcessor
$otherProps = array(
// Здесь указываем где лежат наши процессоры
'processors_path' => $modx->getOption('core_path') . 'components/tvsuperselect/processors/'
);
// Запускаем
$response = $modx->runProcessor('mgr/option/getoptions', $processorProps, $otherProps);
// И возвращаем ответ от процессора
$options_array = $modx->fromJSON($response->response); // Массив со всеми тэгами
if (is_array($options_array['results']) || is_object($options_array['results'])) {
foreach($options_array['results'] as $v) {
$selected = '';
if (is_array($value_arr) || is_object($value_arr)) {
foreach ($value_arr as $key => $val) {
if ($v['value'] == $val) {
$selected = "selected=\"selected\"";
}
}
}
$options .= "<option ". $selected ." value=\"". $v['value'] ."\">";
$options .= $v['value'];
$options .= "</option>";
$selected = "";
}
}
$return = $modx->getChunk($tpl, array(
'tv_id' => $tv_obj->id,
'tv_name' => $tv_obj->name,
'tv_input_name' => $tvInput ?: $tv_obj->name,
'tv_value' => $value,
'res_id' => $res,
'options' => $options
));
return $return;
}
else {
return;
}
Чанк tpl.tvssTagsOptions:<select name="tags[]" multiple="multiple" class="js-tvSuperSelect-tags form-control" id="ticket-tags">
[[+options]]
</select>
В чанке с формой добавления/редактирования тикетов добавил:<link href="/js/select2-4.0.2/dist/css/select2.min.css" rel="stylesheet" />
<script src="/js/select2-4.0.2/dist/js/select2.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$(".js-tvSuperSelect-tags").select2({
tags: true
});
});
</script>
<div class="form-group">
<label for="ticket-sections">Тэги</label>
[[!tvssTagsOptions? &tv=`tags` &res=`0`]]
// В чанке редактирования [[!tvssTagsOptions? &tv=`tags` &res=`[[+id]]`]]
<span class="error"></span>
</div>
Прикрутил к полю тэгов Select2, чтобы тэги было удобно заполнять и все.Может кому пригодится =)
Все работает!
А что не так было? Почему не работало?
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.