Василий Наумкин

Это все равно если бы мы писали программу на php, переносили ее на продакшен, так запускали локальный веб сервер php

Вообще-то, именно так и происходит.

Сам Nginx умеет отдавать только статичные файлы, а обработку php он передаёт другому процессу. Как правило, это php-fpm, который непрерывно крутится в памяти сервера. И для запуска нового сайта на хостинге этот процесс нужно перезапускать.

Разница лишь в том, что сервер php запускает ваш хостер. А сервер node.js нужно запускать самому. Но это говорит лишь о неразвитости хостинга для node. Я могу себе представить с будущем хостинги для node, где всё будет настроено так же удобно, как сегодня для php.

Ровно так же Nginx может отдавать обработку запроса в ruby, python, go, опять же в node.js и еще много куда. Сам Nginx этого ничего не умеет, потому что он reverse-proxy server.

Для справки, Apache2 работу с php тоже сам по себе не поддерживает, он это делает через встроенный модуль mod_php, который может быть и отключен.

Да, свой полноценный сервер со многими фишками — v3.nuxtjs.org/guide/concepts/server-engine/

Работа с БД не зависит от вида сервера — он просто будет выполнять ваш код.

И кстати Express раньше ставился «из коробки» при установке Nuxt, а теперь этого почему-то нет.

Потому что не нужно — у Nuxt есть свой собственный сервер, лучше его и использовать.

Ну раз ты не видишь проблемы — исправляй и шли коммит в репозиторий MODX.

Не понял почему это нельзя исправить.

Потому, что тогда парсер перестанет быть рекурсивным и ты не сможешь делать вот так:

[[~[[+id]]]]

Смысл в том, что после разбора внутреннего тега [[+id]] получается новый тег, например [[~9]], а он уже превращается в ссылку на документ с id = 9.

То есть, нужно парсить этот тег минимум 2 раза — это и есть рекурсия. Так весь MODX и работает, это его чуть ли не основная фишка.

Как ты исправишь основную фишку рекурсивого парсера — рекурсивный разбор тегов? Это просто такой метод работы, который очень многим в MODX и нравится. Напихать тегов друг на друга, парсер сам разберётся.

Ну а замена простых плейхолдеров… Самый главный архитектор системы об этом давно знает и ничего менять не хочет.

Хочешь исправить — ставь pdoTools и пользуйся, для того расширения и нужны.

А кроме комментариев есть ещё примеры?

pdoTools появился не на пустом месте, а потому что я делал разные сложные сайты, включая bezumkin.ru

К самому тесту замечания есть?

Ты даже кода чанков не привёл, тупо итоговые цифры и заявление, что разницы нет.

Если ты эти тесты проводил на одном сайте, и парсер pdoTools был включен — то поздравляю, ты уже пользовался оптимизациями, потому что pdoParser разбирает простые плейсхолдеры сам, без modTag.

Я прямо сейчас создал 2 сайта на modhost.pro. На один установил pdoTools, а на другой нет.

Тестовый сниппет:

<?php
$items = [];
for ($i = 1; $i < 10000; $i++) {
  $data = ['id' => rand(), 'pagetitle' => 'page' . rand()];
  $items[] = $modx->getChunk('test', $data);
}

$output = number_format(microtime(true) - $modx->startTime, 4) . "\n";
$output .= number_format(memory_get_usage() / 1048576, 4) . "mb\n";
$output .= implode("\n", $items);

return $output;

Простейший чанк:

<p>[[+id]] - [[+pagetitle]] [[+id:is=`10`:then=`1`:else=``]]</p>

Обрати внимание, что чанк без Fenom, чисто синтаксис MODX.

Смотрим на 10000 проходов, чтобы разницу было хорошо видно:

— MODX без pdoTools — 1.3216 сек (самый быстрый результат, что удалось увидеть)
— MODX c установленным pdoTools — 0.0557 (самый тормозной результат, было и 0.0156).

Внимание, pdoTools просто установлен, и работает по умолчанию. Никаких специальных оптимизаций.

