Дмитрий Кондаков

У меня на сайте, например, бывают платные разделы. Чтобы добавить пользователю доступ в них при оплате, работает вот такой плагин:

case 'OnWebPageInit':
if ($uid = $modx->user->id) {
	if ($extended = $modx->user->Profile->get('extended')) {
		if (!empty($extended['updateGroups'])) {
			unset($_SESSION['modx.user.'.$modx->user->id.'.userGroupNames']);
			$extended['updateGroups'] = 0;
			$modx->user->Profile->set('extended', $extended);
			$modx->user->Profile->save();
			
			$ctxQuery = $modx->newQuery('modContext');
			$ctxQuery->select($modx->getSelectColumns('modContext', '', '', array('key')));
			if ($ctxQuery->prepare() && $ctxQuery->stmt->execute()) {
				if ($contexts = $ctxQuery->stmt->fetchAll(PDO::FETCH_COLUMN)) {
					$serialized = serialize($contexts);
					$modx->exec("UPDATE {$modx->getTableName('modUser')} SET {$modx->escape('session_stale')} = {$modx->quote($serialized)}");
				}
			}
		}
	}
}
break;

Написан давно, работает без нареканий.

Для разлогинивания заблокированных пользователей использую вот такой код в том же плагине:

if ($modx->user->id) {
	if (!$modx->user->active || $modx->user->Profile->blocked) {
		$modx->runProcessor('security/logout');
		$modx->sendRedirect('/');
	}
}

Если это всё не то — прошу прощения.

Сниппеты MODX могут возвращать исключительно строки, так уже повелось. $modx->fromJSON не нужен, Fenom умеет сам это делать:

{set $result = json_decode($_modx->runSnippet('snippet'), 1)}

Можно еще вот так:

{var $resources = $_modx->getResources(
    ['published' => 1, 'deleted' => 0],
    ['sortby' => 'id', 'sortdir' => 'ASC', 'limit' => 50]
)}
{foreach $resources as $resource}
    {$_modx->getChunk('@INLINE <p>{$id} {$pagetitle}</p>', $resource)}
{/foreach}

Но это только для ресурсов.

Искренне печалит, что нет (и я так понимаю, не планируется) вообще никакой документации.

Нашел я, в чем проблемка. На Shared-хостингах распространена практика использования связки NGINX и Apache. В этом случае вся статика (картинки и текстовые файлы) обрабатывается NGINX'ом, а php-файлы обрабатывает Apache.

Таким образом, файл /core/docs/changelog.txt будет доступен независимо от того, что указано в .htaccess, а MODX проверяет доступность именно этого файла.

Выход один. Сначала проверить, что у вас не открывается в браузере файл /core/cache/logs/error.log, а потом просто удалить файл changelog.txt

Тогда ошибка исчезнет.

На самом деле предложенный багфикс вполне может спасти вашу работу. gist.github.com/Fi1osof/ff3ea018841b1bb1f99b
Обновите этот класс и все. Других ошибок я не обнаружил. Так же при наличии файла core/model/modx/processors/element/propertyset/update.class.php (если вы обновлялись, а не устанавливали с нуля, должен присутствовать), можно просто удалить файл core/model/modx/processors/element/propertyset/updatefromelement.class.php, все должно работать.

Проверил на скорую руку, вроде работает:
1. Берем файл для Smarty.
2. Загружаем его на сервер как /assets/components/ace/ace/mode-smarty.js
3. В файле /assets/components/ace/modx.texteditor.js на 7й строке меняем mode c text на smarty.
4. Хорошенько чистим кэш браузера

Результат:

В итоге для категорий товара я пришел к простому решению, в 2 этапа:
1)сниппет с 1 sql запросом и рекурсивной генерацией меню, для большей быстроты генерации на лету вес можно еще хранить
2)js скрипт который пробегается по дереву и проставляет текущий пункт и родителей

Скорость генерации сократилась с 10s до 1s при первом вызове и потом до 0.05s при кешировании

hashcode.ru/questions/376081/php-%D0%BA%D0%B0%D1%81%D1%82%D0%BE%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%BA%D0%B8-modx

сталкивался с подобный Василий подсказал что в системную настройку session_cookie_domain нужно добавить .sitename.ru

Я для себя написал универсальную функцию изменения системной настройки, которая 100 пудов её изменяет и новое значение доступно сразу же и без дальнейших причуд:

function changeSetting ($key = '', $value, $config = array()) {
  global $modx;

  if (empty($key)) { return false; }

  /* @var $response modProcessorResponse */
  $response = $modx->runProcessor('system/settings/update', array_merge(array(
    'key' => $key,
    'value' => $value,
    'namespace' => 'core'
  ), $config));

  if ($response->isError()) {
    $modx->log(modX::LOG_LEVEL_ERROR, '[avk] Cann\'t update setting with messages: '. print_r($response->getAllErrors()));
    return false;
  }
  $modx->reloadConfig();
  return true;
}

Вызывать надо вот так:

changeSetting('pdoFetch.class', 'pdotools.mypdofetch', array(
  'namespace' => 'pdotools'
));

Namespace указывать надо обязательно, если настройка из стороннего компонента.