Сегодня в 00:23
Нет, лайки всегда были привязаны ко времени публикации, чтобы лайками старых постов рейтинг не накручивали.
MiniShop3 - новый релиз. 1.0.0-alpha.2 15
19 декабря 2025, 15:43
Подозреваю, что в системных настройках компонента нужно указать ID нужного способа оплаты и в уведомление о заказе не забыть прописать ссылку на оплат...
msOneClick - обновление 5
19 декабря 2025, 11:37
Добрый день! с 1 января 2026г. меняется НДС. Подскажите, где поменять НДС на 22%
[mspTinkoff] - метод оплаты Tinkoff MiniShop2 35
18 декабря 2025, 10:15
Ага, спасибо. Первый и думаю не последний)
StaticFilesPlus — автоматическое создание статических элементов с поддержкой категорий 10
13 декабря 2025, 19:55
Красавчег!
MiniShop3: Notification Center — Революция в управлении уведомлениями 4
13 декабря 2025, 17:47
Для MIGX нужно указать
"configs": {
"startDay": 1
}
Ввод дат в "привычном" формате ДД.ММ.ГГГГ и отображение с понедельника 12
12 декабря 2025, 22:23
В Сбере поменяли работу с логином и паролем интернет-эквайринга. Теперь они без суфикса -api. И настраиваются в ЛК СберБизнес. (Логин ПШ и ПАроль ПШ)....
[mspSberbank] Оплата заказов miniShop2 через процессинг Сбербанка 109
Да, Railt на перспективу интересный, но я вот пошарился по доке — очень много пустых разделов, мануалов хотя бы минимальных вообще нет, а я не настолько про чтобы полностью ориентироваться по исходникам. Какие-то моменты можно раскурить по коду, но не настолько. По времени дешевле взять что-то более готовое. Собственно поэтому и начал искать альтернативное решение. Этот github.com/folkloreinc/laravel-graphql как я понял умер, этот github.com/rebing/graphql-laravel что-то не очень понравился (субъективно).
Возьму пока Lighthouse вроде все для старта есть, уже даже апишка получается минимальная буквально со старта.
- Статусы ошибок — я так понимаю в подавляющем большинстве случаев ответ будет 200 и надо парсить тело ответа, чтобы определить что нам пришло. Не критично, но и не радует.
- Бесконечное количество вложенных запросов — насколько понял проблема решаема, можно создать «белый лист» запросов, ограничить вложенность, но это дополнительные телодвижения. Сюда же можно добавить вопрос, а что если клиент решит дернуть все сущности что есть на сайте с максимально допустимым лимитом в одном запросе? Как определить что прилетевший запрос слишком жирный?
- Контроль доступа к данным — ввиду того что неизвестно какой запрос придет от клиента, можно элементарно прошляпить и отдать ему то, что не положено. Конечно можно предоставить контраргумент, мол, можно и SQL инъекцию провтыкать, но на мой скромный взгляд вероятность накосячить с gql гораздо больше, особенно когда много сущностей и разного рода политик доступа.
- Кеширование — как я понял из того что пока читал, организовать кеширование довольно нетривиальная задача, опять таки из-за того что непонятно какой запрос будет выполнен.
- Целостность данных связанных сущностей при update если что-то пошло не так?
- Аналитика — в случае REST я могу повесить логирование каждого endpoint и спустя некоторое время, ознакомиться с полученными данными и в случае необходимости оптимизировать/переделать. В случае gql я себе смутно представляю как это сделать.
Единственное преимущество, которое я вижу в GraphQL это удобный доступ с клиента. Отсюда вытекает предположение, что данная технология подходит очень крупным компаниям, которые взаимодействуют с огромным числом разработчиков. Тогда думаю, будет оправдано заморочиться. Или если планируется раздавать большое количество контента без каких-либо хитрых операций с данными. Например, применение gql в каком нибудь сервисе геоданных я вижу вполне оправданным. В какой-то системе а-ля CRM с кучей хитрых операций, политик доступа, повышенными требованиями к безопасности — нет.P.S. сам я 3-ю версию уже давно не жду.
Спасибо вам за советы.
Время для выполнения действия я получаю вот так:
Конечно если сейчас 12:01, мы добавляем минуту, то выходит вот так 12:2. Но действие все равно выполняется, если интервал небольшой (что странно). Я грешил на этот момент, но как выяснилось приведя время в формат 12:02, то есть с 0, все равно таймер не отрабатывает. Даже если попадаем через 30 мин на 12:45 все равно не работает. Кстати, дело не в формате времени, так как при использовании функции setTimeout() все равно не работает если поставить интервал в 30-60 мин.
Может у меня просто «жизненный цикл» ноды умирает? Сколько вообще живет нода после обращения к ней? Вот описания «поведения» node.js я пока не нашел. То есть в пыхе все понятно, сделал запрос, код отработал и умер, а в ноде как? Сколько живет «процесс» или он вообще не умирает, а в каких случаях умирает, а как сделать чтобы работал постоянно и тд, а что влияет на жизненный цикл процесса. Это все для меня пока загадка.
Возникла одна задачка, которую я никак не могу преодолеть. При обращении по УРЛ в массив notes заносятся данные, скажем ИД и время +30 мин после обращения (скажем сейчас 12:00, тогда в массив пишем 12:30). Далее я запускаю setInterval и каждую секунду перебираю массив notes. Примерно так:
Если время сейчас и время в массиве совпадает, то выполняем действие. И вот тут как раз проблема — если действие нужно выполнить через 1-5 мин после обращения, то действие выполняется, а если через 30 или 60 мин, то нет. Хотя очень редко бывает, что и выполняется, но 1 из 20 раз, примерно. Уже перегуглил все что можно. Не подскажете куда копать по данному вопросу?
Нигде не могу найти ответа по поводу данного поведения — хочет срабатывает, хочет не срабатывает.
Есть каталог Сад Огород. В нем категории «Пилы цепные», «Газонокосилки», «Мотоблоки» и тд. У каждого товара есть производитель (msVendor). И вот тут возникает проблема. Создаем поле фильтра для вендоров, создаем правило и назначаем это правило для страницы «Пилы цепные», сохраняем. И вот тут начинается беда.
То есть, создаются УРЛы для раздела «Пилы цепные» с производителями, которых там нет и в помине. Например, пилы представлены двумя производителями — Honda, Hyundai, но также создаются и «левые» типа Пуберт, Макита и тд. То есть, осмелюсь предположить что компонент фигачит всех подряд вендоров, которые назначены товарам не ограничиваясь указанной страницей для правила. С любыми другими опциями та же беда, берутся значения со всех товаров. а не только с товаров указанной в правиле категории.
Вот это вот дело очень мешает жить, во-первых, создаются страницы с пустыми результатами фильтрации, но это можно побороть соответствующей системной настройкой и будет 404. Во-вторых, и главных, вот эта куча мусора которого быть по идеи не должно очень мешает работать, так как из, например, созданных 150-ти строк в таблице УРЛ, реально нужны 15, остальное просто мешает. Я боюсь представить что будет если на реальном проекте я загружу 2000 товаров с кучей опций для фильтрации, я просто ничего не смогу найти в «таблице УРЛ».
Еще заметил такой момент в сниппете sfMenu. Так как много мусорных УРЛ создается, как я описал выше, в «облаке ссылок» они также вылазят при выводе sfMenu и получается ссылки ведут на 404. Ок. Есть параметр mincount, задаю значение 1, и блин, вместе с УРЛами где результатов 0, также не выводятся УРЛы по которым результат 1. То есть, если я правильно понимаю, то дословно параметр mincount означает минимальное количество, то есть вывести ссылки с минимальным количеством результатов один и более. Но не работает. Выводится больше одного.
Подитожу вопрос. Как сделать чтобы при создании правила, ссылки в таблице УРЛ создавались относительно товаров указанной страницы, а не брались значения всех товаров подряд из всех категорий на сайте?