Сергей Шлоков

1. При установке опции &allowGuestEdit=`0` вроде все гуд — гости смотрят, админы редактируют и добавляют. Но только админ не может удалить событие. Всплывает окно с предупреждением, а далее сообщение, что редактирование запрещено.

Есть такое дело. Логику с правами вынес в сниппет, а в классе забыл подправить это дело. Исправление будет доступно в новой версии. А пока можно самому поправить в файле core/components/mycalendar/model/mycalendar/mycalendar.class.php (строка 406)

if ($this->config['readOnly'])

2. Помогите подружить его с гугл-календарем!

По инструкции должно быть 3 шага:
1. Получить API Google календаря.
2. Создать доступный всем (public) google календарь.
3. Получить его ID. Он должен выглядеть как-то так abcd1234@group.calendar.google.com.
API Google календаря прописать в системных настройках, а ID календаря в параметре &googleCalendars сниппета. Если все сделано правильно, то должно работать.
Календарь ru.russian#holiday@group.v.calendar.google.com является общим календарем с праздниками, у Вас он тоже должен работать.

Чего-то барахлит эта статистика

Не совсем понимаю о чем речь. Через ajax можно запускать и свой сниппет и pdoPage и сниппет в сниппете. Ограничений нет. Просто я не до конца понимаю контекст вопроса.

Почти :)
Версия 1.0.0-pl, а не бета.
П.С. А когда Леонид вернется?

Ну в такой интерпретации и MODX велосипед. :)

Но не всё :)

1. Как я понимаю, при помощи modx, нужно сделать sql запрос к базе, получить весь результат (?) и затем pdopage сам разделит эту кучу данных на несколько массивов, в количестве = количеству страниц. — сомнительно т.к. если база будет большая, процесс ведь затянется?

Ничего не затянется. Тут тысячи записей и все работает быстро.

… вы правда считаете чистый запрос на api — велосипедом?)

Интересная интерпретация. Т.е. если придумывать то, что уже придумано, на чистом api, то это уже не велосипед. Прикольно.

limit для pdoPage = кол-во результатов на страницу.
limit для сниппета = ограничение кол-во результатов, которые нужно разбить на страницы. (Пример: ТОП-100 популярных ресурсов, выводимых по 10 на страницу.)

Согласен. Мне показалось, что там один и тот же лимит.

Что же до element — через api, думаю, выйдет быстрее, да и не придется городить массу переменных непосредственно в вызове pdoPage.

Какая масса переменных? pdoResources вызывается по умолчанию. Т.е. все только упрощается. Если запрос по своей табличке, то передаешь только сниппет через element.

Грасиас, сеньор! Только в блоках code какие-то странные спаны образовались

//Вместо 
[[!siteOnlineUsers?]]
//Получилось
<span class="pun">[[!</span><span class="pln">siteOnlineUsers</span><span class="pun">?]]</span>

В данном примере пагинации не будет. Чтобы она была, в первой части не нужно запрос ограничивать лимитом. Лимит нужен для pdoPage.
И еще… Для запроса по таблице с ресурсами (класс modResource) можно напрямую вызвать сниппет pdoPage с параметрами limit и offset, потому как он автоматом вызывает сниппет pdoResources. Если нужны записи из какой-то другой таблицы, то в своем сниппете делаем запрос по нужной таблице, а сам сниппет передаем в pdoPage параметром element. И не надо изобретать никаких велосипедов.

[[!pdoPage?
	&element=`Ваш сниппет`
	&limit = `10`

Спасибо, Михаил. Обязательно воспользуюсь вашим предложением.

Мне тоже больше нравится вариант с minishop. Работы меньше, а возможностей больше. Просто интересно мнение с той стороны, т.е. пользователей. Поэтому к вам и обратился.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.

oneBooking всегда 990 руб.
Выбор будет между oneBooking с одним, двумя методами оплаты или oneBooking + miniShop2 с большим набором дополнений к нему.

Понял. Спасибо.

Михаил, вопрос по онлайн-оплате. Вы вроде как в теме.
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?

Не добавить, не убавить. Именно так это вижу и я.
Просто представьте, что разбираясь с Tickets вы увидели, что заложенный в него функционал позволяет использовать комментарии как личные сообщения. Нужно лишь немнооооожечко доработать. Некоторым это показалось интересным и вы свое решение предложили сообществу. Это не какой-то супер-пупер мегачат. Это тот же замечательный Tickets с небольшой плюшкой. Вот и все.
Кроме того, я показал еще один вариант использования Tickets — в качестве симпатичной книги отзывов.
Т.е. это просто небольшие расширения для Tickets. Не больше не меньше.

П.С. А возможность расширять диалог люди просили, поэтому я это и сделал.
П.П.С. Думаю, что Tickets подойдет и для большого сообщества. Люди вот на нем не хилые форумы делают. Наверно, такие личные сообщения на форумах могли бы пригодится.

значит нужно по двум столбцам сортировать parent и menuindex. Хотя если id папок не по порядку, то также как в админке не выйдет. Тогда нужно делать отдельные запросы для каждой папки.

&sortby=`id`

Он использует функционал Tickets, а там такой возможности нет. Вернее, у тикетов есть, а у комментариев нет. А мессаджи — это комментарии. Будет это у Tickets, будет и тут.

Не потянет он 300. И использовать его для чата я бы не советовал. Он больше подойдет для общения с сотрудниками компании.
Для чата нужно другое решение, через вэбсокеты. И таких решений уже достаточно в сети. Иначе это будет настоящая DDOS атака на твой сервер — 300 человек ходят по сайту + каждую секунду идут запросы по чату. Хана сайту.
Еще раз напомню. Это для решение для тех, кто уже использует Tickets и хочет кроме комментариев еще и сообщения получить. Два в одном. Например, на этом ресурсе это вполне могло бы пригодится. Иногда возникает какой-то вопрос к конкретному человеку. И тут TicketMessages мог бы помочь. Т.е. онлайн не нужен.