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

Планирую. Только мысль о других шаблонизаторах не чтобы народ из MODX убегал на другую платформу, познакомившись с разработкой на фреймворках, а и обратное движение. Досталось челу из Symfony или Laravel стека MODX на поддержку, он без проблем с этим справится.

А зачем переписывать работающие сайты? Нервы пощекотать? Например, с выходом новой мажорной версии Laravel сайты в большинстве случаев не обновляют. Это для новых проектов.

сложно ли это?

Сделать можно всё. Но если честно, у меня нет никакой мотивации этим заниматься.

Жаль, что не прислушались к моей рекомендации шифровать параметры и сохранять их в форме. Данных получится не больше 1Кб. Уверен, даже мобилы потянут. А плюсов много — можно использовать как CSRF токен, не нужна инвалидация кэша (эта проблема решается в текущем обновлении?), привязка не к сессии, а к пользователю.

Исправил. Походу всё-таки придётся писать тесты. Самому уследить за всем очень сложно.

Проверяйте перед релизом.

Первым делом поставил на свой сайт. Прогнал все страницы. Ничего не сломалось. Единственное, что повылезало

[pdoTools] The "tplPath" and "elementsPath" parameters are deprecated and will be removed in the next version.

Первый блин… За композером не углядел. Выпустил 2.13.1 версию с исправлением.

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

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

Есть 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. Тоже самое можно сделать снаружи на плохо защищённых сайтах как в первом примере. Так что вопрос серьезный.