45 минут назад
Никак не получается настроить. Ошибка такая же как выше писали. Уже раз 100 перепробовал.
AMO CRM - решение бага с получением токена авторизации. 15
2 часа назад
Огонь, очень круто!
MiniShop3: Notification Center — Революция в управлении уведомлениями 2
30 ноября 2025, 16:21
Надеюсь все решится все в ближайшее время
ImgsPaste - дружелюбная вставка фотографий из ms2Gallery, MIGX в контент 52
28 ноября 2025, 17:12
Ребята, это нормально что при в режиме Импорт товаров — недоступен импорт остатков (msProductRemains)?
А в режиме импорта остатков не доступны TV и г...
msImportExport 918
26 ноября 2025, 11:39
Дмитрий. первые две строки в вашем логе — это не ошибки. Это предупреждения о плохом коде. Они сами по себе ничего не ломают.
Настоящая проблема у в...
Релиз miniShop2 ver. 4.4.1 & 4.4.2 18
25 ноября 2025, 13:49
Здравствуйте, устанавливаем msProductRemains перестаёт добавлять в корзину, по логам добавляет, на странице корзины ошибка minishop2 not defined и соо...
[msProductRemains] Остатки без свойств и другое 3
25 ноября 2025, 07:08
Отлично. Ну еще проблему с путями решить и норм) Но судя по комментам о Thumb2x, картинки весят больше, чем после обработки pthumb — что тоже ставит н...
Thumb3x: Современная обработка изображений для MODX 3 34
24 ноября 2025, 21:36
Этого не будет
Thumb2x — это мощный и гибкий компонент для обработки изображений 8
Всего 125 355 комментариев
Подкидываю альтернативную идею, если интересно — проверять версию MODX (или брать из настроек), скачивать соответствующий дистрибутив, и проверять хэши файлов сайта по файлам дистрибутива.
То есть, берём оригинальные файлы index.php в connectors, manager и корне, а так же файлы из core — и проверяем, чтобы все они присутствовали на сайте с оригинальным хэшем.
Если все основные файлы не изменены, то сайт не заражён и должен работать корректно.
Правда, есть еще возможность заражения только файлов дополнений, без ядра. Наверное, можно и их сверять с дистрибутивами из репозитория по той же логике — скачать нужную версию и сравнить хэши…
Кстати, вот вам еще идея — создать онлайн базу для проверки хэшей файлов MODX и дополнений через API. Чтобы простые GET запросы, типа /api/hash/modx/2.8.1/core/model/modx.class.php возвращали sha1 хэш запрошенного файла или 404.
Конечно, это не спасёт от уже залитых шеллов и вредоносов, но они не будут запускаться через сайт. А если запустятся и что-то изменят, то следующая проверка это покажет. И если раз за разом файлы будут меняться — то можно уже более внимательно искать, что там такое у вас залито.
И кажется ты не понимаешь что это за магические письмена
Первым аргументом в метод leftJoin передаётся имя класса ('goodStarVoteCount'); вторым псевдоним для таблицы ( 'countaverage'), если не передать будет взято имя класса; третьим аргументом передаётся условие соединение таблиц как в операторе ON в SQL ( 'modResource.id = countaverage.thread').
На чистом SQL запрос будет примерно таким
Как видишь в секциях SELECT и ON используется псевдоним таблицы, в xPDO тоже надо использовать псевдонимы, если они указаны в leftJoin или setTableAlias. Поэтому вот это всё
неверно, должно быть так
И наконец, чтобы проверить какой же запрос будет выполнен можно сделать так
Установил, настроил, капча выводится, но если не чекнуть её и отправить форму получаю ошибку: Журнал ошибок ModX пуст.
Modx 3.1.2-pl, YaSmartCaptcha 1.0.2-pl, Formit 5.1.1-pl.
В логе сервера такая ошибка:
Подскажите, пожалуйста, может я что-то не так настроил?
Кто ещё не нажал кнопочку «Отправить деньги» в разделе «Поблагодарить автора» под анонсом поста — самое время всем это сделать!
он же там потом разрастаться будет и никто из разработчиков про это помнить не будет.
Хочется отдельный файл лога — почему не положить рядом со стандартным errors.log что-то типа
?
Сайт был версии 2.7.2
Зараженные директории:
- assets/components/formit/js/mgr/widgets/migrate.panel.php
- assets/components/migx/js/mgr/widgets/grids/migxgallery.grid.php
- assets/components/pdotools/js/pdopage.min.php
Сам код во всех файлах одинаковыйНу и да как уже выше писали на уровень выше корня сайта были созданы директории:
.local, .config — в которых и была пакасть.
Компоненты обновил, систему обновил, дрянь удалил.
3й День пока все ок
Но там ведь нет возможности указать периодичность запусков заданий. Только можно указать точное время запуска.
При такой структуре Scheduler'а, для достижения периодичности выполнения нужно будет реализовать логику самоперепланирования внутри скриптов, а первый запуск придется сделать вручную. Это как-то не очень удобно не находите? и не очень надежно. Если вы знаете в каком компоненте есть реализация нормальной работы с этим планировщиком напишите. я гляну, вдруг что-то не так понимаю.
А вот хостинг как раз Timeweb — и очень похоже, что именно у них где-то дырка. Что характерно — заблокировали молча, без всяких предупреждений о нагрузке — потом изучая график нагрузки стало понятно, что уже больше месяца этот майнер работал.
Так же рекомендую произвести поиск каким-нибудь антивирусам по популярным функциям типа base64_decode или развернуть старый бэкап — так как было найдено 3 бэкдора в разных папках сайта + админер в одной из папок, которых ранее точно не было.