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

Вопрос а зачем MODX если делать так

Затем, чтобы не распугать всё сообщество и не переименовывать modx.pro

А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.

Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.

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

Не соглашусь, API здесь первично.

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

А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.

В моём представлении — вот так.

Обратная совместимость с костылями — именно то, что завело нас в текущую ситуацию.

На мой взгляд — это единственный реальный вариант.

Нужно 2 дополнения для MODX:
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.

Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.

Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.

— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.

С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.

При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.

Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!

Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.

Всё сам делаю: и контроллеры, и процессоры и админка на Nuxt.js в дизайне самого сайта.

По сути, админка — это просто специальный раздел сайта, который требует особых прав. Юзер логинится на сайт и может работать в этом разделе, всё выглядит одинаково.

Проекты серьёзные, так что всё это делается под заказ.

Slim я начал раньше использовать, чем Eloquent.

Честно говоря, сейчас всё идеально работает, даже не знаю, что мне эдакого сможет родной Lumen предложить.

Ну и звёздочек у Slim на Github больше — а все знают, что это самое важное!

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

Самому еще эти детские капризы не надоели? Или делись знаниями, и имей в виду, что не всем они могут даваться легко, или молчи уже тогда в тряпочку. А то как девица ветреная себя ведёшь, смотреть противно.

так и не решился попробовать в деле

Если соберёшься — пиши. Всегда помогу, подскажу, у меня там все тропинки уже изведаны.

Поэтому в отдельной локализации смысла нет.

Хотелось дать им возможность самим писать заметки, но оказалось, что это никому не нужно.

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

А как насчет связки phpMorphy + Sphinx?

Не совсем понятно, как и зачем их связывать.

Sphinx — это отдельно крутящий демон, которому ты отдаёшь поисковый запрос и он делает всю работу. Включая, например, подсветку найденных слов.

Выглядит это примерно как SQL запрос, только не в БД, а в Sphinx

$query = (new SphinxQL($this->conn))
    ->select('id', 'comment', 'weight() AS weight')
    ->from('topics')
    ->limit($start, $limit)
    ->option('field_weights', [
        'pagetitle' => 100,
        'content' => 50,
        'comment' => 10,
    ])
    ->groupBy('id')
    ->option('max_matches', 1000000)
    ->match(['pagetitle', 'content', 'comment'], $string);

$result = $query->execute();

В mSearch2 же это всё делается вручную, используя формы слов от phpMorphy. Наверное можно просклонять слова в phpMorphy, потом поискать их в Sphinx, потом отдельно отранжировать и соединить ответы — но вряд ли это что-то улучшит, а вот усложнит — наверняка.

Так же интересно узнать про опыт использования phpMorphy2

Я такого не нашёл. Есть только pymorphy2, но он на Python и его ни разу не использовал.

Slim3 + Eloquent, но можно и MODX приспособить — это тоже в планах, попробовать как-то всё совместить.

Я пока только у себя использую, потому что учусь.

Как буду готов — начну писать заметки про это дело, когда сам освою как следует.

А почему для генерации html нужна нода?

Потому что это полностью готовый отрендеренный фронтенд, который не нужно больше обрабатывать на сервере вообще.

Вот подробности — ru.nuxtjs.org/guide (возможно, понадобится включить VPN)

Не знаю как Коля, а у меня вообще статический HTML генерируется Node, и потом отдаётся Nginx.

Дальше подгружается JS и начинает работать всякий динамический функционал. То есть, весь фронтенд рендерится на сервере и сохраняется в HTML + JS, а дальше только запросы в API за актуальными данными.

Соответственно, фронтенд можно хоть на Github.io хостить и генерировать при новом PR в Git, а бэкенд на отдельном сервере — и никаких проблем.

То есть, если я пишу бэкенд на JS и запускаю его на Node — то это не Node?

Этот бэкенд точно так же, как и PHP, примет запрос, залезет в БД и выдаст JSON ответ.

На фронтенде вообще никто не поймёт, на чём именно бэкенд написан, потому что снаружи будет видно только Nginx, а всё остальное проксируется или в Node, или в php-fpm.

Так в чём разница-то?

А есть разница?

Раян Дал. Создатель NodeJs.

Не работает с NodeJS где-то с 2012-2013 года. Дал это интервью в 2017 году.

Прям надо бросать всё и бежать на Go.

Но если вы пишете распределённый DNS сервер, я бы не выбирал Node.

А, так он вот про такой сервер говорил?! Не про бэкенд для веб-сайта?

Потому что php никогда не станет помощником на фронтенде, а вот js научился работать на сервере.

JS еще научился собираться в нативные мобильные приложения для Android и iOS, например через React Native.

Так что, по универсальности, это однозначно самый мощный сегодня инструмент.

Если ты про yTranslit, то я ни одного нового коммита не вижу в репозитории.

Смысл еще что-то отдавать, если как не было обновлений, так и нет?

С pdoTools я пока и сам справляюсь.

Нет, я немного по-другому пошёл. Изучаю frontent, в частности NuxtJS, а на бэкенде может быть кто угодно, включая MODX.

Как буду готов — покажу, расскажу, что получается.

Я только за, без шуток.

Желающих только нет.