Cyrax_02

Прежде хочу убедиться, что данный артефакт наблюдается не только у меня.

Это уже от предметной области зависит. Если удалённый ресурс в дальнейшем восстанавливается, то его бывшие дочерние ресурсы так и останутся у другого «родителя» (и никак их не выследишь, чтобы снова привязать к восстанавливаемому «родителю»).
А с помощью запроса (например, в myAdmin), всегда можно найти и перепривязать все «подвешенные» ресурсы после очистки корзины. Этот же запрос можно и на xPDO составить, а перепривязывать через процессор 'resource/update'.

Можно перегрузить процессор очистки корзины, чтобы все подчинённые ресурсы окончательно удаляемых ресурсов перемещались в определённое место (или к родителю окончательно удаляемого ресурса). Только для этого нужно будет где-то хитро подменить процессор.

Вот текст собственного процессора удаления ресурса:

<?php
if(!class_exists('modResourceDeleteProcessor')) {
    global $modx; include $modx->config['processors_path'].'resource/delete.class.php';
}
class sResourceDeleteProcessor extends modResourceDeleteProcessor {
    
    public function deleteChildren() {
        if($this->getProperty('deleteChildren', true)) {  // в modResourceDeleteProcessor дочерние ресурсы удаляются всегда
            return parent::deleteChildren();
        } else {
	    return array();
	}
    }
    public function clearCache() {
        if($this->getProperty('syncsite', true)) {  // в modResourceDeleteProcessor кэш очищается всегда
            parent::clearCache();
        }
    }
}
return 'sResourceDeleteProcessor';

Если файл с этим процессором имеет имя «sdelete.class.php» и лежит там же, где и все прочие стандартные процессоры modx, то вызов будет выглядеть так:

$properties = array('id' => $resourceId, 'deleteChildren' => false, 'syncsite' => false);
$response = $modx->runProcessor('resource/sdelete', $properties);

Если файл с процессором лежит в собственной папке PROC_PATH и имеет имя «sResourceDeleteProcessor.class.php», то вызов будет таким:

$properties = array('id' => $resourceId, 'deleteChildren' => false, 'syncsite' => false);
$options = array('processors_path' => PROC_PATH);
$response = $modx->runProcessor('sResourceDeleteProcessor', $properties, $options);

=============================================================================================
1.В данном примере реализовано опциональное отключение удаления дочерних ресурсов и очистки кэша. И реализовано это на базе те же самых свойств, которые передаются вторым параметром в метод modX::runProcessor().
2. Отключать очистку кэширования может быть полезно при пакетной обработке ресурсов для сокращения времени обработки. Аналогично можно отключить и логирование (перегрузкой метода modResourceDeleteProcessor::logManagerAction())

3.В процессорах «resource/create» и «resource/update» параметр «syncsite» уже обрабатывается (по умолчанию syncsite = true), тогда как стандартный процессор «resource/delete» кэш очищает всегда
4.При обработке ресурсов кэш очищается только в следующих разделах: 'db', 'auto_publish', 'context_settings' и 'resource'

Улучшенный invokeEvent() выглядит приблизительно так же, как и улучшенный парсинг тегов:
а) запросы на чистом pdo
б) отказ от объектов
в) г) д) — в invokeEvent не используется

Парсер Василия, вроде, так и работает (это если вдруг кто-то захочет заминусовать меня за «отказ» от объектов).

Свой парсер я включаю/отключаю в настройках (как и всё остальное). А делать два core только из-за собственного modx'а, думаю, и не стоит. Поскольку там всего 4 файла, в каждом из которых в одном месте достаточно изменить modX на smodX и наоборот (чтобы вернуться к стандартному modX).

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

Что касается вопроса изменения системных файлов и лучшего из предложенных вариантов — с вами полностью согласен — вариант 1 является наиболее корректным. А именно, в озвученных 4 файлах достаточно фрагмент

$modx= new modX...

заменить на:

include dirname(dirname(MODX_CORE_PATH))).'/assets/smodx.class.php';
$modx= new smodX...

где smodx.class.php — файл с объявлением нашего класса smodX, наследующего стандартный класс modX.

