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

Привет! Если это было связано с багом/фичей компонента, а не с особенностью вашего конкретного сайта и кастомных доработок — было бы здорово получить наводку, куда копать в случае проблем, спасибо!

Для второго (и последующих) контекста, то есть того, который имеет имя (key), отличное от web. Где там какой домен или поддомен, разницы нет. Как надо чтобы открывалось, такой адрес и пиши. На хостинге все эти домены направляй в одну папку.

НО! Если у тебя и правда из двух установленных MODX в разных папках, у которых в core/config/config.inc.php указана одна и та же база с одинаковым значением $table_prefix — то я не знаю что тебе посоветовать, кроме как не пользоваться одной из папок, а настроить работу поддоменов через контексты, как указал выше.

Дело в том, что в MODX используется файловый кэш, в т.ч. системных настроек и т.п. В момент, когда ты очищаешь кэш, он удаляется и папки core/cache/* и как раз из-за этого могут быть проблемы. Наверное, если отключить вообще весь кэш, то всё будет работать, а почему бы и нет (в познавательных-то целях). Данные все в БД. Отключай короче все кэши, чтобы ничего не записывалось на диск, а всё было в Базе Данных… Но опять же, всякие фотографии, скрипты и стили для фронтенда, они же лежат на диске. При установке любого компонента, его файлы кладутся в папку с установленным MODX, а информация записывается в БД. Из другой папки будет видно инфу, а файлов нет — скорее всего будут ошибки.

Предполагаю, что комфортная работа не возможна в таких случаях. Но не уверен, возможно в кейсах, когда выносится core из корневой папки, можно использовать его в нескольких установках, но так я ни разу не делал, а в MODX3 такую возможность убрали, так что уже и не представится возможности.

Короче, используй 1 установленный движок, и контексты :)

Это может быть очень удобно, если шаблоны одинаковые либо похожи, контент пересекается (например компания и её филиал, или диффузный бренд или просто раздел вынести на поддомен company.com и blog.company.com нужно сделать по тем или иным причинам.

У каждого контекста свои настройки, их можно использовать в шаблоне (те же контакты в шапке и т.п.).

Бонусом получишь обновление движка и пакетов на оба сайта, 1 раз вместо двух создашь любимые TV (обложка для страницы или галерея), 1 раз купишь платный компонент и так далее. На мой взгляд например, совсем не дичь, для этого (в числе прочего) контексты и придуманы в MODX!..

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

Создай второй контекст, создай плагин (в элементах в админке) назови например 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 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!