Алексей Федоров

Если серьезно, то календарь создан, чтобы быть календарем)) Вывод лентой и т.д. организуется кучей компонентов. Начинать стоит с getResources и доработанного в сторону ускорения работы аналога от Василия pdoResources. Можно выводить каждое событие посредством поста в Tickets, а можно, как вариант, впихнуть на сайт код jsTimeline и выводить через него события из гугл-календаря. По всем вариантам есть инструкции в сети. Ну и еще куча всякого. Вообще было бы неплохо понимать, какая вообще задача решается? Потому что сейчас это напоминает вопрос: Можно ли в утюге сварить борщ? Если да, какой рецепт? И задается он посреди кухни, укомплектованной всем необходимым((

Наверное стоит поставить «Решено», а еще лучше перенести в «Готовые решения». И да, спасибо за инструкцию по добавлению кнопок))

Присоединяюсь к сказанному выше. Плюс можно использовать ClientConfig, но его сам пока только разбираю, поэтому конкретное решение привести пока не могу. Вроде бы можно BanerY приспособить для этого))

Каноникал не делает редирект, он всего лишь прописывает url страницы.

Буду знать)

У меня страница выходит вот такой — modzone.ru/rss/ то есть имеем в конце слеш. Возможно стоит [[Canonical]] в хеде (либо настройка в .htaccess), и устраивает войну с замороженным uri. Но это так из разряда предположений. Других вариантов я не вижу.

stebastus

хм, я так предполагал, что там uri заморожен. Вот этой вот папке форум прописываем тот адрес который нужен. Я чтой-то подумал, что поместить папку в контейнер будет проще, чем держать в отдельном каталоге, но раз задача исключительно такая, прописываем для этой папки forum «замороженный uri» — site.ru/kategory/forum-name/ для главной страницы форума замораживаем нужный адрес — site.ru/kategory/forum-name.html Был уверен, что это сработает. Что-то не срастается?

ставим галку «контейнер» и она становится одновременно и страницей и папкой)))

По поводу изменения адреса, есть в настройках страницы пункт «Заморозить uri» должно помочь. Саму страницу делаем контейнером и внутрь помещаем все, что нужно. Должно помочь, по идее.

Подумалось, что для форума неплохо было бы оформлять вывод группы в столбик и как-то индивидуально оформлять каждую конкретную группу. Оформление есс-но через CSS, где название группы будет выводиться селектором content, можно добавить иконку перед ним и т.д. Он просто создан для этого)). Встал вопрос: как сделать так, чтобы название группы превращалось в класс для отдельного элемента. Выводить решил через тег em.

Комментарий в коде просто спас. Php не знаю, но в нагуглил как работает implode и соответственно изменил разделитель. Вместо запятой поставил

"></em>
<em class="

А на странице в лк-юзера будет вызываться

<em class="[[UGroups.Forum?]]"></em>

Результат в итоге такой

<em class="Administrator"></em>
<em class="MessageUsers"></em>

То есть все работает, все здорово. Вроде бы не рекомендуется html конструкции вставлять в php, так что если имеется более правильный вариант этого дела, то…

Собственно, весь вызов сниппета запихнул в чанк с аналогичный названием (tagElementPlugin — обалденная штука!). Сам чанк вызывается в TV (будет вызываться, когда разберусь с Login/HybridAuth). Остается добавить вызов TV в чанке комментария на тикет)) и будет более привычный для форума вид ;)

Оформление «флажков» каждой группы можно вынести в отдельный файл CSS, но править будет неудобно. Зато если воспользоваться ClientConfig, вписать все стили в него, то результат получим в плейсхолдере. Последний добавить в обработку MinifyX и будет один ужатый файлик. Блин… я все больше люблю modx)))))

Сергею Шлокову еще раз спасибо!

Огромное спасибо!!!

Есть еще вот такой вариант, который является упрощением описанного в посте до вывода стандартными средствами:
[[+modx.user.isMember:is=`Users`:then=`Рядовой пользователь`]]
[[+modx.user.isMember:is=`Administrator`:then=`Администратор`]]
[[+modx.user.isMember:is=`Author`:then=`Автор`]]
[[+modx.user.isMember:is=`bla-bla-bla`:then=`Бла-бла-бла`]]

и все таки это жутко, а если число групп разрастется? Плохо будет((

Искал ответ по канонизации урл, нашел по большей части для nginx. Много-много-много готовых кодов. Автор поста указал, что всем кто сидит на апач, он помочь ничем не может. Так что за указание на методологию правки .httacces буду благодарен ;)

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

Если не сложно, напиши пожалуйста где что указать, чтобы через эту красивость добавлять тикеты. Пошаговая инструкция была бы очень кстати)) Сам не программист, с modx разбираюсь потихоньку, некоторые вещи для меня неочевидны, к сожалению(.

Еще сразу возник вопрос по целевому применению. Можно ли сделать вывод через пробел тегов, заданных в ms2form в html-код. На сайт устанавливаю js-сортировщик для списка товаров (там элементов не много будет, поэтому пока таким решением обойдусь, а то с mFilter сходу разобраться не получилось), а он фильтрует по значениям в селекторе class=" (вот тут можно ввести что-то вроде [[~[[*tags]]]], чтобы выдавал перечень тегов?) ".

теперь я знаю как вывести на сайте свою «карту мира», созданную в графредакторе, и снабдить пояснениями)) Ждем-с стабильную версию=)