И дело в шляпе…

1) Ускорение invokeEvent(). Этот метод выполняет код плагинов, повешенных на указанное событие, и реализует практически ту же логику, которая имеет место при обработке сниппетов (тот же самый modScript). Т.е. если возникает задача ускорения парсинга документа (собственный парсер), то логично заняться и ускорением метода invokeEvent(). Поскольку invokeEvent() — это та же самая обработка сниппетов, только код извлекается из плагинов.
2) Появляется возможность отслеживать время подключения классов, время инициализации, время выполнения запроса (modX::getRequest) и многих других операций, выполняемых modx, избавив себя от гаданий, почему modx «тормозит».
3) В момент инициализации modx (modX::initialize()) можно свободно подключать любые файлы (например, собственные библиотечные функции и классы), не обременяя себя строгой логикой пакетов. Эта возможность особенно актуальна, когда необходимо подключить все файлы из некоторой директории.

P.S. «Тайный поклонник» обязательно заминусует этот пост. Можно ставки делать ))

У первого поста минус исчез. Возможны 2 варианта:
1) Минус с первого поста на 2-й перенёс модератор, посчитав его необоснованным
2) За первый пост кто-то поставил плюс, компенсировав тем самым минус «Тайного поклонника»

Появился какой-то тайный поклонник, который меня неконструктивно минусует.
Очень напоминает позу позицию Запада в отношении России.

SendForward так и работает ;)

Но ведь он не меняет URL + GET-параметры нельзя указать:

modX::sendForward
Forwards the request to another resource without changing the URL. If the ID provided does not exist, sends to a 404 Error page.

В момент загрузки страницы url сайта (страницы) уже сформирован. Веб-сервер его уже «проглотил», modx тоже. И инициировать процесс обработки веб-сервером другого url можно только редиректом. А «подменить» уже обрабатываемый url другим в ходе выполнения скрипта — попахивает каким-то низкоуровневым хаком, мне неизвестным.

Всё-таки, функция func_getCurrentURL вам не нужна. Я подумал, что на основе текщего url вам нужно получить новый url с добавленными параметрами (при этом параметры в исходном url могут быть произвольными) — именно так я получаю ссылки для пагинации (путём изменения/добавления параметра page текущему url).

В вашем случае текущий URL и не нужен вообще, нужны только параметры.
Изменить (добавить) параметры при обработке текущего запроса можно 2 способами:

1) «Железный» вариант: на уровне .htaccess (директива redirect с использованием регулярных выражений)

2) В обработчике OnLoadWebDocument (с максимальным приоритетом = 0) добавить недостающие параметры (можно также удалить ненужные) в глобальные массивы:
а) при передаче данных методом POST: $_REQUEST + $_POST
б) при передаче данных методом GET: $_REQUEST + $_GET

И далее в любых сниппетах, функциях, классах, плагинах для получения параметров запроса использовать:
а) либо эти самые глобальные массивы
б) либо метод $modx->request->getParameters($keys, $type) (этот метод как раз и использует вышеуказанные глобальные массивы):

getParameters( string|array $keys = array, string $type = GET )
Get a GPC/REQUEST variable value or an array of values from the request.

Arguments
$keys
stringarray
A key or array of keys to retrieve from the GPC variable. An empty array means get all keys of the variable.
$type
string
The type of GPC variable, GET by default (GET, POST, COOKIE or REQUEST)

Вот функция для определения текущего URL:
[correctMode = true] url формируется на основе текущего ресурса по правилам modx — «устойчивый» вариант
[correctMode = false] url формируется из строки запроса

