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

Согласен. Я вот к этой части вопроса отписался:

Я еще могу понять использование докера там, где крайне сложный проект, который задействует mysql, postgress, redis, php, python и go, все это завязано в общую систему. Но для modx? зачем?

:-)

Это отличная вводная статья для новичков. Кто-то, кто что-то слышал про Doker, но боялся спросить использовать, увидит, что всё не так страшно и даже modx можно вписать в современный стек разработки.
Само-собой предполагается, что нужно почитать ещё материалы по теме, но чтобы попробовать — вполне достаточно.

Надо оно для modx или нет — решает каждый сам для себя, конечно. Я однозначно рекомендую попробовать, хотя бы для своего роста как разработчика. Чтобы потом легко перейти на современную разработку в любой команде.

Самое крутое, что я пока вижу в Doker'е — возможность разбить один большой сервис на кучу микросервисов, которые можно легко сопровождать/обновлять по отдельности + масштабирование + отказоустойчивость. Да, есть накладные расходы, но оно того однозначно стоит.
Собираюсь некоторые старые разработки перевести на Doker + k8s.

Да, нюансов масса выплывает )
Можно посмотреть тут новую версию: modx-v2.eshoplogistic.ru/korzina.html
С очисткой кэша браузера.

Спасибо, проверю/поправлю в течении 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 писать: есть файл -> читаем, получаем указанный заказ, отправляем, удаляем. Если отправка каких-то писем не удалась — пишем в лог и данный файл не удаляем. Однако, имхо, это немного извращение.