Вот, кстати, вопрос. По ClientConfig документация на русском с примерами где-то существует?

Почитал оригинальную, вроде понятно, но не совсем. «Ключ» присваивается в качестве имени плейсхолдера или наоборот нужно взять существующий плейсхолдер и сформировать из него ключ. Опять же на инглише пример для селектора «да-нет» написан. А вот пример для смены фона шапки как сделать не разобрался(( не настолько я в этом деле опытен. Стоит ли вообще с ним заморачиваться без знания php? Потому как добавить возможность для группы пользователей менять шапку в своем «подотчетном» разделе — штука полезная и нужная. Но ее можно и через добавление TV сделать. Другое дело, что собрать все такие вот настройки в одну кучу — это здорово, но с моим уровнем знаний без примеров разобраться нереально(

Поэтому очень интересует существует такая информация в сети вообще или нет?

Установить дополнительный компонент. UserProfile реализует личный кабинет, а не регистрацию

Это круто! Я серьезно)) Я видел соответствующие плагины на xenforo и vanilla. У нас их часто называют дополнениями «геймификации», заграничные друзья — «бейджами». Суть в том, что при выполнении определенных условий, пользователя будут награждать некой «медалькой» (изменением оформления, приветствием с пением гимна и т.п.) и/или расширением прав на ресурсе (постить новые темы форума, проводить опросу, и сюда же я отношу и скидки). Как написал чуть выше Максим, если говорить о широте применения, то это часто конкретные вещи, которые весьма распространены и(!) пользуются большим спросом. Проблема, как всегда, в уровне знаний))

То есть, для «не программистов» этот компонент будет не очень полезен, так? Как человек далекий от join, get, OnSave и API в целом, могу сказать: первое, что бросается в глаза — привязка userkarma к конкретному показателю. Для меня это темный лес, ей богу)) Но об этом чуть позже. Николай, фактически я — твоя целевая аудитория и поэтому как человек, который ХОЧЕТ такой функционал, но не может допиливать его сам хочу указать на моменты, которые могут превратить этот компонент из потенциальной конфетки в очень популярный плагин.

Чтобы избежать ненужной демагогии и препирательств хочу указать сразу — Да, можно нанять программиста, который на основе компонента реализует что-то конкретно под мои условия. К тому же, насколько я понял идею Wassi Wassinen, он рассчитывал, что различные расширения к компоненту будут появляться как сейчас дополнения к miniShop2 — все как бы и не нужны, потому каждый добавляет на свой ресурс конкретные модули (плагины). Но! Если компонент не применим для меня как для рядового пользователя именно из коробки, то я трижды подумаю стоит ли его покупать.

Какой-то функционал из коробки для рядовых пользователей обязан быть! Иначе все полетит в трубу, а это в свою очередь означает прекращение развития компонента, чего очень бы не хотелось. В конкретно нашем случае привязка к рейтингу Тикетс — то, что доктор прописал)) Во-первых, рейтинг там уже сам рассчитывается, во-вторых, теперь, когда мы уже разобрались, что на Тикетс можно замутить нативный, шустрый и красивый форум для modx, вопрос перевода пользователей по группам в зависимости от рейтинга становится весьма остро. Чем шире аудитория клиентов, тем больше популярность (доход от продаж), поэтому я очень рекомендую это сделать.

Дальше… Сейчас я начну говорить вещи, которые отчасти можно отнести к программированию, но при этом сам я не программер, что значительно увеличивает шанс написания некой глупости по незнанию «очевидных» вещей. Поэтому, если что пусть кто-нибудь поправит, ок?

Я вижу главную проблему компонента, из-за которой вероятно придется создавать UserKarma2. «Многопоточность», если можно так выразиться)) Проще говоря, одна линейка «кармы» изначально ущербна. Возможно, в компоненте реализована возможность создавать параллельную, но я этого в статье не увидел. Как уже сказал Максим, разумно говорить о подгруппах. Мы прекрасно понимаем, что для modx это такая же группа, но функционально «кармические» группы используются для совершенно иных целей. И если мне понадобиться учитывать раздавать скидки для покупателей магазина (а мне понадобится) и одновременно переводить пользователей из группы в группу на форуме (не смотря на то, что это кажется какой-то ерундой, вовлеченность увеличивается, что сугубо положительно влияет на ресурс), то как быть?

