точно ко мне вопрос?)))

Варианты с $_pls $_modx->getPlace… Пробовали?

Добрый день. Хочу купить дополнение для miniShop2. Рассматриваю пакеты mscZone и mscDistance. Подскажите, какой из пакетов подойдёт лучше для реализации динамического поиска города в корзине и установки соответствующей стоимости доставки после выбора города?
Заранее спасибо)

У меня вот сейчасс не получается на феноме вывести [[!+ss_meta]] из дополнения Seo Suite

{'ss_meta' | placeholder}

Ты какой ответ ожидаешь увидеть?

Для тех, кто зачем-то 50 раз в раз в неделю скачивает эту библиотеку с npmjs.org

А что с ним не так?

Про Tailwind, если что, я в курсе.

Вряд ли кто-то сейчас завалит новинками все репозитории.

Возможно так и есть.

Хотя как минимум MoreGallery и ContentBlocks не используют ExtJS, являясь при этом очень популярными платными дополнениями.

По скринам я вижу, что ContentBlocks использует ExtJS для всех настроек. Но в самом ресурсе используется что-то другое, но это очень похоже на ExtJS.

Это ж от разработчика зависит. В моей заметке есть и видео, и картинки — тебе кажется это монстром Франкенштейна?

Согласен, что все зависит от разработчика. Я не говорил, что твоя работа похожа на Франкенштейна, я говорю, что если будет много компонентов с разными стилями, то вот это будет ужасно. Ты сделал так, другой разработчик сделал по другому, и уже хаос.

При желании можно написать свои, идентичные родным админочным.

Да, вот это было бы решение, использовать единые стили для всех компонентов на vuejs.

Вряд ли кто-то бы отказался от качественно переписанного интерфейса miniShop2 и Tickets на VueJS, с нормальной адаптивностью.

Здесь проблема финансирования. Сейчас код поддерживается почти бесплатно, и врятли все разработчики минишопа знают vue и получиться, что переписать то можно, но кто поддерживать будет? Я вот вижу только один выход — сделать эти компоненты платными, но это уже другая тема.

Скорее о том, как притащить современные технологии. Это для тех, кто не хочет застрять в 2015 году, и я надеюсь, тут таких много.

Ну это как в москвиче сделать коробку автомат, лучше уже поменять машину. Хотя любители тюнинга и не такое делают, но тут уже каждому свое.

Много ты знаешь свободных разработчиков, которые решают подобные задачи через написание дополнения, вместо вызова FormIt с костылями?

Если нужен компонент, то так и писать, что нужен компонент. Лично я мог бы сделать))

Где веселье-то, в конце концов?

Надеюсь вам было интересно читать про изобретение моего очередного велосипеда.

Да, это было интересно. Для меня это было даже познавательно. Но я рассматриваю, это как эксперимент, что можно сделать как-то по другому.

подскажите, пожалуйста, решение

Ну в итоге то что? Что лучше? Совсем плохо если используешь где то стандартный парсер? Ведь сейчас писать шаблон без фенома даже и мыслей нет. Сайт до 500 страниц не ощутит этот смешанный режим? У меня вот сейчасс не получается на феноме вывести [[!+ss_meta]] из дополнения Seo Suite, и он у меня один в шаблоне. Из за этого одного тега я ведь ничего особо не теряю?

А в целом @vesp-frontend для кого?

На дворе 2022 год, а люди все так и юзают бутстрап

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

Вроде была статья. Но в ней как раз и писали, что феном не даёт прирост скорости. В документации есть тест по pdoTools. Вот он даёт. А феном — это лишняя нагрузка. Он не заменяет стандартный шаьлонизатор, а дополняет. Т.е. работают 2 шаблонизатора. Кроме того, кэшируемые теги MODX, написанные на феном, MODX переводит в свой формат (дополнительная нагрузка). Чтобы было понятно — кэшируемый тег MODX на странице превращается в результат и при следующем запросе страницы уже не вызывается (он распарсен). А феном тег остаётся и MODX должен дополнительно его обработать, перевести в MODX формат и проверить кэш.
Ну и плюс ещё разные неувязки. Я уже много раз о них писал.

Проблема смешанного в том, что очень хорошо нужно понимать что делаешь, потому что при передачах плейсов, переменных начинаются проблемы того что переменная ещё не запарсена модиксом, например или наоборот.
Дело в том что при запуске фенома тратятся ресурсы на срабатывание фенома и смешанный режим будет примерно как феномовских ну и + сюрпризы Кеша и доступности плейсов.

Ну и парсеры работают по очереди. Сначала один потом второй ( не помню в какой последовательности) Сергей Шлоков писал об этом по-моему.

Добрый день! Напишите, пожалуйста, в техподдержку — помогу с настройкой пакета.

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

родственник заходит на сайт, грузит фотографию, пишет текст послания, проверяет и сохраняет. А сотрудники заведения печатают открытку и дарят её пожилому человеку.

Мне кажется это так ужасно. Вместо того чтобы приехать, поздравить, побыть рядом, человек загружает картинку и текст, которую распечатают и подарят совершенно чужие люди. Уж лучше никаких поздравлений, чем такие.

Я сравнивал главную страницу простого сайта.
На чистом модикс и чистом феном.
В быстродействии, тем более из Кеша победил парсер модикса.
Перевес не значительный, но есть.

Где то была статья и там сравнивали работу смешанного режима и чистого фенома, и вроде как был вывод что лучше писать всё на феноме. С тех пор стараюсь так и делать. Это бессмысленно? Я как то не интересовался больше

Меня смущает один момент, если такие компоненты начнут плодить, то это будет ужас!

По моим подсчётам, в modstore.pro добавлено 76 новых дополнений за последние 2 года — по 38 в год. Вряд ли кто-то сейчас завалит новинками все репозитории.

Возможность создавать страницы админки любым удобным спобом была изначально в Revolution, тут я Америку не открыл. Если раньше никто особо этим не увлекался, то и сейчас вряд ли начнёт.

Хотя как минимум MoreGallery и ContentBlocks не используют ExtJS, являясь при этом очень популярными платными дополнениями.

Нарушается общая стилизация и админка будет похожа на франкенштейна.

Это ж от разработчика зависит. В моей заметке есть и видео, и картинки — тебе кажется это монстром Франкенштейна? Лично мне нет, в отличие от вёрстки таблицами и кривой мобильной версии.

Есть системная настройка, отключающая загрузку собранных стилей Bootstrap. При желании можно написать свои, идентичные родным админочным. Смотри, опять же, пример с дополнениями от ModMore.

Вряд ли кто-то бы отказался от качественно переписанного интерфейса miniShop2 и Tickets на VueJS, с нормальной адаптивностью.

На сколько я понял, это статья для тех кто не хочет связываться с ExtJS но очень нужно сделать на MODX, таких я думаю, что очень мало здесь.

Скорее о том, как притащить современные технологии. Это для тех, кто не хочет застрять в 2015 году, и я надеюсь, тут таких много.

Отдать задачу разработчикам, которые работают с MODX.

Много ты знаешь свободных разработчиков, которые решают подобные задачи через написание дополнения, вместо вызова FormIt с костылями?
Да и потом, я конечно мог бы всё это сделать на xPDO и ExtJS, но зачем? Какой в этом интерес, в чём развитие? Где веселье-то, в конце концов?

А так — есть новая заметка на сайте, и заготовка для нового типа компонентов MODX. Может еще и дискуссию в комментариях нагенерируем.