function func_getCurrentURL($correctMode = false) {
        global $modx; $url = '';

        if($correctMode) {
            static $urlCorrectMode; if(!isset($urlCorrectMode)) {
                
                $resourceId = $modx->resource->get('id');
                $context = $modx->resource->get('context_key');
                $parameters = $modx->request->getParameters();
                $urlCorrectMode = $modx->makeUrl($resourceId, $context, $parameters, 'full');
                $urlCorrectMode = htmlspecialchars_decode($urlCorrectMode);
            }            
            $url = $urlCorrectMode;
            
        } else {
            static $urlFast; if(!isset($urlFast)) {
            
                $defaultPort = 80;  // порт по-умолчанию
                $schemeDelimiter = '://';
            
                // Схема
                if(((string)func_getArrayValue($_SERVER, 'HTTPS', '')) === 'on') {  // защищённый режим
                    $urlFast .= 'https'.$schemeDelimiter;
                    $defaultPort = 443;
                } else {
                    $urlFast .= 'http'.$schemeDelimiter;
                }
                // Имя сервера
                $urlFast .= $_SERVER['SERVER_NAME'];
            
                // Порт
                if((int)func_getArrayValue($_SERVER, 'SERVER_PORT', -1) !== $defaultPort) {
                    $urlFast .= ':'.$_SERVER['SERVER_PORT'];
                }
                // Путь и параметры
                if(array_key_exists('REQUEST_URI', $_SERVER)) {
                    $urlFast .= $_SERVER['REQUEST_URI'];
                } else {
                    if (array_key_exists('QUERY_STRING', $_SERVER)) {
                        $urlFast .= $_SERVER['SCRIPT_NAME'].'?'.$_SERVER['QUERY_STRING'];
                    } elseif(array_key_exists('SCRIPT_NAME', $_SERVER)) {
                        $urlFast .= $_SERVER['SCRIPT_NAME'];
                    } else {
                        $urlFast .= $_SERVER['PHP_SELF'];
                    }
                }
            }
            $url = $urlFast;
        }
        return $url;
    }

А дальше добавить параметры — элементарно.

а) время изменения файла, отображаемое на странице редактирования файла в modx, отображается серверное, независимо от значения (server_offset_time)

Как оказалось, время изменения файла, отображаемое на странице редактирования файла в modx, — это не серверное время и не локальное время админа. Это время, соответствующее php-настройке date.timezone (в моём случае оно совпадает с серверным временем). Т.е. modx просто считывает дату файла с помощью filemtime (все php-функции, работающие со временем, используют date.timezone) и отображает её в строковом виде. Никаких преобразований времени не производит.
Хотя логичнее было бы преобразовать это время сначала в UTC, затем в серверное, затем в локальное админское (с учётом server_offset_time) и только после этого отображать.

Аналогично modx поступает и с отображением даты публикации/создания/модификации ресурса — считывает из БД и отображает без всяких преобразований (этот факт делает нецелесообразным использование настройки date.timezone = UTC, которая в определённом смысле является более корректным вариантом).

Здесь возникает 2 вопроса:
1) Зачем нужна настройка server_offset_time?
2) Почему (и каким образом) при задании ненулевого server_offset_time время изменения файла, отображаемое в WinSCP, на server_offset_time превышает серверное время изменения файла?

Сейчас из всего стороннего я использую только pdoTools::getChunk() и minifyX. Да и то — в настройках их можно отключить — и сайт по-прежнему будет работать на базовом функционале без изменения кода (чуть медленнее, но будет работать). Т.е. если что-то перестанет работать, его отключаю и спокойно отлаживаю). Именно такой логики работы изначально придерживаюсь при использовании небазовых компонентов.
Всё остальное (включая pdoResources, пагинация и т.д. и т.п.) реализовано на собственных функциях, классах, обвязках.

P.S. А теперь ждём конструктива от автора минуса…

Под «обходиться стандартным функционалом modx» я имею ввиду «по возможности не использовать third-party-код». Т.е. по возможности стандартный функционал modx + собственный код (который находится под твоим собственным контролем).

А обоснование выставленному минусу будет? Или это не принято?
Я сторонник конструктива — а Вы?

По возможности я стараюсь обходиться стандартным функционалом modx. Только в этом случае при обновлении версии modx гарантированно не будет никаких серьёзных проблем.

Я плейсходер — я потерялся? Будет просто пусто…

Нет. Будет замаскированный плейсхолдер. Или Вы под «маскировкой» поняли удаление из html? Если удалять, то потом не вычислишь позицию вставки в html.

И даже если ты определишь что потерялось что дальше с этим делать?

Исправлять логические ошибки.

Если что-то и «потеряется», то оно «вылезет» в конечном html.