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

Да, это конечно сложнее чем запустить первичную установку WP или MODX

Это просто 2 разных уровня сложности и мастерства.

На MODX и WP можно пилить сайты вообще без знаний, просто кликая мышкой. А Nuxt и прочее Node.js это уже для серьёзных специалистов.

Придётся учиться, но оно того стоит.

Это все равно если бы мы писали программу на 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 именно здесь?