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

Также как и в обычном шаблонизаторе. MODX парсер перед обработкой чанка выгружает все плейсхолдеры, а после обработки загружает обратно.

П.С. Доберусь до компа, попробую. Главное — не забыть! )

Давным-давно в далёкой галактике пытался комбинировать феном синтаксис с модыксовским

{[$chunkName]}
{[!snippetName] : ['param' => 'value']}

Уже не помню, на чём забуксовал — не пошло или лень стало. Но получилось бы прикольно. )

На данный момент родной «шаблонизатор» в modx просто нельзя назвать шаблонизатором — он не справляется с большинством типовых задач шаблонизации, это же очевидно.

Слова человека, воспитанного на фреймворковских шаблонизаторах. Ещё раз повторю, ты просто не вник в механизм «скрипки». Он без проблем справится с любыми задачами. Просто ты пытаешься решить её также как в других шаблонизаторах, а в MODX логика другая. И чем дальше, тем она всё менее понятная для современных разработчиков. А в былые времена пилили серьёзные проекты. Тот же Tickets — очень мощная система для блога. Или сниппеты pdoTools. Даже в них ещё старый подход — логика с кучей чанков без фенома. И всё замечательно работает.

Но в современном мире разработки — это уже анахронизм. Ибо фреймворки захватывают мир разработки. Они двигают свои стандарты.

Да, вот если бы в нем был такой функционал, то это был бы полноценный шаблонизатор, со своими фичами и идеей, и это было бы круто.

Был бы ещё один шаблонизатор похожий на другие, но в отличие от них (универсальных), он использовался бы только в MODX. А значит судьба его была бы предрешена. И зачем тогда на него тратить время?

Но и с другими шаблонизаторами в MODX ситуация не лучше. Попробуй написать таблицу умножения римскими цифрами. Тот же Fenom заставляют работать в парадигме шаблонизации MODX, а у него другая логика. Я об этом тоже уже много раз говорил.

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

{$_modx->resource}
{$_modx->user}

и почему нельзя было эти массивы выделить в отдельные переменные

{$resource}
{$user}

Это сформированные массивы из глобальных объектов, которые есть в каждом запросе. Зачем их засовывать в объект $_modx? По привычке наверно.

Поэтому по большому счету их даже некорректно сравнивать, у них разное предназначение,

Если тебе гитара нравится больше, чем скрипка, это ещё не значит, что скрипка не музыкальный инструмент. Ребята из MODX в своё время придумали альтернативную парадигму шаблонизации, в которой всю логику засунули в сниппеты. Она реально лаконичнее. Согласен с @Руслан Алеев — теги короткие и понятные даже для непрограммистов. Страница выглядит легче и привычнее. Что, кстати, поддерживается стандартами разработки — меньше логики во вьюхах. Но другое дело, что его перестали совершенствовать. Впрочем, как и MODX в целом и xPDO. Думаю, можно было допилить шаблонизатор до какого-нибудь гибрида с обычными шаблонизаторами. Я в своё время экспериментировал, но потом решил, что староват я для велосипедостроительства.

Я недавно писал про парсер MODX, про специфику и недостатки. В текущее время, с развитием стандартов и большого количества готовых и универсальных шаблонизаторов, парадигма шаблонизации в MODX выглядит как минимум странно.

Один маленький замечаний по коду

$id = session_id();

выкладывать идентификатор сессии в публичный доступ из вэри бэд. Это слив куки.

Это не страшная ошибка. Возникает, когда кэшменеджер не может записать данные в файл. Возможно из-за блокировки последнего другим процессом. Можно забить.

Кэшменеджер срабатывает при каждом создании продукта и заново создаёт и кэширует все данные контекста. Хотя единственное, что меняется — карта алиасов. А в системных настройках для больших сайтов кэширование карты алиасов советуют отключать. Так что, единственная проблема, которая может возникнуть — это ошибка при обращении к странице, для которой не сохранились данные в карте алиасов. Но и она маловероятна, так как на последующих итерациях карта будет пересоздана. Очень маленький шанс, что эта ошибка случится на самой последней итерации. Тогда придется чистить кэш, чтобы он пересоздался. Для этого достаточно удалить кэш контекста web.

Нет. Тут по сути похоже — одноразовый токен, выданный на тот же ip и браузер, с которого запросили вход…

Видел вот такое решение…

Навести мышкой на заголовок, кликнуть на стрелку в конце и отметить галочками нужные столбцы.

Я бы на его месте занялся саморазвитием. Поднимать самооценку делая гадости другим деструктивно действует на личность. В этом плане религия усиливает нравственный фундамент человека, раз уж государство сняло с себя обязательство по воспитанию детей. Я сейчас не про церковь говорю.

Я уже с устоявшейся периодичностью кидаю одну и ту же ссылку на документацию. Почему их никто не читает? Буквально два коммента назад писал.

П.С. Заметил, что у нас появился злой бот по имени Slava, который всем тупо минусы ставит. Вот и Андрея он не взлюбил. У меня ни одного коммента не пропускает. Какие-то проблемы у парня. Даже не знаю, чем ему помочь. Может побольше комментов писать, чтобы он душу отводил ставя минусы?

Это можно сделать как в интерфейсе, так и программно.

Не знаю что делать.

Читать документацию.

А предыдущие комментарии не отвечают на этот вопрос?

То есть алгоритм такой:
1) создать ресурс минишопа
2) добавить номер в справочник и указать для него ресурс минишопа

Или так или так

Если при создании объекта бронирования не указать ресурс минишопа, то он будет создан автоматически.

Ресурс будет создан в категории товаров, указанной в настройке.

И еще вопрос. Какие плейсхолдеры у obSearch? Я смогу через него выводить свойства и опции минишопа, TV? Другими словами я смогу полноценно выводить/фильтровать каталог ресурсов минишопа по дате бронирования или этот сниппет выводит только номера из справочника?

Только номера из справочника.

Связь жесткая. Если при создании объекта бронирования не указать ресурс минишопа, то он будет создан автоматически.

assets/components/easycomm/action.php

Вполне возможно, что в этом файле и выдаётся «access denied». Нужно просто открыть его и посмотреть.

Возможно ли из-за того, что на разных доменах находятся адмика и фронт часть?

В теории нет.

$p = $this->modx->getObject('modResource', $product);
$id = $p->get('id');

Я правильно понимаю, что $product и $id будут идентичны? Вот думаю, удивляться или уже пора перестать.

Ответ.