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

Крутые обновления! Просто класс! Спасибо!

Хотел уточнить:

Scheduler… Для MiniShop3, я (что логично) планирую и дальше использовать эту систему, дополнив ее новым заданиями. Но как оказалось компонент не поддерживает MODX3 — а значит мне придется выпустить аналог.

Есть предложение поддерживать Fork, а не плодить компоненты!
У меня даже есть концепт, как отличать компоненты, у нас есть постфикс версии, как правило это -beta или -pl (и даже -pl2 и т.п.). Я анализировал код установщика и не нашел никаких опасных привязок к этим постфиксам.

А значит, мы можем использовать постфикс в стиле:
Scheduler 1.4.1-pl → Scheduler 1.4.1-modx-pro, где modx-pro — github-логин автора форка. Довольно системно получается, и ничего не сломает. Можно использовать и в других компонентах аналогично!

После этого спокойно выпускать новые версии, не оглядываясь на оригинальный пакет. Раз уж там не понятно почему, не принимают PR-ы (вроде этого), из-за чего, полагаю @Николай Савин и не рассматриваешь изначально затащить туда поддержку MODX3 (хоть она и заявлена у оригинального автора).

Что скажете, коллеги?

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

Есть есть желание работать в таком режиме, посмотри на FrankenPHP worker mode → вроде то, что то описал по поводу переиспользования настроек без похода в базу и т.п… Но по-моему это перебор. Потому что приличные SSD/NVME диски уже давно кладут в память часто используемые данные (это будут файлы кэша), а файловое кэширование в MODX есть по умолчанию — просто используй кэш, когда тебе нужна эта магия :) Какое еще ещё нафиг NodeJS?! Я не говорю, что он плохой, просто говорю что незачем лезть в другую вселенную, чтобы получить хорошие показатели скорости!

P.S. А вот сервер на windows (подсмотрел твоё соседнее собщение) очень даже может быть причиной проблем со скоростью. Там нужен особый тюнинг, для которого не так уж много рецептов. Я встречался с таким, победить не получалось, переезжали.

Полностью согласен с недостатками реактивных фреймворков, описанных в заметке, думаю 100мс на инициализацию бекенда это очень много — что-то не так с хостингом, или что-то очень тяжелое прикручено в плагинах на события onmodxinit или где-то ещё по пути до рендеринга. Про то, что фронтенд-часть весит какие-то огромные мегабайты, я писал также в комментах под mmxForms — но в принципе, для какого-то функционала админа, или зарегистрированного пользователя.

У меня на проектах по 20-30мс на полный ответ сервера, без какого-то рокет-турбо-тюнинга (а с ним — быстрее, но сейчас не об этом).

Мне пока удаётся в большинстве проектов убегать от этих адских фроентенд-фреймворков. Надеюсь удастся полностью пережить их рассвет, встретить закат, и классно-здорово работать на набирающем популярность (снова) серверном рендеринге технологии HTMX, которая отлично ложится в концепцию того, как работает MODX, с чанками, крутыми шаблонизаторами и т.п.

P.S. Тоже интересно, для чего реально используешь @Александр Туниеков gtsAPI. Задумка интересная. Не переписываешь ли потихоньку всю админку на формы VUE? ))

Спасибо что делишься!

Вообще чем-то похоже на работу пакета BannerY получилось кстати. Только опять же, со срабатыванием каждый год. На самом деле для ежегодных праздников твой вариант подходит конечно идеально!

Пользуюсь похожей конструкцией, чтобы редактировать 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?