Сергей Шлоков

Во первых, ещё ничего не делается. А во вторых, само ядро не трогается.

Задача как раз начинать не с ядра.

Вот тут и вылазит проблема завязки на специфичный бекэнд. Совместимости нет.

Главный продукт — минишоп. Начинать нужно с него.

Пока обсуждаем идею. Роудмап — следующий шаг.

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

Пока в пробке стою modzone.ru/blog/2017/10/06/why-doesnt-work-tag-ignore/

Блин, во первых за рулём. А во вторых, с телефона это делать просто боль. Может вечером…

У себя в блоге я уже разбирал отличия. Кому интересно, уже разобрались. Принципы абсолбтно разные.

Ты взял и пилишь, а в этом сообществе таких героев нет (

Не путай народ сравнивая парсер и шаблонизатор. У последнего тоже есть парсер. Это как сравнивать двигатель и минивен.

Можно и для Ларки, но там другое сообщество. Это можно сделать на следующем витке развития админки. А тут сообщество, которое может поддержать это. Тут целевая аудитория в отличие от Ларки.

отлично вписывается в философию MODX.

С точностью до наоборот.

Если пилить свой RestAPI, то однозначно без xPDO. Можно взять Slim. Он изнвчвльно и планировался в MODX3. А вот с ORM вопрос дискуссионный. ActiveRecord или DataMapper? Первый вопрос. Второй — какой конкретно?

Может и так.

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

ПАТАМУШТА. ))

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

Например, пилотные серии «Игры престолов» провалились.Никто не бросился делать сразу все сезоны. Было принято решение сделать всё заново с другими актерами и сценаристами. И в итоге грандиозный успех.

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

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

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

А вот тут я мимо. Знания самые базовые.

И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.

Абсолютли )

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

url: «assets/main/data/infra-index.json»

Откуда взялся index? Вы парсите плейсхолдер «alias», а передаете «config», в котором нет никакого index.

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

Двух мнений быть не может! ))

А админку какую-то готовую брал или сам пилил?

Если не секрет, почему именно Slim. Не проще было бы взять родной для Eloquent Lumen?