Алексей Шумаев

Спасибо, проверю/поправлю в течении 1-2 дней.
Можно сразу и название деревни для примера? На всякий случай проверю ситуацию с деревнями.

Принято, проверю.

1. Глюка с почтой не вижу, буду попозже на свежую голову отлавливать.
2. Там, где конкретный адрес важен (Достависта), он учитывается.
но при этом адрес задаётся прямо в виджете, поэтому манипуляции с полями ms2 не имеют значения.
Причём для поля ввода адреса можно подключить dadata: yadi.sk/i/1UamsCRgwxoW9A
modx-v2.eshoplogistic.ru/documentation.html#d12
Сейчас поля ввода адреса внутри виджета и в ms2 не синхронизированы, т.е. вводить надо и там и там. Пока это касается только Достависты, поэтому отложено на недалёкое будущее.
3. Для почты — да, но это под капотом: задавать индекс посетителю сайта не нужно, он автоматом подтягивается от выбранного города.

Да, ещё: что-то делать в чанках не нужно, вся логика в js.

Версия обновлена. Правда я немного поспешил, т.к. по 3 пункту ещё разбираемся.
Скорее всего обновление версии не потребуется, если баг внутри виджета, но лучше пока подождать с обновлением на боевом сайте.

Проверить как сейчас работает можно на демо-сайте: modx-v2.eshoplogistic.ru
Буду благодарен за обратную связь!

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

Спасибо! Завтра займусь обновлением модуля.

Я думаю, можно для способов доставки в чанке
{if $delivery.class == 'eslHandler'} установить класс типа «esl-delivery-item»
и скрывать только их.
В ближайшее время что-нибудь придумаю…

Добрый!

Да, так работает.
Сами способы доставки должны быть на странице, но управляются «за кулисами» по событиям виджета.
Возможно, это я не совсем верно сделал, т.к., действительно могут быть иные способы доставки, которые не нужно скрывать. Я подумаю, как это поудобнее реализовать; скорее всего скрываться будут только способы доставки, созданные модулем при установке.
Пока можно переключиться на свой js-файл, скопировать туда несжатый eshoplogistic2.js и закомментировать/изменить эти строки: yadi.sk/i/XckMjOIIacnUaQ

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

Вообще вроде же сниппет в комплекте готовый есть…

innerJoin?

использовать loadModels

modx.pro/components/17634#comment-108735

Жесть и боль ) Вот прям сочувствую.
Я так думаю это касается ~ 90% работающих в сфере сайтов.
Обычно при таком подходе народ моментально выгорает; да и учиться нет особого смысла — только под конкретную ситуацию.

Опыт — сын ошибок трудных (©), делюсь, пока минута есть.
Подзаработать потом, это хорошо; главное, чтобы проект не возвращался на доработку неожиданно, как будет что-то всплывать. А то техдолг накопится и через пару лет работа будет ради работы делаться. Ну или работать по принципу «сдал проект — и меня нет», тоже так себе подход )))

Ну да, как вариант — конкретная реализация от задачи.

Вангую немного на будущее:
— вдруг проект вырастет?
— вдруг выяснится, что народ закрывает страницу не дожидаясь отправки и не получает билеты, а потом жалуется?
— вдруг сбой отправки и вы об этом не узнаете, а повторной отправки не предусмотрено?
— вдруг надо будет ещё что-то делать вместе с отправкой билета?
Это я к тому, что лучше этот процесс перенести полностью на бэк, где вы его будете контролировать.

Чтобы БД не запрашивать (хотя для небольших проектов это не имеет особого значения, да и вообще — кому нужна БД — узкое место же :-) ) — можно в файлы json писать: есть файл -> читаем, получаем указанный заказ, отправляем, удаляем. Если отправка каких-то писем не удалась — пишем в лог и данный файл не удаляем. Однако, имхо, это немного извращение.

Да, именно на крон. Сохраняем очередь отправки в отдельную таблицу, потом кроном раз в ~ 1 мин отправляем накопившиеся и удаляем из таблицы. Лимит на отправку за один запуск скрипта ~ 5-10 писем, чтобы не иметь проблем с хостером (чтобы за спам 100% не принимали).

Навскидку несколько моментов:
1. «Чтобы избежать повторных отправок, записываем id заказа в куки… » — лучше таки флаг отправки сохранить в БД, например в properties msOrder. Ибо на страницу domain.ru?msorder=1 можно перейти не раз + она запросто может попасть в индекс яндекса (проверено) и будет весело. Запретите индексацию таких страниц в robots.
2. Откликаться будет ТОЛЬКО на ajax запросы: if ($_SERVER['REQUEST_METHOD'] != 'POST')…
Этот код будет работать при любом запросе к данной странице постом.
Меняйте на что-то вроде:

if(empty($_SERVER['HTTP_X_REQUESTED_WITH']) || $_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest') die;

3. Отправку писем нужно повесить на событие оформления заказа или иное подходящее.

И я бы такой функционал в принципе не вязал бы с MS2, он тут по факту не нужен )

За публикацию личного опыта — спасибо.

Версия обновлена, теперь есть сортировка файлов.