В head укажите тег base:

<base href="[[!++site_url]]">

Или если используете Fenom:
<base href="{'site_url' | config}">

Можно там так сделать, согласен. Тогда вопрос, как на стороне сервера понять кто делает запрос? Что именно этот пользователь?

Эх, молодежь. Всё делается гораздо проще. Ставим modHelpers и используем функцию snippet.

{snippet("mySnippet", ["param" => "value"], 604800)}  // сохраняем на неделю. Третий параметр лучше указать через массив (см. ниже)

А в cron удаляем кэш и парсим страницу сниппетом

... // инициализация MODX
// Лучше указать отдельную папку для хранения данных. Иначе данные будут лежать в папке cache/default, которая очищается при сохранении любого объекта MODX.
$options = array(
  cache_key => 'mysnippet_cache',
  cache_expires => 604800,
);
cache()->delete("mySnippet", $options);
snippet("mySnippet", ["param" => "value"], $options);

Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета!!! Обратите внимание, насколько код стал проще.

Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.

П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.

Проверил save(true) не работает :-(
А где делается кеш при загрузке странице в упор не могу найти

Вот такой вот многослойный торт.

Что-то торт слишком многослойный. Решение в теме выглядит бессмыслицей О_О. И в коммент «Смысл в быстродействии» тоже не въехать.
Я бы, наверно, поставил в крон что-то типа

$res_id = 1; // id нужного ресурса
define('MODX_API_MODE', true);
require_once $_SERVER['DOCUMENT_ROOT']."/index.php";

if($res = $modx->getObject("modResource",$res_id){
   $res->save(true);
}

из core\model\modx\modresource.class.php

public function save($cacheFlag= null) {
...

При сохранении ресурса с флагом $cacheFlag= true, кеш ресурса обновляется. Этим занимается метод toCache в core\xpdo\xpdo.class.php.
Наверно, можно при сохранении ресурса в админке сразу создавать его кеш. Переделав плагин Василия bezumkin.ru/sections/tips_and_tricks/351/. Только говорят кеш в MODX чистится весь из-за каких-то проблем. И не понятно, какие проблемы могут возникнуть, если кеш делать при сохранении в админке.

для нубов в modx, php или вообще программировании, типа меня, это будет полезным

ну если ты считаешь, что данный подход лучше чем использовать методы modx, ок.

я в этом ничего полезного к сожалению не увидел

1. результат парсинга заносим в контент;
2. чистим кэш только этого ресурса;
3. для обновления кэша пользователь должен зайти на страницу и получить задержку в несколько секунд (в моём случае), вместо этого мы заходим на страницу кроном.

мой велосипед это и делает, кроме заноса прямиком в контент и углубления в API MODX

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

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

разве после того, как записать результат в контент ресурса, не нужно будет очистить кэш этого ресурса, после этого обновить кэш этого ресурса, чтобы пользователь получил обновленную инфу?

а не проще сделать выполняемый с периодичностью по крону php скрипт который парсит данные и записывает результат в контент ресурса или допустим в тв поле?

Тогда этот скрипт хоть в 3 часа ночи запускай, хоть в 12 дня, когда обработка данных закончится он мигом запишет данные в ресурс и пользователь получит актуальную информацию.

Смысл в быстродействии.

У меня так: есть огромная страница, которую нужно спарсить раз в неделю и парсинг занимает много времени, если парсить каждый раз по окончанию действия кэша или ручной очистки кэша с админки, первому посетителю придется ждать десятки секунд (а он не будет ждать). Решил я парсить её cron-ом раз в неделю отдельным php скриптом, результат сохранять в файл на сервере (около 0.5 мб). Таким образом сниппет «snippetName» с примера выше, просто выполняет чтение и возврат этого файла «echo file_get_contents($file);», что существенно ускоряет время загрузки страницы если я очистил кэш вручную или время кэша закончилось. Потом я cron-ом выполняю запуск того самого php скрипта, который сохраняет результат в локальный файл. Вот такой вот многослойный торт.

Может path влияет
www.php.net/manual/ru/function.setcookie.php

path
Путь к директории на сервере, из которой будут доступны cookie. Если задать '/', cookie будут доступны во всем домене domain. Если задать '/foo/', cookie будут доступны только из директории /foo/ и всех ее поддиректорий (например, /foo/bar/) домена domain. По умолчанию значением является текущая директория, в которой cookie устанавливается.

Не совсем понял, а какую проблему решает данный сниппет?

Рад что помог :-). Спасибо скинуть это хорошо :-). В моем профиле кнопка «Отправить деньги». Но на мат.вознаграждение не рассчитывал :-). И если что-то отправите, то все по вашему желанию :-)

