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

Порт 3333 от MariaDB открыт наружу, так что можно подключаться любым удобным ПО.

Я использую PhpStorm:

Хорошо, что я уже не модыксер =)

modx.pro/hosting/23448

У меня Nuxt.js — это для Vue

А Next.js — это для React

Упс…

Что упс-то? Предыдущую версию делал тот же человек, url не изменились.

Вот посещаемость за весь 2018 год, я не вижу тут падения после обновления.


Вот трафик из поисковиков за 2018


А вот потом, когда народ устал ждать MODX 3 — и пошёл спад. В следующие 3 года это чётко видно

С другой стороны — отчётливо виден пик 2017 — 2018 года и дальнейший спад

Чтоб найти что-то в интернете нужно знать нужные слова :-). Проблема фильтрации в интернет-магазинах называется фасетный поиск. И yandex.ru/search/?text=Фасетный поиск дает уже кучу информации как его организовывать.

Я честно не знал, что это такое, когда писал. И не гуглил =)

В основном применяются специальные базы данных Sphinx/ElasticSearch/etc.

Которые так просто на любом PHP хостинге не запустишь. А это необходимо, если ты поставляешь дополнение для работы в MODX.

Тонкости фасетного поиска на массивах, таких же как применил @Василий Наумкин в mFilter2, описаны в статье История разработки фасетного поиска средствами PHP. И текущему автору mSearch2 стоит ее прочитать :-).

Текущему автору — возможно. А я писал mFilter2 в 2013 году и прочитать эту заметку не мог. Теперь могу, так что сохранил ссылку в закладках на будущее, спасибо!

P.S. Кстати, я продолжаю писать фасетный поиск, но уже на Vue и не универсально, а под проект. Самый свежий можно потыкать вот здесь — lehre.lu/map

Тег {ignore} должен тупо пропускать вообще всё, что внутри.

Я как-то пару раз интегрировал Vue на страницу MODX с Fenom — всё игнорировалось, как должно.

Самое простое — завернуть код с Vue внутрь тега {ignore}...{/ignore}, он специально для этого и придуман.

А я советую облегчённый Vue Petite — github.com/vuejs/petite-vue

Наверное, логика была в том, что на один адрес может быть оформлено несколько заказов.

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

С моей стороны, наоборот, удалять адрес при удалении заказа — это спорное решение.

Конечно.

Либо через 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 и пользуйся, для того расширения и нужны.