tolanych

решение
modx.pro/components/17181#comment-105667

Будет исправлено в ближайшем обновлении (планирую, что выпущу до НГ). До выхода обновления быстрофикс можно произвести самому:

в файле core/components/tickets/processors/mgr/section/update.class.php строку

$properties = array_merge($this->object->get('properties'), $properties);

заменить на

$properties = array_merge($this->object->getProperties(), $properties);

Тут скорее просьба — почините модх, т.к. эти галочки работают аналогично поведению с другими ресурсами и контейнерами)
Как будет время, проверю, есть ли возможность для тикета переопределить поведение этой галочки и прихранить её состояние — но это будет исключительно косметическим решением для админки и на функционал не повлияет.

Если есть возможность, помогите с проблемой. Возможно у вас получится исправить

Обновлением это трудновато исправить, в Tickets такое архитектурное решение, которое на больших объемах делает подсчет просмотров тяжелой операцией.
Вам посоветую либо отказаться от подсчета просмотров вовсе либо использовать для подсчета какие-нибудь другие специализированные решения, работающие на отдельном сервере.
В качестве минимального решения (обойтись малой кровью) — могу предложить кешировать результат работы сниппета TicketMeta на N минут (например на 10). В таком случае тормозить тикет должен не чаще 1 раза в 10 минут во время обновления кеша.

Взгляни в сторону модификаторов:
docs.modx.pro/sistema/osnovyi/filtryi-vvoda-i-vyivoda#Модификатор-UserInfo
Модификатор photo, только не к id текущего юзера, а к автору материала — resource.createdon.

Да, сам процесс подсчета к чанку не относится.

Полумеры — не считать просмотры гостями — системная настройка tickets.count_guests

Так чтобы совсем отключить — это уже кочевряжить код нужно, в плагине Tickets событие OnWebPageComplete вызывает подсчет просмотров

UPD

хотя можете попробовать в настройках плагина (вкладка системные события) просто снять галочку OnWebPageComplete

Вы можете увидеть это в исходниках, добро пожаловать в OpenSource)

github.com/bezumkin/Tickets/blob/master/assets/components/tickets/js/web/files.js#L6

Поиск ответа с такими исходными данным сродни гаданию на кофейной гуще. Предстоит поиск виновника методом отладки.

В плагине минишопа на событии OnHandleRequest

exit($response);

замените на

var_dump($response);
exit();

и посмотреть, что там загадочного возвращается в массиве.
Если вывод не изменится, то по порядочку лезем в метод $miniShop2->handleRequest и ищем там точки выхода и что можно отладочно распечатать.

Ну если совсем научно-профессиональный метод, то настроить среду с PHPStorm, настроить xDebug и через точку остановки ловить ответ сервера и цепочку вызовов, как он пришел к такому ответу.

Ну допустим Вам нужна цифра из поля «totals». Тогда вместо последней строки:

$ym_data = file_get_contents( $url. '?'. http_build_query($params) );
$ym_data = json_decode($ym_data,true);
return (int)$ym_data['totals'][0];;

Насчет внутреннего устройства Office не подскажу, мб там и есть такая возможность.

как идея (сам не проверял) — написать плагин на событие авторизации и при каждой авторизации добавлять в extended-поле user-а текущую id_session.

$extended = $profile->get('extended');
$extended['sess_list'][] = текущий id сессии;
$profile->set('extended', $extended);
$profile->save();

На событие смены пароля доставать из extended-поля все id_session и удалять их из таблицы _session