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

Конечно.

Либо через mod_proxy, либо через mod_rewrite.

Так можно сделать только если на сервере всего один сайт, который займёт 80 порт.

А если сайтов 2 или более — то нужен Nginx или Apache2, которые будут разруливать запросы.

Очевидно, что на публичных хостингах тебе просто придётся работать с одним из них.

Да что ты говоришь.

Тут вот люди даже Hello World пока не могут вывести, а потом начнутся вопросы про реактивность, асинхронность и Vuex.

Для того, чтобы это стало простым и клёвым, нужно взойти на определённую высоту. После этого — да, оно всё просто. А вот MODX и WP наоборот кажутся очень сложными и неудобными, вот такой парадокс.

Насчёт ассемблера… Ну как покажешь веб-сайт на ассемблере, тогда и продолжим сравнения.

Да, это конечно сложнее чем запустить первичную установку 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 рассказывали?

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

getbootstrap.com/docs/5.1/migration/#rtl

Horizontal direction specific variables, utilities, and mixins have all been renamed to use logical properties like those found in flexbox layouts—e.g., start and end in lieu of left and right.

1. Это исходники, которые потом компилируются без комментариев. На качество кода наличие или отсутствие комментариев ни влияет вообще никак. Читать исходники с комментариями приятнее чем без них.

2. И если я укажу у кнопки определённый параметр, она отрендерится именно ссылкой, но с классом btn. Будет выглядеть как кнопка и работать как ссылка. Непонятно, что тебя смущает в таком функционале.



3. Я .vue файлы в этом репозитории вообще только в примерах нашёл. Может всё на JS и TS, чтобы код было удобнее расширять?

Мне тоже еще далеко не всё в этой либе понятно, но вот расширение компонентов я использую:

Ну хотя-бы потому, что первый коммит VueTailwind на Github был 20 марта 2019, в этот момент я уже использовал BootstrapVue 2.0 в своём проекте.

Tailwind тупо новый, и я не вижу причин срочно на него переезжать из-за того, что BootstrapVue слишком хорошо документирован =)

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

Ты какой ответ ожидаешь увидеть?

Для тех, кто зачем-то 50 раз в раз в неделю скачивает эту библиотеку с npmjs.org

А что с ним не так?

Про Tailwind, если что, я в курсе.

Меня смущает один момент, если такие компоненты начнут плодить, то это будет ужас!

По моим подсчётам, в modstore.pro добавлено 76 новых дополнений за последние 2 года — по 38 в год. Вряд ли кто-то сейчас завалит новинками все репозитории.

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

Хотя как минимум MoreGallery и ContentBlocks не используют ExtJS, являясь при этом очень популярными платными дополнениями.

Нарушается общая стилизация и админка будет похожа на франкенштейна.

Это ж от разработчика зависит. В моей заметке есть и видео, и картинки — тебе кажется это монстром Франкенштейна? Лично мне нет, в отличие от вёрстки таблицами и кривой мобильной версии.

Есть системная настройка, отключающая загрузку собранных стилей Bootstrap. При желании можно написать свои, идентичные родным админочным. Смотри, опять же, пример с дополнениями от ModMore.

Вряд ли кто-то бы отказался от качественно переписанного интерфейса miniShop2 и Tickets на VueJS, с нормальной адаптивностью.

На сколько я понял, это статья для тех кто не хочет связываться с ExtJS но очень нужно сделать на MODX, таких я думаю, что очень мало здесь.

Скорее о том, как притащить современные технологии. Это для тех, кто не хочет застрять в 2015 году, и я надеюсь, тут таких много.

Отдать задачу разработчикам, которые работают с MODX.

Много ты знаешь свободных разработчиков, которые решают подобные задачи через написание дополнения, вместо вызова FormIt с костылями?
Да и потом, я конечно мог бы всё это сделать на xPDO и ExtJS, но зачем? Какой в этом интерес, в чём развитие? Где веселье-то, в конце концов?

А так — есть новая заметка на сайте, и заготовка для нового типа компонентов MODX. Может еще и дискуссию в комментариях нагенерируем.