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

4. Как я понял, для каждого контекста нужно дублировать все задействованные ресурсы. Это так?

Так.

Означает ли это, что использовать разные [[*context_key]] в PHP скриптах на одних и тех же ресурсах невозможно?
Например, мы получаем

$item['en']

и передаем его в чанк.

Чтобы использовать один чанк для всех языков нужно в селекте указать соответствующее языку поле

$q = $modx->newQuery('Items');
//Указываем только одно поле, соответствующее языку
$q->select('id,name,'.$modx->getOption('cultureKey').' as item');
if ($q->prepare() && $q->stmt->execute()) {
	$output = '';
	while($row = $q->stmt->fetch(PDO::FETCH_ASSOC)) {
		// Тут оборачиваешь в чанк. В чанке должен быть плейсхолдер [[+item]],
		// в которое передается название предмета
		$output .= $modx->getChunk('твой_чанк',$row)
	}
}

И твой чанк будет работать во всех контекстах.
Главное, в настройках контекста указать ключ cultureKey с соответствующим значением.

Ответ тут.

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

Был уверен, что ты поймешь мой сарказм :) Особенно после этого

Также предлагаю расширить решение, чтобы можно было добавлять комментарии без ModX. Жутко не удобно.

Похоже, что разобрался со своей проблемой. Дело было в том, я пытался запустить добавление комментария непосредственно запросом к action.php без иницилизации сниппета «TicketComments»

Это действительно большая проблема. Народ уже давно мучается.

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

Надо переадресовать этот вопрос автору Tickets. Доколе народ будет мучатся, запуская всякие ненужные сниппеты?
Думаю, общество с удовольствием скинется для решения этой проблемы. Также предлагаю расширить решение, чтобы можно было добавлять комментарии без ModX. Жутко не удобно.

Хотя если требования не большие, то можно и календарем обойтись. Но без админки, только во фронт-энде.
Например, вот как вариант

Вы мне описали компонент бронирования, а это компонент календарь. Его, конечно, можно использовать для бронирования, но всю логику придется писать самостоятельно (и фронт-энд и бэк-энд) или просить кого-нибудь.

Нет тот скриншот поменял. :)

Мне кажется было бы удобнее, если бы на вкладе Авторы указывались не логины, а полное имя. Думаю, не многие смогут связать bezumkin с Василием Наумкиным. А уж про остальных вообще молчу — инкогнито.

Теперь можно.

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

Есть вот такой

if (!empty($autor))

Но можно и с пустой строкой. Смысл одинаковый.

Я имел ввиду логику называния переменных. В переменную автор сохраняется значение поля Город. :)

Часто клиенты постоянно висят на сайте и заставлять их выходить — не правильно и часто невозможно…

Абсолютно согласен. Но решения из коробки нет. Это нужно делать своими силами. Ссылку на решение я давал выше. Это не окончательное решение, оно для понимания. Дальше уж сами в зависимости от задачи. Для того, чтобы понять куда это прикручивать советую глянуть в сторону hybridAuth. Там изменения срабатывают немедленно (работает плагин).

Ну быстрее будет так

$query = $modx->newQuery('modUserProfile', array('internalKey'=> $modx->user->get('id')));
$query->select('city');
//Условие if ($autor != '') думаю лишнее
$_SESSION['gorod'] = $modx->getValue($query->prepare());

Можно и твой вариант. Но как ты правильно сказал вот это $autor = $profile->get('city'); точно похоже на порно.
Следуя твоему стилю можно было бы написать так

$page = $modx->getUser();
$car = $user->getOne('Profile');
$autor = $profile->get('city');
...

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

Я так понимаю, что эти 2 календаря на странице должны отображать разные события. И соответственно сохранять в разные календари разные события. А это в текущей информационной модели невозможно. Как события в таблице разделить по разным календарям?

если оторвать у eventCalendar механизм с возможностью &calendar_id=`cal3` должно работать?

eventCalendar просто выводит события. Он не может их сохранять. Поэтому там все проще.
Выход только один — переписывать все с нуля.

В этой версии только один календарь. Есть вот такая версия. В ней можно использовать несколько календарей. Но скорее всего, если заказчик разрешит её выложить, то не бесплатно.

Mission impossible.
П.С. Теперь знаю чем заняться вечерком.

В сниппете изменить/добавить условие

if (! $modx->user->isMember('manager')) {
	$scriptProperties['readOnly'] = true;
}

Ну уж такие простые вещи можно и самому попробовать сделать.

Не думаю, что в этом есть острая необходимость. Ну висят эти данные в сессии, никому не мешают. Когда пользователь повторно логинится, то эти данные обновляются.
Проблема только в том, что изменения данных пользователя не применяются немедленно. Для этого нужно выйти и зайти снова (logout->login).
А чтобы сессии почаще обновлялись, нужно уменьшить её время жизни в настройках (параметр session_gc_maxlifetime). Вот еще тема о борьбе со старыми сессиями.