Максим Кузнецов

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

Да, к слову — псевдоним admin я привел для примера.) Вы можете назвать и разместить страницу как и где угодно, лишь бы в ней вызывался TicketForm с правильными настройками.

Точно так же, как и страницу создания:
— Допустим, у вас есть сайт и раздел с тикетами /news/
— Создаем страницу (ресурс, не тикет) внутри /news/ — «Панель управления тикетами» c псевдонимом admin
— Добавляем туда вызов TicketForm

Далее, при заходе на страницу /news/admin будет отображаться форма создания тикета. При заходе на страницу с видом /news/admin?tid=айди_ресурса будет открываться форма редактирования.

Вообще, такая ошибка чаще всего бывает при неправильных правах, но если вы точно их проверили, то:
— посмотрите лог ошибок, может быть там всплывает нужные данные
— проверьте настройки соответствующего источника файлов
— возможно, проблема на стороне хостинга

К слову, нет ли проблемы при загрузке изображений с других модулей (например, с tv-поля image)?

Или при помощи сниппета TicketMeta или как-то так:

[[!pdoResources?
	&class=`TicketFile`
	&where=`{"parent":[[*id]]}`
	&sortby=`createdon`
	&sortdir=`ASC`
	&tpl=`ticket.Gallery`
]]

Форму поиска вы можете реализовать при помощи этих или этих компонентов.

Нижние категории — при помощи pdoMenu.

Вы можете реализовать это при помощи дополнение mFilter2, выставив одним из фильтров — родителя, а другим — дедушку ресурса.

Ну и, как альтернатива, вы можете написать сниппет фильтрации самому (вот статья о том, как изобрести велосипед).

Могу выполнить в ближайшее время.
Контакты в профиле.

Видимо, при вашем присоединении таблиц существует не одна колонка name — укажите &class при вызове, чтобы определить нужный псевдоним колонки.

Мм… на мой взгляд, с этим пока у данного дополнения трудновато — не все куски выводимых элементов сейчас можно редактировать, т.к. они вшиты в ядро.

Могу предложить вам на правах самого простого варианта вот такую логику для решения данной задачи:
— размещаем оба сниппета (отображения рейтинга и голосования) в один контейнер с уникальным классом (допустим, ratingDiv)
— добавляем по уникальному классу для контейнера с отображением рейтинга и для контейнера, содержащий элементы для голосования (допустим, ratingTotal и letsRate соответственно)
— при помощи css вешаем на форму голосования следующие стили:

.ratingDiv {position: relative;}
.ratingDiv > .ratingTotal {position: relative; opacity: 1; z-index: 1;}
.ratingDiv > .letsRate {position: absolute; top: 0; left: 0; opacity: 0; text-indent: -9999px; z-index: 2;}
.ratingDiv:hover > .ratingTotal {opacity: 0;}
.ratingDiv:hover > .letsRate {opacity: 1;}

Если коротко, то мы вешаем форму с голосованием точно поверх дива с результатами голосования и прячем ее. А при наведении мы визуально скрываем результаты и проявляем форму для голосования, достигая нужного эффекта.

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

Я делал при помощи вот такой конструкции в чанке:

<div [[+rating:isequalto=`0`:or:isequalto=``:then=`style="display: none;"`]] date-rate="[[+rating:limit=`1`:isequalto=`0`:then=``:else=`[[+rating:limit=`1`]]`]]" class="rating" title="Голосов: [[+totalVoted]]"></div>

И дальше уже оформлял визуализацию при помощи css:

.rating[date-rate="5"] {стили}
.rating[date-rate="4"] {}
...

Самый простой вариант — при помощи css «display: none;»

Писать свой фильтр.

Может переголосовывать бесконечное число раз.

Запретить… ну, на текущий момент, разве что только костылями или правками ядра. Вообще, с этим вопросом вам лучше обратиться к разработчику.

Количество голосов у товара больше 0? Если нет, то дописать [[+rating:default=`0`]].

Если форм для голосований больше, чем одна — заменить вот тут «VoteFormThread.form = 1» единицу на id формы.

Можете еще проверить параметр [[+totalVoted]] — он в этом запросе тоже присутствует (сколько всего голосов за товар) — если он выводится, то с запросом все в порядке.

Ну и, как всегда, не лишним будет обновить кэш..)

Какая стоит версия Minishop'a? И есть ли ошибки в логе?

Вообще, по-умолчанию достаточно просто включить дефолтный способ оплаты paypal (minishop2 — настройки — способы оплаты — PayPal — поставить галочку напротив «включить»), чтобы данный способ отобразился — даже заполнять соответствующие настройки minishop'a для этого не требуется.

Получилось.) Вот рабочий код:

[[!mFilter2? &limit=`25` &loadModels=`voteforms` &paginator=`pdoPage` &class=`msProduct` &element=`msProducts` &depth=`0` &sort=`price:asc, rating:desc`
	&where=`{"class_key":"msProduct"}`
	&leftJoin=`{
		"VoteFormThread": {
			"class": "VoteFormThread",
			"on": "msProduct.id = VoteFormThread.resource AND VoteFormThread.form = 1"
		}
	}`
	&select=`{"Data": "*",  "VoteFormThread": "VoteFormThread.rating AS rating, VoteFormThread.users_count AS totalVoted"}`
	&tpls=`item.list.table`
]]

— рейтинг в чанке выводится плейсхолдером [[+rating]].

Если необходимо сделать добавление со стороны фронтэнда, то самый простой вариант:
[[!TicketComments? &depth=`1`]] — и оставить права комментирования только у администратора.

Ну или можно добавить одно дополнительное tv-поле (допустим, adminComment) и выводить его.

[[+adminComment:notempty=`
//здесь верстка для вывода комментария, если пол не пустое.
`]]

Возможность заполнения, соответственно, оставить только со стороны админки.
Ну или создать небольшой сниппет, проверяющий права юзера, и если юзер — админ, то давать возможность заполнять поле комментария и сохранять значение в tv при отправке.

При создании тикета пользователь ОБЯЗАТЕЛЬНО должен быть авторизован, т.к. у ресурсов модкса (тикеты — такие же ресурсы) всегда должен быть автор.

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

По первому вопросу, честно говоря — без понятия. Но, раз эта проблема возникла после обновления, вполне логично предположить, что дело в изменениях новой версии..)

По второму: msProducts работает или на pdoTools или на очень схожей механике, т.е. менять mProducts особого смысла нет — да и зачем, ведь он и предназначен для отображения подобной информации.

Тут или менять тип поля в бд (самый глупый из вариантов), или вешать &prepareSnippet на вызов или использовать вышеописанный фильтр — [[+value:replace=`.00==`]].
На мой взгляд третий вариант — самый лаконичный и удобочитаемый. Ну и лишнюю нагрузку почти не выдает.

А вообще, при выводе на странице, значения выводит MODX через xPDO, и убирает лишние нули, превращая decimal в int.

Что же до значения в категории, то вы, видимо, вызываете их через msProducts, а там никакой обработки нет (он знает формат только для веса, цены и других дефолтных параметров) — а так как он не знает, что за значение вы выводите, то и выдает как есть в БД — decimal.