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

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

Пока нет. В обозримом ближайшем будущем (до осени точно) поддержки 3 не планируется.

Хороший повод сделать своё дополнение.
Проще всего взять заготовку, например: github.com/modx-pro/modExtra

Не внимательно прочитал вопрос :-)
На самом деле mSearch2 автоматом добавляет в индекс данные создаваемого ресурса.
Если в данном случае этого не происходит и не получается через процессор, значит — да, что-то в системе не работает. Надо дебажить.

Насколько я понял это необходимо:

$modx->runProcessor(
     'mgr/index/update', 
     ['id' => $resource->id], 
     ['processors_path' => MODX_CORE_PATH.'components/msearch2/processors/']
);

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

Я еще могу понять использование докера там, где крайне сложный проект, который задействует 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?