Василий Наумкин
С нами с 08 декабря 2012; Место в рейтинге пользователей: #1
9 часов назад
Можно сделать самому по этой инструкции
Вчера в 12:10
Спасибо, помогло
И пачку скриптов импорта данных со старого, с конвертацией «как надо». Можно всё отполировать до блеска и выкатить в один день в продакшн новый проект. Запустить скрипты, поменять настройки Nginx — и люди видят всё новое, остаётся только авторизоваться.
Ну, это если заказчик не требует внести правки на живую вот прямо на этой неделе. С такими лучше просто не работать.
Вывод — все бегом на https!
Ты имеешь в виду POSIX? Но оно же всё равно не работает без установки Ubuntu?
Но рабочий стол-то на месте? Что про администрирование через SSH?
Вполне возможно.
Но зачем мне покупать что-то «не так плохо», когда у меня уже давно всё есть и бесплатно? Где мега-плюсы Windows для хостинга веб-сайтов?
P.S.
Я не хейтер Windows и честно пару раз в месяц пытаюсь перейти обратно для работы, просто потому, что я там могу насобирать мощнейший комп — но не получается слезть с MacOS.
Как у них там принято — сбоку приделали.
Я попробовал, мне всё равно не зашло. Потому что в PhpStorm этого терминала нет, в своих каких-то локальных скриптах тоже непонятно как использовать.
Это же, по сути, что-то вроде виртуалки, к которой примонтирован HDD Windows.
Ага, поднимать свой домен, чтобы настроить права на локальном компе — умно.
А-ха-ха, её уже можно без рабочего стола использовать на компе с 256 ОЗУ и админить через SSH из коробки?
Паш, ну не смеши мои тапочки, пожалуйста.
Если так, то на AliExpress можно купить за 200 рублей переходник с проприетарного Apple на нормальный M.2 и заменить SSD (только PCI-E). Я так недавно поставил жене 512 диск от Intel, очень хорошо работает.
Windows придумывался не для серверов, в отличие от Unix (Gnu/Linux). Там нет огромного количества нужных вещей, начиная хотя-бы с bash и пакетных менеджеров, и заканчивая правами доступа.
В игрушках и корпоративном сегменте ему равных нет, а вот интернет же совсем не его. И это при том, что на Windows Server требуется покупка лицензии.
Но за заметку «а в MODX еще и так можно», конечно, плюс.
Голосование ни к чему, решать всё равно тебе.
Но и они могут у себя где-то внутри вызывать процессоры MODX для работы. Это даст быстрый старт, а потом эти места можно будет улучшить и переписать.
У меня же конкретное правило — отправлять все запросы к /api сразу на api.php. Выходит, разница только в одной операции чтения диска, зато на каждый запрос.
А так, лично я давно всё отправляю через Nginx:
И там уже любые маршруты с контроллерами.
Используй JWT. Пусть тебе MODX его выдаёт, а потом проверяет и грузит нужного юзера при запуске скриптов.
Но пока никто не взял и не сделал — остаётся только ждать, увы.
github.com/modxcms/revolution/pull/13900#issuecomment-390403195
Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.
Только политоты накинуть на вентилятор, молодец.
Любители фронтенда сами подтянутся, когда им будет куда отправлять запросы для получения данных.
Можно долго обсуждать и принимать решения, но пока у проекта не появится паровозик, который его потащит — проект никуда и не поедет.
На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.
RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.
Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.
А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.
Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.
Если работать с тем, что есть — у нас опять будут разные костыли, потому что нынешние процессоры завязаны на нынешнюю админку и от этого нужно избавиться. Плюс, автоматическая генерация документации будет возможна только по новому 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.