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

В файле assets/compoents/fullcalendar/js/web/default.js добавь следующую настройку

Стоп. pdoTools удалили, а минишоп оставили? Ну так сего же ещё ждать. Библиотека pdoTools обязательно для miniShop2! И для Tickets. И много ещё для чего.

Проверьте лог сервера.
Еще вариант. Зайдите через FTP и в корневом файле index.php в самом начале укажите

ini_set('display_errors', 1);
ini_set('error_reporting', -1);

Тоже самое для админки в файле manager/index.php.
После этого ошибки должны вывалится на странице. Скорее всего отсутствуют какие-то классы.

Скажите пожалуйста, а работа с бронями происходит только через админку?

Да.

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

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

А где ты его меняешь? Меняй в плагине на событие OnMODXInit. Если в $_REQUEST'е есть город, то меняй настройку.

Я же говорю, тут нет смысла холиварить — оба достойные варианта, тут ошибиться нельзя. Вот для сравнения.

Есть ещё фреймворк Lumen, который является младшим братом Laravel. Он используется для сервисов и API. Он почти мгновенно отдает ответ на запрос, потому что не грузит все эти тонны классов, как это делает Laravel. Т.е. в багаже разработчика Laravel уже 2 инструмента. Не знаю, есть ли такое для yii2.
Кстати, ещё Lumen часто используют для SPA приложений (одностраничных) на ангуляре или вью. Что тоже сейчас очень популярно.

А кто первый? )
Я знаю несколько человек из сообщества MODX, кто работает на Laravel, и ни одного, кто знает yii2. Возможно это повлияло.
Эти два фреймворка приблизительно похожи. Смотрел и тот и другой. Почему-то решил выбрать Laravel. У последнего и документация хорошая и сообщество живое. Да и популярность Laravel стремительно растет. Моё мнение, выбрав один из этих фреймворков ошибиться нельзя.

P.S. Как выбрать PHP фрейворк.

Laravel построен по принципу SOLID и опытный разработчик следует этому принципу при разработке приложений на ларе. Как правило, один модуль ничего не знает про другой. Зависимости реализованы через абстракции. К примеру, личный кабинет. Чтобы он работал, класс пользователя должен инмплементировать соответствующий интерфейс с требуемыми методами. Таким образом, в разных проектах объект пользователя может отличаться полями, но содержит всегда требуемые методы. Это открывает большие возможности — легко расширять функционал, проще тестировать. Это чисто для примера. Менеджеру, привыкшему просто загружать пакет из менеджера пакетов MODX, объяснить это непросто, но программист поймёт о чём я говорю. Это реально другой уровень. Сам я ещё не все прелести попробовал, но от уже познанного в таком восторге. :)

Ну если говорить про

личный кабинет, история заявок, калькулятор, обмен данными (по API с CRM)

то этого ничего нет «из коробки». Всё придется ставить дополнительно или писать самому.

Если в Laravel все стандартизировано — хорошо.

Иначе он работать не будет. Как и любой другой фреймворк. Причем он поддерживает все последние стандарты в отличие от MODX. А последний уже морально устарел. Именно поэтому кривая его популярности ползёт вниз. А MODX 3 так и не родился, хотя ждали больше 3-х лет.

Миш, позволю себе не согласится с твоим мнением про много кода и велосипеды при программировании в Laravel. Для него/неё написано гораздо больше модулей, чем для MODX. Главный недостаток — это отсутствие UI во многих из них. Но на то он и framework. :) Лично у меня после того, как я преодолев страх погрузился в Laravel, не возникает ни малейшего желания возвращаться на MODX. А страх был именно из-за отсутствия привычного UI. Пользователи Windows меня поймут — линуксы, юниксы и баши до сих пор вызывают у меня дрожь. :)

Язык определяется в системной настройке cultureKey.

Неа. Некудышный я телепат. ) Поэтому придется по старинке — или дай доступ к сайту (самый простой вариант) или создай на modHost тестовый сайт со всеми дополнениями, установленными на твоем сайте, и если проблема повторится, то дай мне доступ (более сложный вариант)

Идею понял, но решение не додуманное — настройка All всегда в приоритете. Т.е. нельзя разрешить какое-то действие в пакете. Но даже если поменять местами аргументы, то все равно нужно проверять совпадения действий.

Я не делал. Проще убрать доступ в этот интерфейс.

У меня сейчас вообще нет времени на программирование. Но как только освобожусь, закончу то что запланировал на Laravel. Думаю, многим здесь это понравится. :)

Исправил. Проверил на своих сайтах, всё работает.
Спасибо за багтестинг!

Проверим. Пока отключил обновление. На тестовом сайте всё гуд (см. картинку в топике).

Тебе спасибо за идею. )

Тогда неплохо было бы примечание повесить — мол возможны проблемы при деинсталяции и удалении выделенных пакетов.

Одно лечат, другое колечат.

Походу никто не пользуется деинсталяцией пакетов. В том числе тестировщики. Видимо анахронизм. В MODX 2.5.7 деинсталлировать пакет не получится (по крайней мере на MODHOST.PRO) —

Консоль запущена...
Поиск пакета с подписью: ace-1.6.5-pl
Пакет найден. Подготовка к деинсталляции.
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Problem instantiating object from vehicle
Recoverable error: Object of class xPDOObjectVehicle could not be converted to string
Ошибка при деинсталляции пакета с подписью: Object