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

Запустит довольно просто, как раз этим занимался сейчас :) решил и здесь написать:

Создай второй контекст, создай плагин (в элементах в админке) назови например ContextSwitch и подключи его на OnHandleRequest вот код:

<?php
if ($modx->event->name != 'OnHandleRequest' || $modx->context->key == 'mgr') {return;}

// Определяем запрашиваемый хост
$host = $_SERVER['HTTP_HOST'];

// Выбираем контекст с настройкой http_host
$q = $modx->newQuery('modContextSetting', array('key' => 'http_host', 'value' => $host));
$q->select('context_key');

if ($q->prepare() && $q->stmt->execute()) {
    // Получаем ключ контекста
    if ($context = $q->stmt->fetch(PDO::FETCH_COLUMN)) {
        // Web инициализируется в index.php - на него переключаться не нужно
        if ($context != 'web') {
            $modx->switchContext($context);
        }
    }
}

Далее в новом контексте укажи настройку (правый клик в админке → редактировать контекст) и добавь туда 2 системные настройки:
1. site_start (укажи id страницы в новом контексте, её нужно там создать и опубликовать) и это будет главная страница!
2. http_host (полный адрес url без https и слешей, например sub.example.com)

И всё должно заработать!

Когда уже, адепты и любители MIGX, вы запушите перевод на русский всех этих мудрёных колонок!? Смотрится интерфейс не лучше, чем смешанный синтаксис modx+fenom. Я уже и @Денис Усманов намекал про это, при случае! :)

Насколько я помню, не во всех последних релизах была проблема со старой версией PHP (с 7й), а в 2.8.6 и 3.0.4 (предыдущих на текущий момент релизах из ветки 2.х и 3.х).

Обновляйте на крайнюю версию в пределах своей мажорной ветки (ну и с большой аккуратностью и обязательным бекапом — с 2.х на 3.х), несовместимость обработчика изображений с PHP7 исправили в MODX 2.8.7 и в 3.0.5!

Демо вроде автор закрыл, а ссылка из поста на компонент вполне рабочая, или о чем речь?

Это путь от корня на сервере?
Вот я форкнул один из пакетов, хочу подправить код и собрать новую версию для теста. Предполагается что я всё это заливаю в корень установленного 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 (это не я)…

Но всё-таки знать, что полностью не вылезая из админки есть возможно работать — это очень хорошо, особенно для новичков.