Дима Касаткин

Привет! Давно не виделись)) Когда изучишь что сейчас актуально, удивишься, что для сайтов всё ещё актуально MODX, хоть 2 хоть 3 версия. Веб-приложение или сервис лучше на микросервис-ориентированном фреймворке пилить конечно, а если именно сайт… Ну попробуй WP и Joomla, но с даже давним опытом в MODX будет крайне некомфортно.

Из статьи:

… если вы забудете правильно удалить зависимость, и сайт упадёт — никаких проблем, просто установите её обратно и удалите как положено.

Вы же всё равно это делаете из консоли сервера и нерабочая админка вам никак не помешает всё починить.

Зная разработчиков, могут и не заметить что сайт упал. Так что работа из админки даёт сайд-эффект пассивной проверки работоспособности)

Лучше всё-таки консоль использовать как fallback, а не как основной инструмент. ИМХО.

2. Как отвечать на вопросы от Composer при разруливании зависимостей?

А если помечтать, потенциально возможно прикрутить UI и всё-таки ставить пакеты из админки, ну бывает же Web UI для composer…?
(кстати сделано на твоём плюс-минус стеке? из 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 (ну уже года полтора как, может больше) появились настройки автоматического создания статичных элементов.

Думаешь, это работает также, как мода на короткие носки? – ну кстати очень может быть 8-)

(главное не скачивать все подряд плагины)

Ну точно джунгли этот VSCode :) В скачивании плагинов подстерегает опасность?))

Я к PhpStorm пришел после Dreamviewer и NetBeans. Редакторы по типу Sublime, Notepad++ или Atom (из которого вырос VSC) всегда казались блокнотами с доп. функционалом, на фоне этих мощных IDE.

То, как вырос VSC конечно впечатляет (и как он обогнал популярнейший когда-то Sublime), но стоит ли идти на него из «другой лиги» IDE, вопрос открытый конечно…

Спасибо за развернутый ответ!

Редактировать файлы на сервере… официальное расширение Remote-SSH… На сервере нужен только nodejs

Ну чтобы редактировать файлы, дополнять серверный софт что-то не хочется. Для любых других редакторов (да и того же VSC если не в проектном режиме использовать а просто файл удаленный открывать через WinSCP) хватает поддержки SFTP (Через SSH который)… Вроде на странице по ссылке Remote-SSH требование установленной nodejs не нашел, так что это обнадеживает!

Конечно, для человека, который использует PhpStorm без плагинов и расширений, не иначе как джунглями представляется VSC…

В PhpStorm всё просто работает: подсвечивается, переходится по клику и автодополняется, бандлится и минифицируется и т.п., без необходимости даже открывать консоль, и уж тем более перебирать (нет, не изучать) бесконечные подборки плагинов в интернетах…

Но крутого расширения для MODX из этого поста, для PhpStorm пока нет, так что хватаем мачете и прыгаем в джунгли VSC, получивший второй шанс! :)

Всем привет! Я пока не осилил всех лонгрид-комментов в этом топике, но точно знаю, что @Fi1osof лучше вот так призвать, более технологично, и может даже сработать :)

Пользуясь случаем, если у кого есть под рукой, кроме супер плагина из топика, какие ещё плагины надо поставить в VSC для удобной работы с MODX.

Необходимый минимум функций вот такой:
• Автозагрузки на сервер (SFTP) по CTRL+S (желательно без хранения учетных данных от удаленного сервера в JSON-файле рядом с исходниками)
• Перехода к объявлению JS/PHP-функций по CTRL+click
• Сборки CSS из LESS/SCSS исходников, но без бандлеров (как file watchers в phpstorm) и мудреных JSON-конфигов.

Просто года два назад такой простой набор не получилось собрать для VSCode и мне пришлось его опустить. Но я вижу, что всё меняется, и с тех пор VSC стал настолько лучше, что я рискнул заменить им (и пока не пожалел) notepad++ для открытия одиночных файлов (которые вне проектов), которым пользовался много лет (правда зарешал дизайн, а не функционал, но всё таки). Но как проектным редактором, мне осадочек от предыдущего подхода пока не наёт пользоваться.

Посоветуйте джентельменский набор модыксера (или модэксера?) для VSC плиз!

