Wordpress & Composer: правильная установка Carbon Fields?

Question

[thehighhomie]

Почти разобрался с новой тенденцией разработки на WP. Настроил свою сборку с помощью Composer и все меня радует, кроме плагина Carbon Fields. Почитав документации на офф. сайте по этому плагину я был в восторге от него!
Единственная проблема в установке, а именно:
У меня структура проекта схожая с Bedrock, и при установке Carbon FIelds 2.2.0 в стандартном режиме в папку vendor, которая лежит в корне, появляется проблема с assets (css, js), так как они лежат на уровень выше сайта.

В доках есть страница Support for Bedrock & similar frameworks, но я немного растерялся, если я укажу путь установки в папку web (как в Bedrock) то в паке веб появится еще одна папка vendor с Carbon Fields, но это работать не будет все равно, посмотреть почему можно здесь.
То есть assets нормально работают если плагин работает если он лежит в папке контента, либо в папке с плагинами, либо в папке с вордпрессом. Но все таки можно сделать так чтобы работало из любой другой дирректории, только не выше уровня сайта (в случае с Bedrock это папка web) определив константу:

define('Carbon_Fields\URL', home_url() . '/vendor/htmlburger/carbon-fields');

этот костыль тоже меня не устраивает.

Будет работать если указать путь установки в папку с контентом, в случае с Bedrock это папка app, где лежат папки themes, plugins.... + к этим папкам добавится папка vendor, в которой и будет лежать плагин Carbon Fields. Теперь все работает, все круто, но меня смущает тот факт, что это похоже на костыль и чувство такое, что не очень красиво что-ли, когда есть общая папка вендоров в корне и еще папка с вендором (в которой только один плагин), среди папок themes, plugins...

Посоветуйте как быть?

Answer 1

[Игорь Воротнёв]

Настроил свою сборку с помощью Composer

Раз такое дело, посмотри еще мою :)

Что касается путей - увы, так у них реализовано. Вариант с константой ИМХО самый оптимальный. Либа находится там где и должна - в папке /vendor/, а URL к ресурсам переопределяем константой.

Comments

[thehighhomie]

о, круто) спасибо)

Либа находится там где и должна - в папке /vendor/

вы имели ввиду vendor в папке с контентом (themes, plugins и т.д.) или в корне где основной vendor?

[Игорь Воротнёв]

thehighhomie, в корне. Лично я приверженец того, что должен быть один composer, глобальный на уровне проекта, в котором и сам WordPress, и плагины, и тема, и любые дополнительные пакеты - все это зависимости. Соответственно, и vendor один, в корне проекта.

[thehighhomie]

Игорь Воротнёв, прошу прощения за отсутствие и что оставил вопрос без решения, заболел. спасибо за помощь. я кстати пытаюсь изменить структуру темы, содержимое темы к примеру в папке content а webpack, к примеру со всякими настройками в корне темы. пытался разобраться как в тут это сделано (тема sage), но после того как по шарил в вендорах, в нужных классах, я так и не понял что делает этот код:

Container::getInstance()
    ->bindIf('config', function () {
        return new Config([
            'assets' => require dirname(__DIR__).'/config/assets.php',
            'theme' => require dirname(__DIR__).'/config/theme.php',
            'view' => require dirname(__DIR__).'/config/view.php',
        ]);
    }, true);

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

array_map(
    'add_filter',
    ['theme_file_path', 'theme_file_uri', 'parent_theme_file_path', 'parent_theme_file_uri'],
    array_fill(0, 4, 'dirname')
);
Container::getInstance()
    ->bindIf('config', function () {
        return new Config([
            'assets' => require dirname(__DIR__).'/config/assets.php',
            'theme' => require dirname(__DIR__).'/config/theme.php',
            'view' => require dirname(__DIR__).'/config/view.php',
        ]);
    }, true);

с array_map все понятно а с Container::getInstance() нет( вы не могли бы объяснить, если знаете что тут происходит?

[Игорь Воротнёв]

thehighhomie,
Container (Roots\Sage\Container) - это их Dependency Injection / Service Container, смотрите пакет root/sage-lib, который ставится компоузером. Он, в свою очередь, наследует Illuminate\Container. Вот тут есть интересный тюториал по нему. Метод bindIf() добавляет данные в контейнер (если они не были добавлены ранее), в данном случае - instance конфига с конкретными значениями. Это позволяет далее в любом месте кода получать доступ к этим данным через контейнер, это собственно вся суть DIC.

[thehighhomie]

Игорь Воротнёв, я смотрел код этих классов, но что в итоге получается я не понял, я хочу без этих зависимостей по вордпрссовски описать тоже самое) я поставил тимбер вместо блейда и вполне доволен, так что такого стиля описания страниц как в Sage мне не нужно, все и так хорошо для меня, по этому дополнительные зависимости не нужны мне)

да, кстати, я заметил авторы сборок часто добавляют в папку контента (где plugins, themes и т.д.) кастомные папки, например my-plugins, я так понимаю, что я могу в mu-plugins добавить свои плагины, по 1 файлу на плагин, а так как в папке mu-plugins нужно как раз держать именно 1 файл php для одного плагина, то я могу в my-plugins писать движок каждого плагина, а в mu-plugins, в файле плагина подтягивать нужные функции и классы из my-plugins? это для того, чтобы я мог к примеру создать много тем и без проблем между ними переключаться, и не тянуть за собой к примеру кастомные поля и страницы настроек, я правильно мыслю?)

[Игорь Воротнёв]

по этому дополнительные зависимости не нужны мне)

Ну тогда надо этот Sage перепиливать, убрать установку конфига в контейнер, убрать те вызовы, которые потом идут (используя данные из конфига).

кастомные папки, например my-plugins, я так понимаю, что я могу в mu-plugins добавить свои плагины

mu-plugins это не кастомная папка, это стандартная папка WP для "Must Use" плагинов. Это плагины, которые загружаются перед обычными и их нельзя в админке выключить (то есть, они включены всегда). Удобная штука для многих задач.

по 1 файлу на плагин, а так как в папке mu-plugins нужно как раз держать именно 1 файл php для одного плагина

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

в my-plugins

А вот про такую папку первый раз слышу, никогда не видел и не совсем понимаю зачем она вообще. Имхо, только усложняет. Если это либа - кладите в vendor, если mu-plugin - тогда в mu-plugins, если обычный плагин - в plugins. Не вижу смысла усложнять жизнь.

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

Не совсем понимаю в чем проблема / боль и в чем собственно вопрос. Переключение темы должно быть безболезненным по определению, это всего лишь фронтенд. Функциональность должна быть в плагинах.

[thehighhomie]

Игорь Воротнёв, спасибо, все понятно, кроме этого:

Ну тогда надо этот Sage перепиливать, убрать установку конфига в контейнер, убрать те вызовы, которые потом идут (используя данные из конфига).

что этот код делает вообще? какие экшены использует или фильтры? думаю есть какой-то рецепт но не могу найти... как по вордпрессовски переписать это, чтобы работало?