Теперь понятно, что парсер MODX без pdoTools просто тормозное говно и твои тесты ни о чём?



Updated 26.04.2022
Попробовал повторить тест еще раз и не смог — оказалось, что я допустил ошибку. Если сниппет использует $modx->getChunk(), то разницы в скорости не будет, потому что pdoParser тогда не работает.

Сниппет должен использовать $modx->getService('pdoTools')->getChunk('test', $data);, тогда всё быстро.

Всё проверил еще раз и накатал новую заметку с результатами.

Даже 100 ресурсов — это большая редкость.

Я тебе привожу пример, что нет — не редкость.

Как справится парсер MODX с выводом такой ветки комментариев, если он каждый тэг и условие будет превращать в modTag и запускать его parse?

PHP шаблонизатор всё еще только про удобство, а не скорость?

Вот в этой заметке сейчас 890 комментариев и она выводится плюс-минус за 1 секунду на Fenom с разными условиями.

Выводится без кэша, потому что комментарии отличаются для каждого юзера. Админу выводятся удалённые, автору подсвечиваются его ответы и т.д.

Попробуйте это повторить на парсере MODX. Не думаю, что вывод комментариев на сайте это прям такая уж редкая задача.

А ты что хотел, чтобы американцы про российский pdoTools рассказывали?

Правда, народ на запрещённом сайте тоже недоумевает

Я бы предложил вместо miniShop2 3.0 сделать просто miniShop3

Это сняло бы массу проблем с расположением файлов, переездом рабочих сайтов и разработкой дополнений. Тем более, что домен для него давно куплен и ждёт своего часа — minishop3.com

В описании сказано, используются jQuery.Form и jQuery.jGrowl.

То есть, ему нужен jQuery.

Можно ли обойтись без него?

Я даже не буду ничего отвечать, и процитирую самого автора:

Самый клоунский комментарий, который вызывает улыбку :)))

Да, если брать за уникальный id хэш от параметров сниппета и получать его потом из запроса юзера — рабочий вариант. Даже, пожалуй, хороший.

Но тут сразу второй вопорос — каждое дополнение будет устанавливать собственную такую таблицу? Или они все должны использовать какую-то общую? Если общую — как дополнениям об этом договориться, требовать какую-то зависимость, типа нового дополнения AjaxSettingsDB?

И если у вызова сниппета будет какой-то уникальный параметр, типа id юзера, то количество записей в такой БД будет ровно тем же, что и у таблицы сессий. Еще встаёт вопрос еще об очистке этой таблицы — сколько дней хранить в ней настройки?

Но, повторюсь, этот вариант мне нравится и в былые времена я мог бы переписать свои дополнения на хранение настроек в одной общей таблице. Кто сейчас это будет делать — вопрос.

Наверное, я просто не так часто пользовался вкладкой releases.

В репозитории та же версия, что и на modstore.

Ничего передавать не нужно, это Open Source — любой человек может сделать форк и выпускать свои версии с любыми исправлениями.

Архивация репозитория означает, что лично я им заниматься не буду, только и всего.

Отличная идея для дополнения!

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

Тот же вариант, что и настройки в файлах, только в БД.

Если работа сниппета зависит от каких-то динамических параметров (id юзера или группа), то точно так же замусорит базу данных. При этом, насколько я помню, возможностей по расширению логики работы там поменьше, чем у modSession.

Да и взять и разом почистить modRegistry из админки нельзя.

Да без проблем, буду заносить как только начну хоть что то получать а не вкладывать то сразу проплачу рекламу на modx.pro.

А, ну тогда и не пиши сюда.

А до тех пор — я пост убираю.

Где-то в этом рекламном посте есть рассказы о технологиях?

Или кто-то впервые прочитал про Laravel именно здесь?

Не вижу ничего плохого в том что б немного прокламировать себя да и может наконец-то избавлюсь от статуса просто фанат EVO.

Так может тогда и денежку пора начать заносить за рекламу?

А то спасибо сам себе говоришь, а modx.pro — нет.