Впечатляющая работа! Было бы здорово такое же, для PhpStorm / WebStorm, но ради такого возможно стоит дать VSCode второй шанс. Теперь есть причина, по которой VSCode может оказаться удобнее PhpStorm для разработки под MODX, и это прекрасно!

Вообще 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пасибо @Баха Волков !

Так обсуждали тут уже ранее: форкнуть запрещают, ошибки не исправляют, правила modstore компонент с идентичным функционалам не пропустит, а без переиспользования существующего кода там половину функционала компонента (плагин на сохранение, индексирование) по-другому особо и не сделать — используются лучшие практики для MODX (я и выше писал, что компонент крутой).

Так что там замкнутый круг.
Выход в опенсорс решил бы эти проблемы, но… его же покупают и так, зачем же дарить :) но видимо не достаточно покупают чтобы была мотивация его развивать, ну или наоборот, развитие заключается в накатывании фиксов в рамках техподдержки или доп. услуг после продажи… Тут я не в курсе, но факт в том, что он устарел и серьезного развития в нём нет. Хотя вроде как готовится бета для MODX3 что на самом деле круто!

Альтернативы чему именно?

Спасибо, читается на одном дыхании) Все признаки хорошего поста, и кликбейтный заголовок, и картинки, и примеры, и даже легко-троллинговая опечатка в финале :) Зачётно получилось!

Спасибо @Евгений Шеронов за твой вклад, и этот позитивный шаг навстречу сообществу — дал вторую жизнь компонентам, а не забросил, заблокировав тем самым ещё и возможность появления обновленных и улучшенных форков (как случилось с крутыми, но устаревшими mSearch2 и mFilter2).

Я считаю что в долгосрочной перспективе, компоненты с работой по подписке для коммерческих проектов — лучший вариант. Так что будем очень рады предлагать про-версию своим клиентам, если ты всё-таки задумаешь её сделать.

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

@Артур Шевченко лови донатик, восполни потраченные на написание анонса калории :)

Друзья, всем кому интересны новые компоненты, не забывайте тоже про раздел Поблагодарить автора под каждым постом здесь!

Интересное решение, особенно то, что не требует вызова сниппета!
Будем пробовать на следующем же проекте!

В будущем планирую создать в админке интерфейс для управления формами, аналог Formalicious, только название попроще придумаю.

Может я в своём стиле конечно, но товарищи, Formalicious — OpenSource компонент. И сделан достаточно универсально. Я недавно использовал его, нашел кучу несоответствий документации неочевидных моментов, подготовил код для PR как в него (в том числе русские лексиконы), так и в его доку.

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

Интеграция между компонентами я считаю очень хороший и правильный путь. Пусть лучше будет модульность (не обязательно использовать в паре) между компонентами, но результат от вложенных усилий будет точно лучше, чем автономность и дублирование функционала!

P.S. Ура, красивая демо-страница :) отдельное спасибо за неё

А можно чуть подробнее о таком сценарии использования? Я всегда использовал UserFiles если нужна работа с картинками, или FileAttach если просто файлы, но со показом размера и счётчиком скачиваний.

Первый платный, а FileAttach нет, за что спасибо @Виталий Чекрыжев!

И к стати мы обновляем сейчас под MODX3 этот самый FileAttach. Не откажемся и т от вашей подделки в сборе на апдейт!

Привет! Подкинь плиз ссылку на те самые рекомендации Google, о которых речь то!

Ну а в целом, сниппет pdoSitemap разсчитан на создание карты сайта с расчетом на то, что бщвч-ресурсы у вас будут выполнять роль страниц (контентных или товаров), а если ты сделал специальный тип ресурса (Custom Resource Class) или через Collections или MIGX собрал видеогалерею для сайта (или через модуль), то проще всего через pdoResoutces выбрать все видео, и обернуть каждый чанком с кодом, который приведён выше, да и на самом деле разместить второй ссылкой на дополнительный файл sitemap.

Ну также, как разметку schema org или JSON-LD всегда делаем, только получается надо со всего сайта в 1 «файл» собрать (в данном случае будет динамическая страница, но «Тип содержимого» (Content Type) можно выставить как XML и страница будет выглядеть xml-файлом.

В таком стиле:
sitemap.xml содержит 2 ссылки:

1. sitemap-pages.xml
2. sitemap-video.xml

Желаю успехов! Можешь выложить потом пост в разделе готовых решений здесь?