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

Это путь от корня на сервере?
Вот я форкнул один из пакетов, хочу подправить код и собрать новую версию для теста. Предполагается что я всё это заливаю в корень установленного MODX. Папка _build сразу содержит установочные скрипты, из-за чего я не могу использовать готовую установку MODX, где поддерживаю другие пакеты.

Вот этот путь /Extras/ModxExtraName/ откуда берется? Корень / перед /Extras/ где смонтирован? У меня это примерно так на хостинге /home/user/data/www/modx.test.ru/ и вот отсюда уже идут ...modx.test.ru/_build/ и так далее.

А вообще, есть предложение ко всем, кто собирает MODX-пакеты!

Давайте в билдерах в папку ./_build/ вкладывать ещё подпапку с названием пакета
Сейчас структура папок:
./_build/build.config.php
./_build/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…

Предлагаю делать так:
./_build/ModxExtraName/build.config.php
./_build/ModxExtraName/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…

Это позволит не вычищать каждый раз _build перезаливкой другого пакета. Ведь организовать подпапку — это логично и красиво.

И даже не обязательно использовать modx-build-environment-gui, он просто сканирует папку _build, парсит версии для сборки и даёт список ссылок (гордо именуемый тем самым GUI), чтобы поменьше клавиатуру пальцами полировать :) но сам ничего больше и не делает. Даже ссылку на скачивание собранного транспортника уже выдаёт билдер самого пакета, если поддерживает согласно инструкции…

В общем так или иначе, круто что наконец мы добрались улучшать Developer Expierence! Чем проще создавать и поддерживать компоненты, тем лучше для экосистемы, и для сайтов, которые на поддержке, и для наших нервов ;)

P.S. Может перенести в заметки и раскрыть тему, есть желающие? Ставьте лайк, если интересно :)

Так и я не сравниваю, ты ведь в своём решении в Докер-ом предлагаешь вообще типа в режиме одноразовой копии запускать движок MODX для работы с пакетом, а файлы во внешней среде хранить как я понял. Это здорово! Но одно другому не мешает =)

Ну это к слову… А теперь к твоей теме: я сам на windows работаю, и докер локально не использую, но изучаю тему и поюзываю на серверах (как минимум потому что иногда другого не предлагается...). И вот читаю конфиги твои и есть вопрос: а почему ты не монтируешь в локальную папку директорию _build? Тебе же не только правки в код вносить, но и собрать надо пакет, или другой у тебя workflow?

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

P.S. Он теперь в копилке репозиториев MODX RSC будет, или исходники останутся закрытыми?

Вам бы, коллеги, скооперироваться чтобы список ботов (user agent-ов) общий использовать для botAim и SmartSessions)

Предлагаю, если нужно, захостить его там же, где статистика установки компонентов, в надёжной инфраструктуре одного из крупных ДЦ. Я поспособствую!

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

С каждым годом всё больше и больше проблем от ботов. Ваши решения (Алексея и Андрея) очень помогают, и необходимость в них только растёт!

Андрей, привет! Спасибо что делишься, конечно Win-пользователей опять докер-мэны обходят стороной, обидненько :) Но переживём.

Меня вот этот вопрос заинтересовал:

Мой подход всегда был таким: 1 сайт, одно дополнение

А ведь использование сборщика разных пакетов не было бы такой проблемой, если бы когда-то давно этот момент предусмотрели создатели шаблонных пакетов…

Я уже давно придумал как это решить для себя, а недавно выпустил для всех! С помощью git submodule можешь подключить в любой пакет и пользоваться тоже → github/dimasites/modx-build-environment-gui welcome!

Выглядит «интерфейс» вот так:

(это ссылки на сборку каждого пакета, все на одном установленном MODX)

Концепция до безобразия простая — положить исходники в папку с названием дополнения =)
Один раз переносишь, и поддерживать становится проще!

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

<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-)