А зачем переписывать работающие сайты? Нервы пощекотать? Например, с выходом новой мажорной версии Laravel сайты в большинстве случаев не обновляют. Это для новых проектов.
сложно ли это?
Сделать можно всё. Но если честно, у меня нет никакой мотивации этим заниматься.
Жаль, что не прислушались к моей рекомендации шифровать параметры и сохранять их в форме. Данных получится не больше 1Кб. Уверен, даже мобилы потянут. А плюсов много — можно использовать как CSRF токен, не нужна инвалидация кэша (эта проблема решается в текущем обновлении?), привязка не к сессии, а к пользователю.
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». Её определяет человек с правами на эту операцию. Если нужно переопределять папку с шаблонами согласно какой-то логике, контент-менеджер просит этого человека и тот пишет плагин, в котором переписывает настройку согласно задаче. Всё просто, логично и под контролем. Ну не должен контент-менеджер иметь права гулять по всей файловой системе.
Вопросы безопасности закрою в самом ближайшем будущем. Для понимания, я нашел сайт, на котором смог вывести полный список пользователей. Заходить в админку не стал, просто написал админу сайта. А дальше запускается робот и собирает список для взлома. А подписчикам моего телеграм-канала я показывал, что контент-менеджер (человек с доступом только к ресурсам) может вывести любой файл на страницу и как пример вывел файл config.inc.php. Тоже самое можно сделать снаружи на плохо защищённых сайтах как в первом примере. Так что вопрос серьезный.
Сделать можно всё. Но если честно, у меня нет никакой мотивации этим заниматься.
Первый блин… За композером не углядел. Выпустил 2.13.1 версию с исправлением.
2. Или используем твой вариант с таблицей в виде префикса или такой
Напомню, что можно работать напрямую с запросами через базовый API.
3. Это чудит xPDO. Он формирует запрос, а не pdoFetch. А вообще очень странная конструкция. Я бы так даже не додумался написать. Для сравнения на SQL сервере я бы написал так
Для сравнения на клиенте так
А потом в цикле проверил бы на равенство два последних поля.
Но так как запрос простой и без логики, я бы не стал вообще использовать xPDO, а сделал бы маленький и лёгкий запрос (без кучи объектов xPDO)
Наверно и ты мог бы сэкономить своё время ;)
П.С. Ну а по тексту… Количество ошибок и опечаток расстраивает. Есть хорошее правило у редакторов — вычитывать текст перед публикацией. Событие «Добавление в корзину» меняет лого, хотя файл называется Title.php.
П.П.С. Кстати, обрати внимание, в моём компоненте не нужно прописывать добавленный метод в events.php. Он сразу срабатывает.
Замена планировалась на основе modHelpers. Осталось написать замену сниппетам. Но я хотел заменить их на сервисы. Чтоб как у взрослых. Чем меньше MODX специфичных вещей, тем легче перемещаться между стеками. И легче заходить в MODX из тех же фреймворков.
Статические элементы и файловые элементы — семантически разные вещи. Последние не имеют дубля в БД. Лучше их не путать. Дополнительные настройки только запутают людей. В pdoTools есть системная настройка «pdotools_elements_path». Её определяет человек с правами на эту операцию. Если нужно переопределять папку с шаблонами согласно какой-то логике, контент-менеджер просит этого человека и тот пишет плагин, в котором переписывает настройку согласно задаче. Всё просто, логично и под контролем. Ну не должен контент-менеджер иметь права гулять по всей файловой системе.