Aleksandr Huz

Интересное решение. Сомнения отпали окончательно)))

Ты используешь phinx как контейнер, в котором вызываешь xPDO Manager. То есть, миграции выполняются через xPDO и поэтому phinx получается здесь немного избыточным.

Но это, конечно, просто мое мнение. Я сейчас тоже решаю использовать phinx в PageBlocks, ведь в 3 версии у меня в планах создавать динамично кастомные таблицы. Склоняюсь к тому, чтобы отказаться от xPDO и использовать свой конструктор запросов для работы с базой.

А как ты их между собой связал? Это же разные сущности.

Я думал, что после миграции ты запускаешь билдер, который будет обновлять схему, карту и классы, и тогда магия $modx->map[$class] не нужна.

Но, похоже, это не так. Тогда вопрос: а зачем нужен Phinx? При создании новых полей он не участвует, новые таблицы не создаёт. Миграции происходят только при обновлении компонента?

Допустим, в новой версии компонента добавлено новое поле — значит, нужно создавать новую миграцию и обновлять схему ещё раз?

Честно говоря, я не понимаю явного преимущества использования phinx в этом кейсе.

Ранее, мы использовали резолверы для создания и обновления таблиц и это почти всегда приводило к неприятностям, по мере появления новых полей

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

Отличный план.

1. Будет ли поддержка modx3?
2. Продукты будут в отдельной таблице?
3. Миграции phinx — а xpdo объекты будут работать? Миграция будет запускаться вручную или при обновлении компонента? Например, при создании поля, что будет происходить?

Сервисы создают записи, обновляют и удаляют ее, дергая каждый свою XPDO модель.

Если придираться, то:
Сервис — это бизнес-логика и обработка данных
Репозиторий — запросы к базе
Контроллер — запросы, ответы и валидация данных

То есть, контроллер вызывает сервис, сервис вызывает репозиторий, а он в свою очередь обращается к модели.

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

Хочу перенести с MODX2+MiniShop2 на MODX3+PageBlocks. Это вообще реально?

Я не в курсе работает ли минишоп в MODX3, но я параллельно работаю еще над pbShop — аналог минишопа, но с зависимостью от PageBlocks, поэтому будет реально. Сроков пока не могу дать.

3) Но меня очень волнует момент с SeoFiltr ом, возможно ли повторить его функционал? Хотя бы в минимальном исполнении, и так, чтобы при переносе остались те же url?

я не знаком, с этим компонентом, позже попробую установить и протестировать

Согласен. Но сейчас документация уже почти полная, примеры постепенно будут добавлятся.

В режиме менеджера там и так все интуитивно понятно:

• В меню компонента создаёшь блок с нужными полями.
• В ресурсе добавляешь этот блок и заполняешь контентом.
• В шаблоне выводишь блоки через сниппет [[!pbBlocks]].

И все. Получается аналог мигса, только с визуальным конструктором и более мощным функционалом.

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

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

Например, создал модификатор меню

'menu' => function (int $rootId = 0, $level = 3) {
        return query('modResource')
        ->where([
            'published' => 1,
            'hidemenu' => 0,
        ])
        ->select('id,class_key,template,pagetitle,menutitle,introtext,alias,uri,link_attributes,parent')
        // получаем дополнительные поля, если меню нужно построить от родителя с id 12
        ->when($rootId === 12, function ($query) {
            $query->select('cargo_tooltip,transport_tooltip');
        })
        // кешируем результат навечно, пока не сбросим кеш
        ->cache(0)
        ->menu($rootId, $level);
},

и в файловом чанке

{foreach menu() as $item}
    <li class="nav-item{($item.id == $modx->resource->id) ? ' active' : ''}">
        <a class="nav-link" href="{$item.uri}">{$item.menutitle ?: $item.pagetitle}</a>
     </li>
{/foreach}

или вывести меню с другой категории
{foreach menu(12) as $item}
    <li class="nav-item{($item.id == $modx->resource->id) ? ' active' : ''}">
        <a class="nav-link" href="{$item.uri}">{$item.menutitle ?: $item.pagetitle}</a>
     </li>
{/foreach}

CMS писать точно не планирую)) Мне нравится админка MODX3, но хочется добавить больше гибкости и удобства, как в ларавел. И еще, чтобы админку можно было легко кастомизировать под проект.

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

Реально компонент — «космолет», но использовать на боевых сайтах страшно

А почему страшно? я с 2022 года использую его с modx3 и все нормально. Сейчас делаю большой проект полностью без чанков, сниппетов и тивишек и это реально удобно и быстро. Так что страшного здесь ничего нет.

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

Все правильно, так и должно быть

«Array» отображается в колонке «значения» таблицы, но в самом поле должны быть превью.
А на фронте, да, это массив
pageblocks.boshnik.com/docs/fields/image

Fenom встроен в PageBlocks, но он никак не влияет на стандартный парсер. Феном обрабатывает только чанки, которые вызваны через сниппеты компонента.

Так есть же такая возможность или речь о бесплатной версии?

экранируйте поле rank или установите новую версию.
Версия 1 не поддерживается с 29.11.2024

вроде писали что PageBlocks работает с MySQL 8

Это для новых версий, а у вас, наверное, 1 версия установлена, или я ошибаюсь?

Занят был версией 2.8.0
pageblocks.boshnik.com/ru/changelog

так что теперь переноситься на 1-2 месяца

Пришлось проверить)))

POST-запрос на assets/components/fetchit/action.php с выключенным MODX_API_MODE вызывает как минимум событие OnHandleRequest.

Все супер, но не нравится только правка исходников.

Он напрямую исполняет action.php, минуя index.php и весь основной жизненный цикл MODX.
Событие OnHandleRequest никогда не вызывается.

Все-таки не минуя index.php, но из-за того, что включен режим API (MODX_API_MODE), плагины действительно не сработают.

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

Но если компонент не обновлять, то и так сойдет))