Ограничение по «группам». Не просто так были упомянуты «бейджи». Суть в том, что при достижении некого количества «кармы», пользователю присваивается некая «медалька», общий список которых выводится сниппетом. Тут все до омерзения просто это даже мне понятно: создается таблица со списком медалек, как только условие выполнилось, ставим 1, и конкретный бейджик выводится сниппетом. В сущности, это будет разумно сделать отдельным компонентом и выложить в репозиторий как расширение UserKarma(2?). Почему я об этом заговорил, хотя к делу это вроде как не совсем относится? С радостью поясню))

Вот эти медальки-бейджики — классический пример расширения под «идеальный» UserKarma. Скидки покупателям в магазине? Дзинь! Еще один компонент. Нужно, это просто к примеру, чтобы карма изменялась в зависимости от того, сколько пользователь предложил новостей на СМИ-портал (по аналогии с предложением постов в группу ВК)? Дзинь! Еще один компонент=) Работа с календарем и датами появления пользователей на ресурсе, частота, длительность перерыва и т.д. — еще один компонент-надстройка. Думаю, все предельно понятно. Ах да, Дзинь! =) Эти дзинь это капающие денежки, если что ;)

А теперь перейдем к адовой (на первый взгляд) части. Как это все увязать? Правильно, нужно общее ядро, которое сделает так, что надстройки не будут конфликтовать и при этом все будет предельно понятно рядовому пользователю, иначе компонент пролетит как фанера над Парижем. Никто не станет брать дополнение, в котором на каждый чих нужно звать программиста (я знаю, что повторяюсь, но, Николай, у тебя есть такой пунктик. Нужно ближе к народу быть). Итак, как это сделать? Очень просто на самом деле ;)

Мне, как конечному пользователю, нужен интерфейс в котором я смогу создать «линейку кармы» и затем настроить ее. Последнее подразумевает, что будет возможность выбрать условия для «конкретного действия» при наступлении конкретных условий. Я акцентирую внимание еще раз — именно «условий», во множественном числе.

Я уже почти сплю, поэтому сейчас лезть в графический редактор не стану, но если нужно могу набросать схематический концепт «окошка». Сейчас просто опишу содержимое: Есть колонка условий в которой есть поле выпадающего списка и кнопка «добавить дополнительное условие» и есть колонка «действие» и соответственно кнопка «добавить новое действие».

Берем конкретный пример (сейчас будет та самая адовость). Я хочу перевести пользователя в группу «Скидка 10%», если он а) вошел в группу «доверенные» на форуме (часть карма-форума), б) вошел в группу «купил товаров на 100 000» (надстройка для карма-магазина), в) сегодня вторник и пользователь онлайн/оффлайн (надстройка карма-календарь).

Либо! Удалить пользователя из группы «Скидка 10%», если он: а) заработал получил медаль «Тролль» (на форуме получены 100 минусов, знаю, что тикетс это не считает, но кто-то однажды может сделать плагин для допподсчетов, тут был бы спрос. К примеру, мне этот функционал реализует нанятый программист) б) отсутствует на ресурсе более 6 месяцев (карма-календарь).

При этом у каждого условия и действия могут быть свои типы значений, что подразумевает появление своих особенных полей для каждого из них при выборе. Предусмотреть все действия нельзя, так? Но вот тут и появляются надстройки! Родительский компонент должен свободно работать с полями дополнений и обеспечивать работу со значениями параллельных линеек (было бы очень хорошо, если бы он изначально понимал все группы modx. Конечно, нужна защита от дурака, чтобы пользователь не ставил взаимоисключающих условий приписывать к условиям одной линейки одинаковую цифру (не обязательно пользователь должен выводится из одной группы и помещаться в другую — если! конечному юзеру компонента это нужно, то он указывает условие «форум-карма» значение=«40» действие: 1) добавить в группу «проверенный» 2) удалить из группы «новобранец».

Именно так, чтобы линейка формировалась самостоятельно! Чтобы была расширяемость сторонняя и стандартизированная хоть немного! Только тогда это будет по-настоящему популярное дополнение. В этом случае очередь за компонентом выстроится огромная)) И что на мой взгляд немаловажно, в таком варианте мы получаем приложение в духе modx — свобода творчества! Николай, не нужно делать расширения только для программистов, так и денег будет сложно заработать)) Кстати, на счет последних, я понимаю, что работы тут нормальная кучка, но при этом было бы круто сделать «материнскую основу» свободно распространяемой. Возможно имеет смысл замутить краудфандинговый сбор (сам похвастаться большим количеством свободных средств не могу, но толпой, думаю, осилим). Это ускорит распространение компонента и соответственно простимулирует создание небольших платных надстроек)) Вроде бы опыт MiniShop2 достаточно положителен как пример?

Короче, я свое видение универсализации показал, нужны будут уточнения с точки зрения «конечного пользователя», всегда готов))

С английским не очень дружу, но вот это вроде бы практически то, что нужно для реализации подсказок GlossaryOfTerms