thank you

Док менеджер 3.0 не работает на 3.1.1 что делать?

Док менеджер 3.0 не работает на 3.1.1 что делать?

Пока никто не написал на каком моменте он не работает ( У меня работает ) может не так тестирую Тоесть не могу воспроизвести баг что б могли пофиксить

Установил из Extras, открываю

Проблема в: $this->ds = explode((strstr($this->ds, "||") !== false ? "||" : ","), $this->ds); $this->ds - не строка получается, тут и ругается

переопределить можно только зависимость

т.е. те которые через сервиспровайдеры подключены были?

из папки core/src/providers например?

Кстати, а визуальные компоненты при выводе ТВ в 3.0 работают или им уже совсем кранты пришли?

Проблема в: $this->ds = explode((strstr($this->ds, "||") !== false ? "||" : ","), $this->ds); $this->ds - не строка получается, тут и ругается

Это понятно, вопрос что там за обьект приходит такой если строка должна, с учетом что падает модуль а ругается на фаил из ядра ( при этом ни что в ядре на это не ругается ) делаем вывод что проблема в модуле, но что там править и в чем именно проблема не понятно, так как после исправление проблем с языком поставил модуль и он работает без проблем. А как воспроизвести ошибку не понятно, и соответственно без ее воспроизведения не получится корректно починить. Ибо принудительно переводить обьект в строку не вариант там же не просто так строку ждем :)

из папки core/src/providers например?

которые в контейнер засовываются как зависимость

поэтому usermanager или templateprocessor ты можешь переопределить

а то что работает мимо контейнера тебе не мешает

Кстати, а визуальные компоненты при выводе ТВ в 3.0 работают или им уже совсем кранты пришли?

должны работать

т.е. те которые через сервиспровайдеры подключены были?

переопределить модель там, где это прибито гвоздями, у тебя не получится

которые в контейнер засовываются как зависимость

А как понять, что это зависимости, если и там и там просто use TemplateProcessor да use SiteContent. Видимо на эти сервис провайдеры проще всего и ориентироваться

У меня проснулась тяга все расковырять 😁

use SiteContent это просто импорт

ну, тогда тебе нужно начать с загрузки зависимостей

файл AbstractLaravel.php

Вот кстати по этим виз.компонентам, getDocumentObject получает для этого все данные, а вот SiteContent уже теряет всё, не то, что виз.компонент, но даже дефолтные значения

ну это к вопросу, пихать ли все в модель или делать прослойки

я считаю, что модель должна только общаться с базой 🙃

я тут просто мутил очередную наркоманскую обертку для обертки и насчет этих виз.компонентов споткнулся в ней)

getDocumentObject тебе и делает все данные

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

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

ну это я больше к вопросу полной замены modResource на DocumentManager - чтоб ТВ оттуда тоже получать

эти все UserManager и задуманы, чтобы все было в едином стиле

DocumentManager ты можешь переопределить, другой вопрос, что используется ли он где-то вообще ((:

просто опять получается, что через SiteContent тв прилетает в таком виде (а с дефолтными значениями вообще теряется)

🤷‍♂️

а в documentObject вот так

🤷‍♂️

ну это возвращается в коллекции от SiteContent::find($id);

чтобы привести все в порядок, нужно опять все ломать

поэтому после 1.4 боль и страдания ((:

в 6.x все будет красиво, ну в 7.x максимум 😜

да тут бы хоть с текущим положением дел разобраться, потом уже порядки наводить))

DocumentManager ты можешь переопределить, другой вопрос, что используется ли он где-то вообще ((:

Неа 🙂

Он будет использоваться вместо модхапи же ))

или уже не будет?))

Он планируется вместо всех мест где у нас есть работа с документом

тогда и от documentObject можно будет избавиться

Он будет использоваться вместо модхапи же ))

вместо модхапи используется модхапи с другим неймспейсом 🙃

********************* * хвилинку уваги * * минутку внимания * ******************** обратите внимание на этот пост, https://modx.evo.im/blog/develop/2407.html#comment55410 ******************** * * * * * * * * * *

нормальный пост

всем советую посмотреть

что к чему 😊

ну человек типа хочет по папкам фильтровать

ну человек типа хочет по папкам фильтровать

по папкам фильтрует , но список этих папок не строится в eFilter

ааа, я по ссылке и не ходил )

я смотрю там даже modResource и тот в сервис провайдерах подрубается в ядро ))

надо убрать

и все бля по разному - одно через $this->app->bind(), второе через $this->app->singleton() , третье вообще не пойми как

тяжжжко )))

невозможно понять - оно так и надо или оно так просто получилось ))

ну там где объект создается один раз и потом отдается, то singleton

т.е. сейчас по идее может работать такая конструкция evolutionCMS()->doc->edit(5) без modResource

да, может

только откуда оно возьмет modResource

гы Class 'modResource' not found )

но разница должна быть понятна

bind каждый раз будет делать new

это было бы логично, если бы внутри этого байнда не было return \DLTemplate::getInstance($modx);

так DLTemplate сам по себе singleton

ну так и я на это намекаю)

короче ладно, пока в такие дебри лезть ну его нафиг )

буду считать, что то, что через сервис-провайдеры в папке core/src/providers подрубается, то можно и подменить

не обязательно

может провайдер там просто папку для шаблонов устанавливает ((:

или роут задает

похер, других более внятных ориентиров пока нет )

блейдсервиспровайдер просто добавляет директивы

правильнее в конфиге смотреть, что можно подменить ((:

Знать бы в каком конфиге

core/config/app.php