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

* поправочка:

<base>

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

То что ты руками указал, и сработало, это вроде как хорошо, но решить системно было бы ещё лучше!

В свежей версии MODX были правки в указанной части дефолтного конфига, и хотелось бы понять, есть ли недочёт в новой версии, или просто у тебя сайт со времён HTTP не был перенастроен на HTTPS и действуют какие то старые настройки. В любом случае я хотел бы подтвердить, что именно обновление приводит к смене протокола в url, а не что-то другое.

Я уже несколько десятков сайтов обновил и нигде такое не всплыло, вот в чем дело. Но ещё больше предстоит обновить и лучше бы я знал, если проблема и правда есть ;-)

Кстати, добавлю к списку вопросов выше ещё:
— не установлен ли у тебя тег в вёрстке? Если да, в каком значении?

Привет! У меня нет возможности проверить по http (без https) но вот сейчас проверил на паре сайтов из тех, что обновил — всё выводится как надо, значение настройки содержит https:// в начале.
Чтобы помочь тебе, дай больше инфы:
1. Проверь в системных настройках и в настройках контекста, может у тебя руками указано значение где-то?
2. По какому протоколу открываешь сайт, когда настройка выдаёт неверное значение? Например по https. А если по http открыть (без редиректа на https) — как себя поведет настройка?
3. Какой протокол указан в настройке [[++server_protocol]]?

Обновил сегодня несколько проектов, которые на PHP 7.4.

Всё прошло хорошо, без сюрпризов и ошибок! Надеюсь, у всех так же ;-)

Благодарю за полезный материал!

Для тех, кто захочет воспользоваться решением, рекомендую заменить JS-комментарии (/* такие */) на fenom-комментарии ( {*на такие*} ) чтобы на фронтенд не выводить их!

И всё для того, чтобы пользователи не начинали развиваться.

Василий, прекращай пожалуйста путать развитие разработчика (программиста, ИТ-гика, кодера, PHP-шника и т.п.) с развитием например маркетолога, который собирает сайты на MODX CMS (вместо Wordpress и Битрикс и etc) чтобы иногда пригласить разработчика на сложные задачи.

Дружелюбность системы, баланс её простоты и функционала, скорость развёртывания позволят её развиваться и привлекать новых пользователей.

Развитие!=Усложнение. Часто бывает наоборот, у гиков реже. Но для гиков уже есть фреймворки с их усложнениями на любую глубину погружения, а MODX крут тем, что сохранял баланс простоты.

Или сделать проще слишком сложно ?)) (Вот он и вызов!)

Приветствую! Отличная новость про фильтры, впечатляющая скорость, жду релиза с нетерпением, с удовольствием поучаствую в развитии (в документации, и как ещё получится). Потому что развитие системе поиска и фильтров, которые уже есть для MODX, давненько не хватало!

Тоже есть пара вопросов:

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

1. @Артур Шевченко, а сниппет(ы) компонента умеет(ют) передавать в чанки все указанные в вызове параметры? На мой вкус при сборке сайта очень частно нужно добавить какие-то параметры сверх тех, что предусмотрены документацией и влияют на логину сниппета, а просто доступна в чанке для проверки или использования значения.

Так, например, умеет делать pdoResources, но не умеет pdoMenu, и это очень не удобно…

2. Чанки на Fenom поддерживаются? И на квадратном modx-синтаксисе тоже? Разделение на row и outer в наличии, или предлагается на Fenom циклы крутить?))

3. Понимаю, что внедрение было на MODX2, но много ли логики в компоненте, которая отличается от MODX3 и какие перспективы по адаптации? На MODX3 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!

Привет! Давно не виделись)) Когда изучишь что сейчас актуально, удивишься, что для сайтов всё ещё актуально 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 что на самом деле круто!