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

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

Был в сети 06 ноября 2025, 19:54
Заказы не принимаю
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 является общим календарем с праздниками, у Вас он тоже должен работать.
1. Как я понимаю, при помощи modx, нужно сделать sql запрос к базе, получить весь результат (?) и затем pdopage сам разделит эту кучу данных на несколько массивов, в количестве = количеству страниц. — сомнительно т.к. если база будет большая, процесс ведь затянется?
Ничего не затянется. Тут тысячи записей и все работает быстро.
… вы правда считаете чистый запрос на api — велосипедом?)
Интересная интерпретация. Т.е. если придумывать то, что уже придумано, на чистом api, то это уже не велосипед. Прикольно.
limit для pdoPage = кол-во результатов на страницу.
limit для сниппета = ограничение кол-во результатов, которые нужно разбить на страницы. (Пример: ТОП-100 популярных ресурсов, выводимых по 10 на страницу.)
Согласен. Мне показалось, что там один и тот же лимит.
Что же до element — через api, думаю, выйдет быстрее, да и не придется городить массу переменных непосредственно в вызове pdoPage.
Какая масса переменных? pdoResources вызывается по умолчанию. Т.е. все только упрощается. Если запрос по своей табличке, то передаешь только сниппет через element.
В данном примере пагинации не будет. Чтобы она была, в первой части не нужно запрос ограничивать лимитом. Лимит нужен для pdoPage.
И еще… Для запроса по таблице с ресурсами (класс modResource) можно напрямую вызвать сниппет pdoPage с параметрами limit и offset, потому как он автоматом вызывает сниппет pdoResources. Если нужны записи из какой-то другой таблицы, то в своем сниппете делаем запрос по нужной таблице, а сам сниппет передаем в pdoPage параметром element. И не надо изобретать никаких велосипедов.
[[!pdoPage?
	&element=`Ваш сниппет`
	&limit = `10`
Мне тоже больше нравится вариант с minishop. Работы меньше, а возможностей больше. Просто интересно мнение с той стороны, т.е. пользователей. Поэтому к вам и обратился.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.
Михаил, вопрос по онлайн-оплате. Вы вроде как в теме.
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?
Не потянет он 300. И использовать его для чата я бы не советовал. Он больше подойдет для общения с сотрудниками компании.
Для чата нужно другое решение, через вэбсокеты. И таких решений уже достаточно в сети. Иначе это будет настоящая DDOS атака на твой сервер — 300 человек ходят по сайту + каждую секунду идут запросы по чату. Хана сайту.
Еще раз напомню. Это для решение для тех, кто уже использует Tickets и хочет кроме комментариев еще и сообщения получить. Два в одном. Например, на этом ресурсе это вполне могло бы пригодится. Иногда возникает какой-то вопрос к конкретному человеку. И тут TicketMessages мог бы помочь. Т.е. онлайн не нужен.