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

Просто всё физически успеть сложно.

Если есть желание поддержать проект, то почему нет?

Есть ereplace, есть preg_replace модификаторы.

А JS исходники обновлять не стали? Компонент не поддерживает PHP7. Оригинальный редактор поддерживает.

1. Видимо нужна foolproof защита.
2. Или используем твой вариант с таблицей в виде префикса или такой

'select'=>[
    'modResource'=>'DISTINCT pagetitle as pagetitle',
],

Напомню, что можно работать напрямую с запросами через базовый API.

$query = $modx->newQuery('modResource');
$query->query['distinct'] = 'DISTINCT';
...

3. Это чудит xPDO. Он формирует запрос, а не pdoFetch. А вообще очень странная конструкция. Я бы так даже не додумался написать. Для сравнения на SQL сервере я бы написал так

'select'=>[
    'parent', 
    'SUM(published) = COUNT(*) as all_published'
],

Для сравнения на клиенте так

'select'=>[
     'parent', 
     'SUM(published) as all_published',
     'COUNT(*) as count'
],

А потом в цикле проверил бы на равенство два последних поля.
Но так как запрос простой и без логики, я бы не стал вообще использовать xPDO, а сделал бы маленький и лёгкий запрос (без кучи объектов xPDO)

$table = $modx->getTableName('modResource');
$sql = "SELECT parent, SUM(published) = COUNT(*) as all_published FROM $table GROUP BY parent";
$statement = $modx->prepare($sql);
if ($statement->execute()) {
    $result = $statement->fetchAll(PDO::FETCH_ASSOC);
}
4. Скорее всего тоже xPDO шалит. Проверю.

Спасибо!

Положил в копилку. Спасибо!

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

Спасибо! А я пью ;)

Не только мне одному пришла в голову подобная мысль. Только мне она пришла чуть раньше — 4 года назад. Middlewares. Сам пользуюсь и другие не жалуются.
Наверно и ты мог бы сэкономить своё время ;)

П.С. Ну а по тексту… Количество ошибок и опечаток расстраивает. Есть хорошее правило у редакторов — вычитывать текст перед публикацией. Событие «Добавление в корзину» меняет лого, хотя файл называется Title.php.

П.П.С. Кстати, обрати внимание, в моём компоненте не нужно прописывать добавленный метод в events.php. Он сразу срабатывает.

Упало. Спрячу на черный день )) Спасибо!

Спасибо за поздравление с тем, что я буду больше бесплатно работать. )))
Замена планировалась на основе modHelpers. Осталось написать замену сниппетам. Но я хотел заменить их на сервисы. Чтоб как у взрослых. Чем меньше MODX специфичных вещей, тем легче перемещаться между стеками. И легче заходить в MODX из тех же фреймворков.

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

Статические элементы и файловые элементы — семантически разные вещи. Последние не имеют дубля в БД. Лучше их не путать. Дополнительные настройки только запутают людей. В pdoTools есть системная настройка «pdotools_elements_path». Её определяет человек с правами на эту операцию. Если нужно переопределять папку с шаблонами согласно какой-то логике, контент-менеджер просит этого человека и тот пишет плагин, в котором переписывает настройку согласно задаче. Всё просто, логично и под контролем. Ну не должен контент-менеджер иметь права гулять по всей файловой системе.

Спасибо! С таким не сталкивался. Может это проделки xPDO? Вспомнишь, пиши.

Спасибо! С утра уже 2 американо от бариста. ;)

Вопросы безопасности закрою в самом ближайшем будущем. Для понимания, я нашел сайт, на котором смог вывести полный список пользователей. Заходить в админку не стал, просто написал админу сайта. А дальше запускается робот и собирает список для взлома. А подписчикам моего телеграм-канала я показывал, что контент-менеджер (человек с доступом только к ресурсам) может вывести любой файл на страницу и как пример вывел файл config.inc.php. Тоже самое можно сделать снаружи на плохо защищённых сайтах как в первом примере. Так что вопрос серьезный.

Прилетело. Спасибо за хороший кофе, но булочку заменю на хороший сыр. ))

Ну можно поступить проще — нажать сверху кнопочку «Поблагодарить автора» и угостить его хорошим кофе ;)

Да, планирую. Если парсер для страниц можно указать любой (в системной настройке) и отказаться от pdoParser'а, то чанки парсятся жестко только феномом на глядя на то, какой парсер указан в настройке. В принципе можно отключить феном для чанков (отдельной настройкой), то там другая засада — текущий парсер включится только если есть скобки [[. Т.е. ни смарти ни твиговские теги не распарсятся. Как-то так, если я ничего не путаю.

В общем, задача — чтобы pdoTools всегда использовал указанный в системной настройке парсер, который может быть pdoParser, SmartyParser (есть в ZoomX) или TwigParser (если такой будет).

Может я чего-то не понимаю, но получается совсем не короче. Этот путь из названия перемещается в параметр. Т.е. ещё нужно писать отдельный параметр. Что явно выглядит длиннее.

Ну теперь понятно. Только moderrorhandler — это замена PHP-шного обработчика ошибок и минишоп к нему никаого отношения не имеет. Он срабатывает, когда PHP спотыкается. А минишоп ругается через $modx->log().

И ещё, очень плохая идея держать лог ошибок в открытом доступе. Программистам по рукам давать надо.