аааааа! ты лучший! куда спасибо скинуть?)
очистка таблицы решила проблему, но тем не менее надо бы разобраться, как правильно назначать права контент-менеджерам, но уж с этим как-нибудь, думаю, разберусь))

А if тут не самый лучший выбор. github.com/fenom-template/fenom/blob/master/docs/ru/tags/switch.md

{switch $idx % 7}
{case 1, 2}
    ...
{case 3}
    ...
{case default}
    ...
{/switch}

Спасибо, реализовал. Если кому нужно, вот код:
Код чанка:

{if ($idx % 7) == 1 || ($idx % 7) == 2}
  <div class="col-lg-6 col-md-6 col-sm-12">
	<article class="big-news-main-container">
	  <div class="post-box">
		<img src="[[+tv.image:phpthumbof=`w=800&h=533&zc=1&q=100`]]" alt="[[+longtitle]]">
		<div class="entry-content">
		  <h3><a href="[[~[[+id]]]]" title="[[+pagetitle]]">[[+pagetitle]]</a></h3>
		</div>
	  </div>
	</article>
  </div>
{else}
  {if ($idx % 7) == 3}
	  <div class="col-sm-12">
		<article class="full-news-main-container">
		  <div class="type-post">
			<div class="entry-content">
			  <h3 class="entry-title"><a href="[[~[[+id]]]]" title="[[+pagetitle]]">[[+pagetitle]]</a></h3>
			  <div class="publication-data">
				<p class="byline">[[*createdby:userinfo=`fullname`]]</p>
				<p class="post-date"><i>[[+publishedon:dateRU]]</i></p>
			  </div>
			  <p>[[+introtext]]</p>
			  <p class="tags-preview">
				[[!tolinks? 
				&items=`[[+tv.tags]]`
				&tpl=`tagLinkTpl`
				&target=`117`
				]]
			  </p>
			</div>
		  </div>
		</article>
	  </div>
	{else}
	<div class="col-lg-3 col-md-6 col-sm-12">
	  <article class="small-news-main-container">
		<div class="type-post">
		  <div class="entry-cover">
			<a href="[[~[[+id]]]]"><img src="[[+tv.image:phpthumbof=`w=800&h=533&zc=1&q=100`]]" alt="[[+longtitle]]" /></a>
		  </div>
		  <div class="entry-content">
			<h3 class="entry-title"><a href="[[~[[+id]]]]" title="[[+pagetitle]]">[[+pagetitle]]</a></h3>
			<div class="publication-data">
			  <p class="byline">[[*createdby:userinfo=`fullname`]]</p>
			  <p class="post-date"><i>[[+publishedon:dateRU]]</i></p>
			</div>
			<p>[[+introtext]]</p>
			<p class="tags-preview">
			  [[!tolinks? 
			  &items=`[[+tv.tags]]`
			  &tpl=`tagLinkTpl`
			  &target=`117`
			  ]]
			</p>
		  </div>
		</div>
	  </article>
	</div>
	{/if}
{/if}

Код вызова чанка:

[[!pdoPage?
&element=`pdoResources`
&parents=`[[*id]]`
&tpl=`allPostTpl`
&includeTVs=`image,tags`
&hideContainers=`1`
&limit=`0`
]]

jquery $.post знаете? :-) на стороне сервера делаете скрипт, что вытаскивает данные и по ajax с него выдергиваете данные. А точных инструкций не дам. Вариантов реализации куча. Например можно посмотреть реализацию ajaxForm и от нее отталкиваться.

проверте таблицу modx_access_category
Она по идее должна быть пустой. Если там что-то есть, то вы наверно доступ манагерам к категориям элементов ограничивали. То есть, кому-то дали права а остальным облом. В том числе и анонимам. Если я, конечно, верно код интерпритировал. Доступ к категориям редактируется здесь yadi.sk/i/4CM-C0bYWRRFjg
Если у кого-то доступ настроен, то надо и анонимам сделать аналогично. Только контекст на web поменять.