1.@Артур Шевченко, а сниппет(ы) компонента умеет(ют) передавать в чанки все указанные в вызове параметры? На мой вкус при сборке сайта очень частно нужно добавить какие-то параметры сверх тех, что предусмотрены документацией и влияют на логину сниппета, а просто доступна в чанке для проверки или использования значения.
Так, например, умеет делать pdoResources, но не умеет pdoMenu, и это очень не удобно…
2. Чанки на Fenom поддерживаются? И на квадратном modx-синтаксисе тоже? Разделение на row и outer в наличии, или предлагается на Fenom циклы крутить?))
3. Понимаю, что внедрение было на MODX2, но много ли логики в компоненте, которая отличается от MODX3 и какие перспективы по адаптации? На MODX3 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!
Но после погружения в докер и прочие консоле-зависимые технологии, я уже замечал что сложно бывает объяснить как может быть, что при работе над сайтами люди никогда её не открывают). Но они есть (например я и те команды у кого я перенимал workflow, и кому передавал), как и есть те кто иногда меняет пару строчек кода в админке MODX минуя IDE (это не я)…
Но всё-таки знать, что полностью не вылезая из админки есть возможно работать — это очень хорошо, особенно для новичков.
C этим для затаскивания в продакшен mmxForms надо что-то будет делать… Может для форм в личном кабинете подойдет и как сейчас, но для страниц, куда из поиска посетители приходят — в таком виде пока не вариант.
P.S. А конструктор Vueform интересный конечно, Formalicious попроще будет, класс!
Конечно, для человека, который использует PhpStorm без плагинов и расширений, не иначе как джунглями представляется VSC…
В PhpStorm всё просто работает: подсвечивается, переходится по клику и автодополняется, бандлится и минифицируется и т.п., без необходимости даже открывать консоль, и уж тем более перебирать (нет, не изучать) бесконечные подборки плагинов в интернетах…
Но крутого расширения для MODX из этого поста, для PhpStorm пока нет, так что хватаем мачете и прыгаем в джунгли VSC, получивший второй шанс! :)
А если и если основную разработку чаще ведут в файлах, под git-ом, и тут уже связка StaticElementsLive и новый VSCode IntelliSense for MODX будет отличным решением!
А для тех, кто собирает пакеты (modx packages), и особенно если их часто обновляет, поддерживая более одного modx-пакета постоянно, также может пригодиться git-модуль с GUI: modx-build-environment-gui
Вообще, с выходом этого плагина для весь DX при работе с файлами в MODX переходит на другой уровень, на голову выше! Больше cпасибо @Баха Волков !
Меня вот этот вопрос заинтересовал:
А ведь использование сборщика разных пакетов не было бы такой проблемой, если бы когда-то давно этот момент предусмотрели создатели шаблонных пакетов…
Я уже давно придумал как это решить для себя, а недавно выпустил для всех! С помощью git submodule можешь подключить в любой пакет и пользоваться тоже → github/dimasites/modx-build-environment-gui welcome!
Выглядит «интерфейс» вот так:
(это ссылки на сборку каждого пакета, все на одном установленном MODX)
Концепция до безобразия простая — положить исходники в папку с названием дополнения =)
Один раз переносишь, и поддерживать становится проще!
То что ты руками указал, и сработало, это вроде как хорошо, но решить системно было бы ещё лучше!
В свежей версии MODX были правки в указанной части дефолтного конфига, и хотелось бы понять, есть ли недочёт в новой версии, или просто у тебя сайт со времён HTTP не был перенастроен на HTTPS и действуют какие то старые настройки. В любом случае я хотел бы подтвердить, что именно обновление приводит к смене протокола в url, а не что-то другое.
Я уже несколько десятков сайтов обновил и нигде такое не всплыло, вот в чем дело. Но ещё больше предстоит обновить и лучше бы я знал, если проблема и правда есть ;-)
Кстати, добавлю к списку вопросов выше ещё:
— не установлен ли у тебя тег в вёрстке? Если да, в каком значении?
Чтобы помочь тебе, дай больше инфы:
1. Проверь в системных настройках и в настройках контекста, может у тебя руками указано значение где-то?
2. По какому протоколу открываешь сайт, когда настройка выдаёт неверное значение? Например по https. А если по http открыть (без редиректа на https) — как себя поведет настройка?
3. Какой протокол указан в настройке [[++server_protocol]]?
Всё прошло хорошо, без сюрпризов и ошибок! Надеюсь, у всех так же ;-)
Для тех, кто захочет воспользоваться решением, рекомендую заменить JS-комментарии (/* такие */) на fenom-комментарии ( {*на такие*} ) чтобы на фронтенд не выводить их!
Дружелюбность системы, баланс её простоты и функционала, скорость развёртывания позволят её развиваться и привлекать новых пользователей.
Развитие!=Усложнение. Часто бывает наоборот, у гиков реже. Но для гиков уже есть фреймворки с их усложнениями на любую глубину погружения, а MODX крут тем, что сохранял баланс простоты.
Или сделать проще слишком сложно ?)) (Вот он и вызов!)
Тоже есть пара вопросов:
1. @Артур Шевченко, а сниппет(ы) компонента умеет(ют) передавать в чанки все указанные в вызове параметры? На мой вкус при сборке сайта очень частно нужно добавить какие-то параметры сверх тех, что предусмотрены документацией и влияют на логину сниппета, а просто доступна в чанке для проверки или использования значения.
Так, например, умеет делать pdoResources, но не умеет pdoMenu, и это очень не удобно…
2. Чанки на Fenom поддерживаются? И на квадратном modx-синтаксисе тоже? Разделение на row и outer в наличии, или предлагается на Fenom циклы крутить?))
3. Понимаю, что внедрение было на MODX2, но много ли логики в компоненте, которая отличается от MODX3 и какие перспективы по адаптации? На MODX3 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!
Зная разработчиков, могут и не заметить что сайт упал. Так что работа из админки даёт сайд-эффект пассивной проверки работоспособности)
Лучше всё-таки консоль использовать как fallback, а не как основной инструмент. ИМХО.
(кстати сделано на твоём плюс-минус стеке? из slim и bootstrap)
Но после погружения в докер и прочие консоле-зависимые технологии, я уже замечал что сложно бывает объяснить как может быть, что при работе над сайтами люди никогда её не открывают). Но они есть (например я и те команды у кого я перенимал workflow, и кому передавал), как и есть те кто иногда меняет пару строчек кода в админке MODX минуя IDE (это не я)…
Но всё-таки знать, что полностью не вылезая из админки есть возможно работать — это очень хорошо, особенно для новичков.
Способ установки дополнения — интересный, и видно что много пользы под капотом!
В рамках фидбека, озвучу пару моментов, которые настораживают
• Дружелюбность установщика в консоли — не удобно от слова совсем. Возможно для тех кто разрабатывает фреймворки, CMS, и модули к ним, такой метод ок, но для тех, кто собирает сайты и лендинги — очень не очень, и отпугивает новичков системы (потому что в WP и Битриксе консоль не нужна чтобы собрать сайт)
• Тащить на фронтенд 430Кб CSS и JS для форм (которые 1,7 мб не сжатые) во времена расцвета повсеместной погони за PageSpeed для UX и SEO — для меня прямо стоп-фактор. Это в 10 раз больше, чем тащим для полнофункциональных форм сейчас:
— менее 40 килобайт на весь зоопарк (тоже сжатое, не gzip правда, а brotli, но там разница в ~10%)
C этим для затаскивания в продакшен mmxForms надо что-то будет делать… Может для форм в личном кабинете подойдет и как сейчас, но для страниц, куда из поиска посетители приходят — в таком виде пока не вариант.
P.S. А конструктор Vueform интересный конечно, Formalicious попроще будет, класс!
Спасибо всем кто участвовал! Вместе мы делаем MODX лучше и удобнее, и это круто!
Все собранные донаты отправились в пользу автора компонента-преемника: FileMan by @Наумов Алексей!
Я проводил тесты, и да, из-за особенностей реализации через галочку «Статичный файл», на 10%-15% медленнее отрабатывают все шаблоны-чанки. В процентах кажется много, а в абсолютных числах разница типа в 0.1 сек на медленных сайтах, и ещё менее заметно – на быстрых.
А вообще, человечество, в лице @Prihod изобрело StaticElementsLive, рекомендую обратить внимание!
И ещё, в свежих версиях MODX (ну уже года полтора как, может больше) появились настройки автоматического создания статичных элементов.
Я к PhpStorm пришел после Dreamviewer и NetBeans. Редакторы по типу Sublime, Notepad++ или Atom (из которого вырос VSC) всегда казались блокнотами с доп. функционалом, на фоне этих мощных IDE.
То, как вырос VSC конечно впечатляет (и как он обогнал популярнейший когда-то Sublime), но стоит ли идти на него из «другой лиги» IDE, вопрос открытый конечно…
Ну чтобы редактировать файлы, дополнять серверный софт что-то не хочется. Для любых других редакторов (да и того же VSC если не в проектном режиме использовать а просто файл удаленный открывать через WinSCP) хватает поддержки SFTP (Через SSH который)… Вроде на странице по ссылке Remote-SSH требование установленной nodejs не нашел, так что это обнадеживает!
Конечно, для человека, который использует PhpStorm без плагинов и расширений, не иначе как джунглями представляется VSC…
В PhpStorm всё просто работает: подсвечивается, переходится по клику и автодополняется, бандлится и минифицируется и т.п., без необходимости даже открывать консоль, и уж тем более перебирать (нет, не изучать) бесконечные подборки плагинов в интернетах…
Но крутого расширения для MODX из этого поста, для PhpStorm пока нет, так что хватаем мачете и прыгаем в джунгли VSC, получивший второй шанс! :)
Необходимый минимум функций вот такой:
• Автозагрузки на сервер (SFTP) по CTRL+S (желательно без хранения учетных данных от удаленного сервера в JSON-файле рядом с исходниками)
• Перехода к объявлению JS/PHP-функций по CTRL+click
• Сборки CSS из LESS/SCSS исходников, но без бандлеров (как file watchers в phpstorm) и мудреных JSON-конфигов.
Просто года два назад такой простой набор не получилось собрать для VSCode и мне пришлось его опустить. Но я вижу, что всё меняется, и с тех пор VSC стал настолько лучше, что я рискнул заменить им (и пока не пожалел) notepad++ для открытия одиночных файлов (которые вне проектов), которым пользовался много лет (правда зарешал дизайн, а не функционал, но всё таки). Но как проектным редактором, мне осадочек от предыдущего подхода пока не наёт пользоваться.
Посоветуйте джентельменский набор модыксера (или модэксера?) для VSC плиз!
Вообще Developer experience (DX) в MODX и раньше был очень неплохим. Кто касается других систем, очень меня сейчас поймут. Один только Ace, который поддерживает @Иван Бочкарев чего стоит. Если править что-то быстро из админки, и связка modDevTools + Ace = просто класс!
А если и если основную разработку чаще ведут в файлах, под git-ом, и тут уже связка StaticElementsLive и новый VSCode IntelliSense for MODX будет отличным решением!
А для тех, кто собирает пакеты (modx packages), и особенно если их часто обновляет, поддерживая более одного modx-пакета постоянно, также может пригодиться git-модуль с GUI: modx-build-environment-gui
Вообще, с выходом этого плагина для весь DX при работе с файлами в MODX переходит на другой уровень, на голову выше! Больше cпасибо @Баха Волков !