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

Если этот пакет нужен постоянно, то лучше указать его в системной настройке extension_packages. Тогда он будет самостоятельно загружаться всегда.

Для справки. Проверить загружен ли пакет можно по условию

if (isset($modx->packages('имя_пакета'))) ...
// или 
if (class_exists('имя_класса_из_пакета')) ...

Что происходит, когда я заново загружаю этот метод?

addPackage метод умный — он не будет загружать пакет, если он уже загружен.

Лучший гайд — это исходники MODX.

В моем случае он возвращает пусто ''.

Проверить можно просто. В сниппет PrintTimeTable перед return нужно добавить

$modx->log(1, $query->toSql()); // Сформированный sql запрос
$modx->log(1, $id_doctor);

Замет в журнале логов проверить.
На странице пусто потому, что после 10 циклов MODX этот плейсхолдер удаляет. Но в сниппет он передается на второй итерации.

Но ничего не выводится, так как каким-то образом отрабатывается $query->where(array('id' => $id_doctor)); в котором $id_doctor=null.

Думаю, не совсем так. Даже совсем не так. Если MODX не может распарсить плейсхолдер, то он его возвращает. Т.е. получается $id_doctor='[[!+id_doctor]]'. Вообще ваш вариант

[[!PrintTimeTable? &id_doctor=`[[!+id_doctor]]`]]

не очень хороший. MODX будет крутить 10 циклов, чтобы распарсить этот пустой плейсхолдер. Если добавить фильтр (любой) в плейхолдер, то MODX сразу его распарсит согласно условию. Т.е. парсер выдаст значение плейсхолдера, а не сам плейсхолдер. Поэтому с фильтром isempty получилось.
Не понятно зачем нужен промежуточный сниппет GET. id_doctor можно выловить в сниппете PrintTimeTable, тогда и таких проблем не будет. А в чанках можно использовать феном.

По дискасу… комментарии хранятся там же.

По теме. Допустим ты аутентифицировал пользователя как-то (HybridAuth кстати создает пользователя в БД). Встанет задача где-то хранить его данные — имя, email и т.п. Допустим запихнул в куки. А как сохранить информацию о пользователе в отзыве? Прописать куки? Завтра она пропадёт и что делать? А если это неважно, то зачем заставлять пользователя логиниться? А если залогинился через другую соц.сеть — уже другой пользователь. Подводных камней вагон.
Ещё права MODX работать не будут, в группы добавить нельзя. Возникает вопрос — ради чего отказываться от встроенного функционала? Почему нельзя хранить пользователей в базе? Может проще докупить место, чем изобретать свой велосипед, а потом ломать голову с поддержкой этого чуда.

Ещё один пример или непонимания или собственной интерпретации.
Не

Авторизация → действие (добавление комментария)

а авторизация действия. Именно так, без лишних слов и стрелок.

А от идентификации пользователя самому пользователю толку нет.

Ты о чём? На этом сайте, чтобы добавить комментарий, пользователь должен залогиниться. Т.е. сервер его должен идентифицировать. А уж испытывает ли пользователь от этого счастье или дискомфорт — это его сугубо личное дело. Лично я такими категориями (есть толк или нет) не оперирую. Нужно залогиниться — логинюсь. Не нужно — не логинюсь.

Я не буду даже говорить про личный кабинет с персональными настройками

Каюсь, вообще не понял о чём и про что это.

Заглянем в википедию.
Аутентификация — процедура проверки подлинности, например: проверка подлинности пользователя путём сравнения введённого им пароля с паролем, сохранённым в базе данных пользователей.
Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.

Как-то так.

[[pdoMenu?
	&parents=`0,19`
	&level=`1`
]]

showHidden, showLog

Имеющий глаза да увидит, имеющий уши да услышит — всё есть в доках.

Кэш браузера.

protected $isAutoBrMode = false;

Ну это как-то совсем не комильфо. До первого обновления.

Часто наблюдаю непонимание терминов авторизация и аутентификация. Аутентификация — это идентификация пользователя. А авторизация — это проверка разрешения на какое-то действие — просмотр, редактирование, удаление и т.п.

Создавать пользователей в БД после авторизации не нужно (это важно)

Думаю, в MODX это реализовать будет крайне сложно. Только если ваять свой механизм аутентификации.

Отключать глобально не хочется, чтобы не было проблем с тикетами.

Не будет. Для тикетов используется другой набор параметров (Ticket), как и для комментариев (Comment).

Очень много ошибок в коде.

1. Ты используешь в функции модификатора переменную $modx. А откуда она взялась? Её нужно пробросить через замыкание

...
$fenom->addModifier('dateformatter', function ($input)  use ($modx){
...

2. Загружать сервис не обязательно — он уже загружен.
3. Этот код содержит лишние строки

$output = $monthname; // Эта строка для чего?
return $output;
// Можно заменить на 
return $monthname;

4. Так как $monthname может быть не определена, в switch нужно добавить

default:
	$monthname = '';

Попробуй всё это собрать самостоятельно.

Параметры minTime и maxTime

$user->leaveGroup() — удаление группы (можно указать id или название)

П.С. save() использовать не нужно ни в том, ни в другом случае.

adminTools — это набор фич только для админки.

Вообще для ориентации удобней хлебные крошки. Кто-то вроде делал пакет с ними.
Для выделения добавьте в файл assets\components\admintools\css\mgr\themes\dark.css

.dark-theme #modx-leftbar-tabpanel .x-tree-node .x-tree-selected,
.dark-theme #modx-leftbar-tabpanel .x-tree-node .x-tree-selected span,
.dark-theme #modx-leftbar-tabpanel .x-tree-node .x-tree-selected .icon {
	background-color: #343b4c;
}

И modstore.pro/playboy тоже 404 выдает. Видимо русские хакеры взломали. ))

А вот так не проще?

<script>
  $(document).ready(function() {
      AjaxForm.Message.success = function(message, sticky) {
	$.fancybox.close();
        $.fancybox('<h1>' + message + '</h1>');
     };
  });
</script>

Спасибо!