3 часа назад
+
Вчера в 17:14
Это не ошибка, а warning — посмотрим, спасибо!
UPD github.com/modx-pro/MiniShop3/pull/127
01 марта 2026, 14:45
Добавил сиcтемную настройку ms3recentlyviewed.block_bots_detector и интегрировал jaybizzle/crawler-detect
01 марта 2026, 14:38
В следующий раз сделаю как положено)
28 февраля 2026, 15:20
Всем привет!
Версия модуля 1.4.0
Необходимо обновить наименования товаров.
Выбираем Тип импорта — Обновить данные товаров
Соответствие Столбца Наз...
27 февраля 2026, 21:26
Настройками нельзя, только написанием своего плагина, который будет проверять необходимые условия. Если сами не справитесь, могу написать его за отдел...
25 февраля 2026, 17:49
Добавлен также генератор разнообразных типов опций товара в разном количестве для разных наборов и их заполнение у товаров.
25 февраля 2026, 09:59
Удалось найти решение?
Всего 125 693 комментария
Каждый раз костыли лепить не нравится)))
Ну а если мы удалим пользователя — мы удалим и информацию об оставленной электронной почте.
На мой взгляд было в 10 раз логичнее сохранять и почту и телефон в заказе, а если уже выставлена соответствующая настройка — регистрировать пользователя по этим данным!
Ну попадает заказ к одному анониму, ничего страшного, в заказе адрес и номер будет разный. Врятли, менеджеры переходят к пользователю, чтобы посмотреть его контактные данные.
А если это сильно смущает то можно удалять этого же пользователя, если его имя совпадает с почтой
Вешаем плагин на событие: OnUserSave
Но, только если при регистрации почта не используется как логин.
Конечно, это все костыли, и более правильно будет не создавать пользователя, но дать возможность решать это через системную настройку.
Ну это прям призыв, чтобы пришли люди и грохнули сайт без каких-либо сложностей))
И даже так (и вроде когда используется массив) (обсуждали уже где-то здесь) что-угодно можно пропихнуть.
Всегда когда работаем с целыми числами всего лишь нужно добавить (int) перед чем-угодно и спать спокойно.
А это открывает доступ к другим типам инъекций.
Возможно, Fenom что-то там и порежет, но надеяться не стоит.
Теперь по замечаниям.
1) Абсолютный путь в целом там и не нужен, оставлю относительный.
Но ещё более не секьюрно давать кому-то доступ в админку))
Там и без этого никаких проблем получить все системные настройки через Fenom.
2) Поправил, в следующем обновлении уже не должно всплывать.
— если email пустой, то сделаем его в формате «Получатель_заказа@мой сайт.ру». Класс… т.е. первый купивший Алексей зарегистируется на сайте и создаст пользователя с такой почтой, а заказ от второго Алексея внезапно попадет к первому, т.к. почта-то одинаковая…
Ладно, если мы на фронте этого не выводим всего… но в админке то выглядит так, как-будто все эти заказы от одного пользователя!
select id=«delivery_shop» name=«extfld_delivery_shop» value="{$form['extfld_delivery_shop']}" class=«form-control»
Нужно вот так?
$properties = $msOrder->get('properties');
$delshop = $properties['extfld_delivery_shop'];
И просто вывод {$delshop} )?
Подзаработать потом, это хорошо; главное, чтобы проект не возвращался на доработку неожиданно, как будет что-то всплывать. А то техдолг накопится и через пару лет работа будет ради работы делаться. Ну или работать по принципу «сдал проект — и меня нет», тоже так себе подход )))
Вангую немного на будущее:
— вдруг проект вырастет?
— вдруг выяснится, что народ закрывает страницу не дожидаясь отправки и не получает билеты, а потом жалуется?
— вдруг сбой отправки и вы об этом не узнаете, а повторной отправки не предусмотрено?
— вдруг надо будет ещё что-то делать вместе с отправкой билета?
Это я к тому, что лучше этот процесс перенести полностью на бэк, где вы его будете контролировать.
Чтобы БД не запрашивать (хотя для небольших проектов это не имеет особого значения, да и вообще — кому нужна БД — узкое место же :-) ) — можно в файлы json писать: есть файл -> читаем, получаем указанный заказ, отправляем, удаляем. Если отправка каких-то писем не удалась — пишем в лог и данный файл не удаляем. Однако, имхо, это немного извращение.