Семён Кудрявцев

Да, про события в итоге нашел их и решил задачу, а идея писать сначала во временный файл, а потом перезаписывать в конечный — это прям то, что нужно!

Ещё раз спасибо автору компонента, всё чаще его встречаю у клиентов на сайтах с MODX Revo,
чертовски удобно всё настраивать.

Не, это то понятно) Я к тому что отдельно геокодер яндекса со 100% точностью определяет мой адрес, я поэтому и удивился, что компонент через яндекс не смог определить корректно геолокацию, а отдельно без проблем.

У меня определяет не правильно, погрешность в 30 км, доступ к геоданным предоставил в браузере, не помогло.

Заметил странное поведение компонента, версия последняя, каждая выгрузка из 1С создает по 3 сессии, хотя по логике должна быть всего 1, при первом запросе авторизации получается кука, устанавливается сессия и работает до конца обмена.

Если проблема коснулась объекта адреса заказа, то может и за одно пофисить связанный с этим баг из ишьюс
github.com/modx-pro/miniShop2/issues/627

Только это не имеет большого смысла, так как с ресурсами можно работать в админке и без захода в сам ресурс, например через контекстное меню снять его с публикации, и тогда плагин не сработает, а даже если бы сработал, то в процессорах публикации/депубликации один фиг жестко прописан снос всего кэша.
Та же история с публикацией по расписанию.
Единственный вариант — это полностью переписывать реализацию класса кэш-менеджера и всех его методов.

Да идея неплохая, так сможем всем сообществом довести скрипт до ума, а потом предложим в пулреквест

Я бы не спешил с пулреквестом, так как скрипт написан с ошибками.
Хорошо бы его сначала протестить по-полной, но за решительный шаг, наконец-то избавить компонент от jQuery — уважуха!
Сейчас тестирую скрипт, где-то лезут ошибки в браузер из-за недостающих проверок на существование элементов, что джеквери делает под капотом.
Так же хорошо, что убран функционал с уведомлениями, он должен быть опциональным, но проверки на него тоже выкидывают ошибки в консоль.
Автору благодарность, ошибки не критичные, легко все пофиксить

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

Отличное начало, интересно почитать про Ваш опыт с ZoomX, сам около года назад запилил интернет-магазин на нем (ещё на самой первой версии), работает в продакшене. Сейчас как раз добавляю в него API слой — будет интересно получить опыт другого разработчика.

Компонент реально крутой получился, уже перерос компонент от Марка из modmore. Единственное чего не хватает, возможности указывать файловые чанки, снова нужно писать код в админке.

С медленной работой сталкиваются все, кто пытается на windows и macos пробрасывать исходники из хостовой системы в wsl а потом в docker, причина элементарная — виртуализация, когда активируется wsl, основная операционка становится виртуальной машиной №1, дистрибутив в wsl становится виртуальной машиной №2, обе они работают параллельно на гипервизоре первого уровня от микрософт если на винде (под капотом убогий и медленный hyper-v) В итоге когда ты запрашиваешь страничку, запущенную в докере, она сначала из одной виртуалки идет в другую виртуалку, а потом из второй через моунт тома попадает в докер — отсюда и тормоза. Если исходники разместить сразу в wsl, откуда они будут сразу попадать в докер, то скорость будет близка к нативной, с учетом накладных расходов докера, но на глаз это очень трудно увидеть. В итоге всё летает как положено) Сам долгое время с этим мучился, пока не закопался в эту виртуализацию и не разобрался что и как там работает.

Решил попробовать компонент, но вышло с трудом из-за некорректной инструкции
Во первых везде написано, что при установке в папке core создаются файлы — по факту они не создаются.
Во вторых в папке самого компонента в core есть папка plugins с описанной структурой, но и там ошибка, в файле events.example вызывается файл Title.php, тогда как в папке ModxPlugins/Web/ лежит Logo.php
В третьих даже если прям там в папке самого компонента переименовать файл events.example в php и исправить Title на Logo один фиг ничего не заработает.
А чтобы заработало нужно самому скопировать из папки компонента папку plugins в папку core, и сделать в ней вышеописанные правки.
Хорошо бы исправить инструкцию, и либо сделать реально чтобы файлы формировались в папке core, либо написать что их надо самим копировать.
И было бы неплохо иметь возможность в системных настройках указывать свой путь для плагинов, и указывать его ещё на этапе установки, чтобы уже первичных набор файлов записался туда.

Отбой, повторная переустановка обновления помогла — всё работает

У меня и без этого пакета, обновление криво встало, не добавилось поле entrance в таблицу с адресами:
Ошибка:

Error 42S22 executing statement: 
Array
(
    [0] => 42S22
    [1] => 1054
    [2] => Unknown column 'msOrderAddress.entrance' in 'field list'
)

Сергей, поздравляю! Хорошая новость.
Видишь как сложилось, ты хотел писать замену pdoTools, а получилось, что сам пакет тебе передали на попечение.
Жду с нетерпением возможности использовать smarty из твоего ZOOMX в pdoTools, теперь не надо будет использовать 2 шаблонизатора на сайте)
По поводу безопасности, читал и в телеге и в твоем блоге, может тут пойти по такому же принципу как в последней обнове движка сделали, для статичных элементов добавили настройки, ограничивающие куда можно класть статические элементы. Можно даже под эти настройки завязаться, так как один фиг все шаблоны где-то должны в одном месте лежать. То есть ограничить какой-нить одной папкой, чтобы ни до чего другого было не дотянуться.

Потестил компонент, не работает функционал «Завершить все сеансы» — может быть имело смысл не создавать свою таблицу, а расширить существующую и тогда бы это работало. В итоге получаем ошибку —
А так затея интересная, автору респект.

Вопрос автору, планируется ли поддержка msPromoCode2?
Компонент перебивает отрисовку функционала промокодов при редактировании заказа, при чем не помогает даже изменение приоритетов срабатывания плагинов.
Может как-то придусмотреть в компоненте, возможность другим компонентам рисовать свой функционал в заказе хотя бы отталкиваясь от приоритета события плагина.
Обычно компоненты рисующие extjs в админке рагют свои скрипты на событие — msOnManagerCustomCssJs,
было бы удобно иметь возможность задавать приоритет этому событию и тогда все компоненты могли бы при необходимости свой функционал добавлять в интерфейс, сейчас же Ваш компонент перманентно перебивает все скрипты других компонентов несмотря на приоритеты.

Крутяк! Автору, респект — давно ждал этой истории, что и как делать в MODX + Vue
На вопрос автора — Нужно ли дальше делать подобные компоненты или они наоборот уводят MODX куда-то в сторону?)
Ответ: Однозначно, да!
И по поводу админки на vue, хотелось бы, чтобы это всё-таки стало реальностью)