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

И если на сайте присутствуют файлы, названные киррилицей, то скорее всего в процессе копирования их названия исказятся. И у 50% товаров исчезнут изображения, потому как менеджер залил файл «юбка белая.jpg» а после копирования и перезаливки файлов вернулся #!!&&& ***.jpg

Это уже не доработка сайта, это фигня какая-то, если там всё так организовано. Я в подобных случаях пишу новый сайт, где всё делается «как надо».

И пачку скриптов импорта данных со старого, с конвертацией «как надо». Можно всё отполировать до блеска и выкатить в один день в продакшн новый проект. Запустить скрипты, поменять настройки Nginx — и люди видят всё новое, остаётся только авторизоваться.

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

Я тоже ловлю это переодически на сайтах без https.


Вывод — все бегом на https!

Тут нам за MODX LLC никак не угнаться.

Есть :)

А, плагином, я и не догадался.

POSTFIX

Ты имеешь в виду POSIX? Но оно же всё равно не работает без установки Ubuntu?

запускается на 256 мегабайтах

Но рабочий стол-то на месте? Что про администрирование через SSH?

Все реально не так плохо как ты думаешь :)

Вполне возможно.

Но зачем мне покупать что-то «не так плохо», когда у меня уже давно всё есть и бесплатно? Где мега-плюсы Windows для хостинга веб-сайтов?

P.S.
Я не хейтер Windows и честно пару раз в месяц пытаюсь перейти обратно для работы, просто потому, что я там могу насобирать мощнейший комп — но не получается слезть с MacOS.

Не, у меня 2018.

Тогда да, не видать апгрейда, только продавать и новый покупать. С 2016 года там всё распаяно наглухо.

Уже завезли :)

Как у них там принято — сбоку приделали.

Я попробовал, мне всё равно не зашло. Потому что в PhpStorm этого терминала нет, в своих каких-то локальных скриптах тоже непонятно как использовать.

Это же, по сути, что-то вроде виртуалки, к которой примонтирован HDD Windows.

Active Directory тот же решает эту проблему.

Ага, поднимать свой домен, чтобы настроить права на локальном компе — умно.

Да и серверная Windows перестала быть чем-то ужасным.

А-ха-ха, её уже можно без рабочего стола использовать на компе с 256 ОЗУ и админить через SSH из коробки?

Паш, ну не смеши мои тапочки, пожалуйста.

у меня MacBook с 128гб памяти и мне очень больно держать локально Windows

Полагаю, речь идёт про SSD и ноут у тебя MacBook Air около 2012+ года?

Если так, то на AliExpress можно купить за 200 рублей переходник с проприетарного Apple на нормальный M.2 и заменить SSD (только PCI-E). Я так недавно поставил жене 512 диск от Intel, очень хорошо работает.

Будете пробовать делать такой сэтап?)

Windows придумывался не для серверов, в отличие от Unix (Gnu/Linux). Там нет огромного количества нужных вещей, начиная хотя-бы с bash и пакетных менеджеров, и заканчивая правами доступа.

В игрушках и корпоративном сегменте ему равных нет, а вот интернет же совсем не его. И это при том, что на Windows Server требуется покупка лицензии.

Но за заметку «а в MODX еще и так можно», конечно, плюс.

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

Голосование ни к чему, решать всё равно тебе.

Только 3й вариант, только свои процессоры. Чтобы всё завязано было именно на них с самого начала.

Но и они могут у себя где-то внутри вызывать процессоры MODX для работы. Это даст быстрый старт, а потом эти места можно будет улучшить и переписать.

Это более общее правило. try_files проверяет, есть ли $uri на диске, как физический файл, и если нет — то шлёт запрос дальше, на общий роутер.

У меня же конкретное правило — отправлять все запросы к /api сразу на api.php. Выходит, разница только в одной операции чтения диска, зато на каждый запрос.

Другой вариант, который уже больше подходит для концепции REST — отсылаем все запросы как и договаривались на адрес по маске /api/**/*
MODX предсказуемо выдаст событие onPageNotFound — ну а дальше как завещал @Василий Наумкин выстраиваем плагин маршрутизации — и делаем что захотим.

Это если решать все вопросы одним MODX. Да и тогда лучше использовать OnHandleRequest.

А так, лично я давно всё отправляю через Nginx:

location ~ ^/api/ {
    rewrite ^/api/(.*)$ /api.php?q=$1;
}

И там уже любые маршруты с контроллерами.

А зачем тебе куки, для авторизации что-ли?

Используй JWT. Пусть тебе MODX его выдаёт, а потом проверяет и грузит нужного юзера при запуске скриптов.

Не надо ничего ждать, надо брать и делать.

Но пока никто не взял и не сделал — остаётся только ждать, увы.

У нас и веселее высказывания были:

And I'm very surprised by the unnecessary sarcasm. You may have put a lot of work into this, but I've put over a decade of my life into this if you want to play that game. You didn't communicate once on decisions or ask a single question after our initial discussion. Open Source is about collaboration.

And further, a little respect for the people and company that made this software possible in the first place might be in order here.

github.com/modxcms/revolution/pull/13900#issuecomment-390403195

Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.

То чувство, когда этот Джейсон напоминает одного человека в России про которого нельзя говорить(Пу)

Оно и видно, как никто (ты) не говорит.

А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять…

Только политоты накинуть на вентилятор, молодец.

Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками.

Тебе и не надо работать с фронтендом, в первую очередь нужно написать API — а это бэкенд на PHP.

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

Я думаю, эти вопросы решит тот, кто начнёт делать RestApi дополнение.

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

На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.

RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.

Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.

Вопрос а зачем 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.