Алексей Соин

как бесплатную альтернативу можно ещё использовать DBearer, а так да, DataGrip и PHPStorm отлично справляются со всеми задачами.

почему же не поймут о чем речь?) я както пробовал с nestjs работать, крутая штука, но мне больше понравился adonisjs, в нем подход максимально похож на мир laravel. @srs тоже понял о чем тема, а тех кто не отписался в комменты и прочитал статью ещё наберётся, так что я думаю многим для разнообразия будет интересно почитать или хотябы понимать о дальнейшем развитии себя как разработчика после modx. Статей интересных на сайте выходит мало, так что эта точно не лишняя))

Немного не по теме, но увидев такую деструктуризацию мне стало страшно)))

мне както давно тоже нужно было игнорировать подключаемые метрики и выводить vue компонент, тег {ignore} не очень с этим справляется, я делал так, создал плагин ignore на событие pdoToolsOnFenomInit, со следующим содержанием:

<?php
/** @var modX $modx */
switch ($modx->event->name) {
    case 'pdoToolsOnFenomInit':
        $fenom->addModifier('ignore', function ($input) {
            $output = '{ignore}' . $input . '{/ignore}';
            return $output;
        });
        break;
}

а уже метрики и vue компоненты я добавлял с помощью чанков и настройками в clientConfig, добавляя вконце модификатор ignore, выглядило это чтото типо

{'metrics' | config | ignore}

{'vue-chunk' | chunk | ignore}

таким образом не нужно переопределять вьюшные теги и както стараться подгонять код чтобы феном не ломался))

ну так я про это и говорю))

И достаточно много как статей, так и примеров на modx.pro и github чтобы разобраться, если оно нужно. Я лично не защитник extjs, я только говорю, что если и делать компонент, то в ui стиле системы под которую он делается

Пишем в гугле extjs modx и первая ссылка docs.modx.com/3.x/ru/extending-modx/custom-manager-pages/modext/modext-tutorials

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

Приведу такой пример, я както решил сделать компонент для переключения в админке modx темы с светлой на темную, но изза того что некоторые компоненты написаны без классов и элементов UI modx получалось так, что вся панелька с тёмной темой, а некоторые элементы интерфейса как прожектора светят белым, а подстраиваться под кучу сторонних компонентов эт такое…

я думаю, имеется ввиду не список допов работающих с modx3, а допов которые корректно работают с новой версией minishop2

@Leonid Krylov мне кажется не лишним будет в modstore добавить шилд у дополнений, которые уже адаптированы для 3 версии modx

Кстати, так как данный баг пока не собираются исправлять, советую скрыть доступ к корневому файлу composer.json через .htaccess, либо nginx(в зависимости от настроек сервера).

Пока не оптимизируют MIGX, pdoTools не выйдет из беты и не появится minishop, я думаю, обновляться или делать сайты под modx 3 ещё рано. Мне кажется 90% сайтов работают на этих дополнениях, так что для большинства обновление до тройки пока не будет «простым».

И я также не понимаю, про какую такую обратную совместимость они всё время говорят, если по факту её нет?

Ссылки вида [[~123]] не конвертируются.

а что же с ними происходит?)) [[~123]] -> {'123' | url}

Параметры [[+modx_setting]] должны преобразовываться в {'modx_setting' | option}.

[[+modx_setting]] — плейсхолдер, с чего вдруг он должен стать опцией? если имелось ввиду [[++modx_setting]] то он преобразуется в {'modx_setting' | config}

Плейсхолдеры надо не {'pholder' | placeholder}, а просто {$pholder}, но если в его имени есть точки, то {$_pls['pholder']}.

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

Также было бы круто, чтобы можно было вставлять целый HTML-шаблон с тегами MODX

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

Если есть: конструкции=`условий`, то просто писать о их наличии (и номерах строк), но не блокировать все конвертирование.

Если имеется ввиду модификаторы, то повторяюсь, тотже :default уже не имеет смысла использовать в fenom заместо него надо использовать {if ...}.

Параметры сниппетов и чанков Fenom было бы лучше конвертировать с одинарными кавычками ' вместо двойных ".

Какой практический смысл в этом? Я пользуюсь всегда двойными кавычками.

точно ко мне вопрос?)))

У меня вот сейчасс не получается на феноме вывести [[!+ss_meta]] из дополнения Seo Suite

{'ss_meta' | placeholder}

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

Чем так цвет фона душу раздерает?) Мне в дизайне всё нравится))

Поправил, единственное пока не придумал, как получше обрабатывать комменты и на подумать остается обработка фильтров/модификаторов и свойств, но скорее всего в дальнейшем буду просто выводить предупреждение, что фильтр :default нужно вручную править для fenom синтаксиса и т.д.

Выводится сниппет если не понять что за тег, а так пока переводит чанки, сниппеты, системные значения. Доработать даный конвертер не трудно, но не хотелось бы тратить время на сервис, который никому не нужен. Хотелось бы услышать, нужен ли он кому-то (например лайк/дизлайк вот этого моего коммента, или в гитхабе плюсами). Если нужно, выделю время на доработки.

На скорую руку накидал свой вариант m2f.zencod.ru/

Если у кого то есть предложения по более лучшему варианту, велком с пуллреквестом))) github.com/alexsoin/modx2fenom