Вчера в 20:35
Нет конечно, иначе это были бы уже отдельные товары.
06 марта 2026, 09:38
Александр, данный компонент более недоступен для приобретения?
06 марта 2026, 09:11
Спасибо за информацию — проверим. Какой редактор используете?
04 марта 2026, 21:09
Немного нетипичный пост на этом форуме. Будем считать это экспериментом. Кратко вводную информацию я выложил у нас в телеграм-сообществе — получил мно...
04 марта 2026, 20:13
Атомарненько)))
03 марта 2026, 13:58
+
Всего 125 675 комментариев
Каждый раз костыли лепить не нравится)))
Ну а если мы удалим пользователя — мы удалим и информацию об оставленной электронной почте.
На мой взгляд было в 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 писать: есть файл -> читаем, получаем указанный заказ, отправляем, удаляем. Если отправка каких-то писем не удалась — пишем в лог и данный файл не удаляем. Однако, имхо, это немного извращение.