Не, это то понятно) Я к тому что отдельно геокодер яндекса со 100% точностью определяет мой адрес, я поэтому и удивился, что компонент через яндекс не смог определить корректно геолокацию, а отдельно без проблем.
Заметил странное поведение компонента, версия последняя, каждая выгрузка из 1С создает по 3 сессии, хотя по логике должна быть всего 1, при первом запросе авторизации получается кука, устанавливается сессия и работает до конца обмена.
Только это не имеет большого смысла, так как с ресурсами можно работать в админке и без захода в сам ресурс, например через контекстное меню снять его с публикации, и тогда плагин не сработает, а даже если бы сработал, то в процессорах публикации/депубликации один фиг жестко прописан снос всего кэша.
Та же история с публикацией по расписанию.
Единственный вариант — это полностью переписывать реализацию класса кэш-менеджера и всех его методов.
Я бы не спешил с пулреквестом, так как скрипт написан с ошибками.
Хорошо бы его сначала протестить по-полной, но за решительный шаг, наконец-то избавить компонент от 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, либо написать что их надо самим копировать.
И было бы неплохо иметь возможность в системных настройках указывать свой путь для плагинов, и указывать его ещё на этапе установки, чтобы уже первичных набор файлов записался туда.
Сергей, поздравляю! Хорошая новость.
Видишь как сложилось, ты хотел писать замену pdoTools, а получилось, что сам пакет тебе передали на попечение.
Жду с нетерпением возможности использовать smarty из твоего ZOOMX в pdoTools, теперь не надо будет использовать 2 шаблонизатора на сайте)
По поводу безопасности, читал и в телеге и в твоем блоге, может тут пойти по такому же принципу как в последней обнове движка сделали, для статичных элементов добавили настройки, ограничивающие куда можно класть статические элементы. Можно даже под эти настройки завязаться, так как один фиг все шаблоны где-то должны в одном месте лежать. То есть ограничить какой-нить одной папкой, чтобы ни до чего другого было не дотянуться.
Потестил компонент, не работает функционал «Завершить все сеансы» — может быть имело смысл не создавать свою таблицу, а расширить существующую и тогда бы это работало. В итоге получаем ошибку —
А так затея интересная, автору респект.
Вопрос автору, планируется ли поддержка msPromoCode2?
Компонент перебивает отрисовку функционала промокодов при редактировании заказа, при чем не помогает даже изменение приоритетов срабатывания плагинов.
Может как-то придусмотреть в компоненте, возможность другим компонентам рисовать свой функционал в заказе хотя бы отталкиваясь от приоритета события плагина.
Обычно компоненты рисующие extjs в админке рагют свои скрипты на событие — msOnManagerCustomCssJs,
было бы удобно иметь возможность задавать приоритет этому событию и тогда все компоненты могли бы при необходимости свой функционал добавлять в интерфейс, сейчас же Ваш компонент перманентно перебивает все скрипты других компонентов несмотря на приоритеты.
Крутяк! Автору, респект — давно ждал этой истории, что и как делать в MODX + Vue
На вопрос автора — Нужно ли дальше делать подобные компоненты или они наоборот уводят MODX куда-то в сторону?)
Ответ: Однозначно, да!
И по поводу админки на vue, хотелось бы, чтобы это всё-таки стало реальностью)
чертовски удобно всё настраивать.
github.com/modx-pro/miniShop2/issues/627
Та же история с публикацией по расписанию.
Единственный вариант — это полностью переписывать реализацию класса кэш-менеджера и всех его методов.
Хорошо бы его сначала протестить по-полной, но за решительный шаг, наконец-то избавить компонент от jQuery — уважуха!
Сейчас тестирую скрипт, где-то лезут ошибки в браузер из-за недостающих проверок на существование элементов, что джеквери делает под капотом.
Так же хорошо, что убран функционал с уведомлениями, он должен быть опциональным, но проверки на него тоже выкидывают ошибки в консоль.
Автору благодарность, ошибки не критичные, легко все пофиксить
Во первых везде написано, что при установке в папке core создаются файлы — по факту они не создаются.
Во вторых в папке самого компонента в core есть папка plugins с описанной структурой, но и там ошибка, в файле events.example вызывается файл Title.php, тогда как в папке ModxPlugins/Web/ лежит Logo.php
В третьих даже если прям там в папке самого компонента переименовать файл events.example в php и исправить Title на Logo один фиг ничего не заработает.
А чтобы заработало нужно самому скопировать из папки компонента папку plugins в папку core, и сделать в ней вышеописанные правки.
Хорошо бы исправить инструкцию, и либо сделать реально чтобы файлы формировались в папке core, либо написать что их надо самим копировать.
И было бы неплохо иметь возможность в системных настройках указывать свой путь для плагинов, и указывать его ещё на этапе установки, чтобы уже первичных набор файлов записался туда.
Ошибка:
Видишь как сложилось, ты хотел писать замену pdoTools, а получилось, что сам пакет тебе передали на попечение.
Жду с нетерпением возможности использовать smarty из твоего ZOOMX в pdoTools, теперь не надо будет использовать 2 шаблонизатора на сайте)
По поводу безопасности, читал и в телеге и в твоем блоге, может тут пойти по такому же принципу как в последней обнове движка сделали, для статичных элементов добавили настройки, ограничивающие куда можно класть статические элементы. Можно даже под эти настройки завязаться, так как один фиг все шаблоны где-то должны в одном месте лежать. То есть ограничить какой-нить одной папкой, чтобы ни до чего другого было не дотянуться.
А так затея интересная, автору респект.
Компонент перебивает отрисовку функционала промокодов при редактировании заказа, при чем не помогает даже изменение приоритетов срабатывания плагинов.
Может как-то придусмотреть в компоненте, возможность другим компонентам рисовать свой функционал в заказе хотя бы отталкиваясь от приоритета события плагина.
Обычно компоненты рисующие extjs в админке рагют свои скрипты на событие — msOnManagerCustomCssJs,
было бы удобно иметь возможность задавать приоритет этому событию и тогда все компоненты могли бы при необходимости свой функционал добавлять в интерфейс, сейчас же Ваш компонент перманентно перебивает все скрипты других компонентов несмотря на приоритеты.
На вопрос автора — Нужно ли дальше делать подобные компоненты или они наоборот уводят MODX куда-то в сторону?)
Ответ: Однозначно, да!
И по поводу админки на vue, хотелось бы, чтобы это всё-таки стало реальностью)