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

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

P.S. Поправь плиз отступы в форматировании кода во 3 и 4 блоках, а то я shift+tab чуть не нажал машинально, когда читал :)

Ух ты! Осенний код подъехал, спасибо! Всегда жара с заявками в праздники, может и пригодится!

Тоже решаю такие квесты регулярно, поэтому позволю себе задать вопрос)

Просто интересно, а ты не пробовал стандартные для Revo планируемые даты публикации прикрутить для этих целей как-то?

Имею в виду перед тем, как решение выработал. Сниппет конечно круче, т.к. он универсальный, один раз поставил, и будет срабатывать каждый год))

Тоже горожу сниппеты, но сейчас подумал, что по-простому кажется можно было типа такого

[[#8.published:is=`1`:then=`[[#8.content]]`]]

выводить в шаблоне страницы, а в стандартных полях ресурса (с id=8 из моего примера) ставить планируемую дату публикации, и снятия с публикации, вот эти:


Как думаешь, @Денис Усманов, рабочая это схема для одноразовых событий?

Привет! Спасибо за решение, сорри не могу плюсануть уже, время прошло, вовремя не заметил!

Я же правильно понимаю, что можно не делать одноразовый сниппет, а просто запустить его код через компонент Console или подобный?

И ещё есть вопрос по SEOSuite, пользуясь случаем. Они там решили вопрос с тем, что компонент создаёт большую секцию своих настроек в админке для каждого ресурса? Там эта секция была выше, чем секция с основным контентом (и соответственно с секцией TV-шек, если их системной настройкой `tvs_below_content` перенести тоже на первую вкладку в админке где страницы редактируешь) и из-за этого осложнялось редактирование контента на мой взгляд (SEO-настройки маячили и лишний раз мешались). Помню из-за этого даже кто-то ставил старые версии, SEOtab вроде… и ждали фикса, сообщив разрабам на github. Это пофикшено в свежих SEOsuite?

В примерах выше просили вывод ShowLog. В твоём случае нужно сделать то же самое. Естественно, нужен полный вывод. А то твой обрывается на тайминге 0.0152969 (это в секундах, довольно быстро).

Возможно у тебя тормозит что-то другое, попробуй поставить debugParser и открыть страницу с параметром &debug=1 из-под админа и кидай сюда таблицу.

P.S. Нормальный такой некропост спустя 10 лет, но в целом почему бы и нет))

UPD: Так на сайте и страницы каталога переключаются по 20секунд. Это надо дебажить уже сам mSearch2 (mFilter2 вернее). Как правило, где-то там в чанке лежит нечто очень медленное…

Степан, спасибо что поделился!
Проверь плиз заголовок, что-то с ним не так)
Предлагаю допилить вот так: «[ruAgo] Дорабатываем output filter ":ago" на склонения по-русски»

Привет! Автопубликация это круто! Спасибо за компонент!

Есть ряд вопросов перед стартом:

Планировщик встроенный, или интеграция с компонентом scheduler? Нужен cron или на хитах? Если второе (без cron-а), то настройки увеличения количества хитов в промежутках между запусками для сайтов с большой посещаемостью есть?))

А картинки-видео из TV нестандартных типов (image+ например) поддерживаются? А галереи на MIGX?

Можно привести текст из этого файла readme.txt здесь хотя бы?
Не всегда под рукой есть тестовый сайт ведь!

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

Для второго (и последующих) контекста, то есть того, который имеет имя (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>