Володя

• Раз — «как зайти на сервер crontab -e»
• Два — «что такое crontab»
• Три — «как зайти на сервер по ssh»

Зайти на сервер, там

crontab -e

И добавить команду

10 1    * * *   rm -rf /home/твойлогин/www/core/cache

Сохранить и выйти — кэш будет удаляться в 1:10 по времени сервера, каждые сутки.

1. Вполне себе рабочий вариант. Если сайт сделан не на костылях, то от очистки кэша раз в сутки ему ничего не будет — никто и не заметит.

2. Галочка есть в настройке страницы. Также есть разные системные настройки кэширования.

3. Не играет роли, сессии хранятся в БД и автоматически чистятся, согласно настроек MODX. Например, таблица с сессиями modx.pro сейчас весит всего 46мб.

4. Можно, конечно, но я бы сократил размер сайта:

Сайт после очистки кэша весит около 450 мб.

Первым делом почистить /core/packages — если ты не планируешь откатывать пакеты, то там нет ничего нужного. Очень часто эта директория весит мегабайт 200 — 300 и совершенно напрасно.

Вторым делом посмотреть, что у тебя там из файлов, картинок, видео? Может, стоит замутить источники файлов и вынести это дело куда-нить на Amazon?

Не за что.

Только еще момент: таким образом нельзя установить свойства, которых еще нет у объекта. К примеру, если у объекта нет свойства test, то нельзя сделать так: $object->test = $value; Свойства test у объекта после этого просто не будет. Вот здесь как раз и придется использовать $object->set($key, $val), чтобы свойство было создано. За эту магию отвечают ООП-методы __set() и __get() у класса xPDOObject. И вот здесь как раз кроется самое интересное (для этого смотрите сорцы xPDO github.com/modxcms/xpdo/blob/master/xpdo/om/xpdoobject.class.php#L739 ). Дело в том, что в методах __get() и __set() сразу прописана работа со связями getOne()/setOne() и т.д. и т.п.
К примеру, можно сделать так: $profile = $user->Profile, что будет равнозначно $profile = $user->getOne('Profile'). Таким образом можно получить свойство $user->Profile->email, даже если именно в этот момент еще не был получен связанный объект modProfile для этого пользователя. Или вот так:
$user = $modx->newObject('modUser', array(
«username» => «NewUser»,
));
$profile = $modx->newObject(«modUserProfile», array(
«email» => $someEmail,
«password» => $somePass,
));
$user->Profile = $profile;
$user->save();
И будут записаны в БД и данные пользователя (modUser), и данные его профиля (modUserProfile).

А что мешает напрямую устанавливать значение свойства?
$user = & $modx->user;
$user->password = 12345;
$user->save();

И будет у вас в таблице в чистом виде пароль 12345.

Значения свойств не обязательно устанавливать через метод ->set(), где выполняются всякие модификации и т.п., их можно устанавливать напрямую, если само свойство у объекта уже есть. Это так же, как вы не установите $user->set('sudo', true);, так как там проверка, и если поле — sudo, то обламывается. Зато можно установить $user->sudo = true; $user->save();

В итоге проблема решилась, на мой взгляд, изящнее, чем расширение класса modUser.

С версии 5.3 в php появились замыкания, а с версии 5.4 к ним добавили два метода: bind и bindTo. Подробнее о теории можно почитать тут.

Эти методы позваляют связать ваше замыкание с конкретным объектом, после чего замыканию становится доступен $this. То есть, фактически, мы можем добавить на лету произвольный метод классу и он будет выполняться в контексте класса.

В рассмотренном мной в заметке случае делается так:

$user = $modx->user;
$method = function($name, $value)
	{
		$this->_setRaw($name, $value);
		return $this->save();
	}

$method = $method->bindTo($user, 'modUser');
$method('password', '12345');

Вуа-ля! Защищенный метод нам доступен из любого класса, поскольку выполняется как будто изнутри класса modUser.