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

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

Был в сети 06 ноября 2025, 19:54
Заказы не принимаю
Если этот пакет нужен постоянно, то лучше указать его в системной настройке extension_packages. Тогда он будет самостоятельно загружаться всегда.

Для справки. Проверить загружен ли пакет можно по условию
if (isset($modx->packages('имя_пакета'))) ...
// или 
if (class_exists('имя_класса_из_пакета')) ...

Что происходит, когда я заново загружаю этот метод?
addPackage метод умный — он не будет загружать пакет, если он уже загружен.
В моем случае он возвращает пусто ''.
Проверить можно просто. В сниппет 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 работать не будут, в группы добавить нельзя. Возникает вопрос — ради чего отказываться от встроенного функционала? Почему нельзя хранить пользователей в базе? Может проще докупить место, чем изобретать свой велосипед, а потом ломать голову с поддержкой этого чуда.
Ещё один пример или непонимания или собственной интерпретации.
Не
Авторизация → действие (добавление комментария)
а авторизация действия. Именно так, без лишних слов и стрелок.

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

Я не буду даже говорить про личный кабинет с персональными настройками
Каюсь, вообще не понял о чём и про что это.

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

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

Создавать пользователей в БД после авторизации не нужно (это важно)
Думаю, в MODX это реализовать будет крайне сложно. Только если ваять свой механизм аутентификации.
Очень много ошибок в коде.

1. Ты используешь в функции модификатора переменную $modx. А откуда она взялась? Её нужно пробросить через замыкание
...
$fenom->addModifier('dateformatter', function ($input)  use ($modx){
...
2. Загружать сервис не обязательно — он уже загружен.
3. Этот код содержит лишние строки
$output = $monthname; // Эта строка для чего?
return $output;
// Можно заменить на 
return $monthname;
4. Так как $monthname может быть не определена, в switch нужно добавить
default:
	$monthname = '';
Попробуй всё это собрать самостоятельно.
Вообще для ориентации удобней хлебные крошки. Кто-то вроде делал пакет с ними.
Для выделения добавьте в файл 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;
}