Как вы обрабатываете контекст для сложных полей ACF Flexible Content с Timber? - PullRequest
0 голосов
/ 13 декабря 2018

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

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

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


Вот как мои файлы (в основном) выглядят так:

index.php

$context = Timber::get_context();
$context['post'] = ( is_front_page() ) ? new Timber\Post( get_option( 'page_on_front' ) ) : new Timber\Post();

Timber::render( 'page.twig', $context );

page.twig

{% extends 'base.twig' %}

{% block content %}

    {% for bloc in post.meta('blocs') %}

        {% include 'blocs/' ~ bloc.acf_fc_layout ~ '.twig' ignore missing %}

    {% endfor %}

{% endblock %}

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


Извлечение сообщений внутри шаблона ветоки установка переменных кажется грязной и противоречит цели использования ветки в первую очередь.Есть ли лучший способ справиться с этим?

1 Ответ

0 голосов
/ 03 января 2019

Распространенным способом решения этой задачи является использование пользовательского класса, расширяющего Timber\Post.Подробнее об этом вы можете прочитать в Расширенном руководстве по лесоматериалам .

В вашем случае этот класс может выглядеть примерно так:

class PostFlexible extends Timber\Post {
    public function dynamic_context( $args ) {
        return $something;
    }
}

Тогда вместо использованияTimber\Post() в вашем шаблоне PHP вы будете использовать новый класс:

$context = Timber::get_context();
$context['post'] = ( is_front_page() )
    ? new PostFlexible( get_option( 'page_on_front' ) )
    : new PostFlexible();

Timber::render( 'page.twig', $context );

И в своем шаблоне Twig вы можете вызвать метод, который что-то делает:

{{ post.dynamic_context }}

Вопросесть, что именно вы хотите сделать?Вы можете визуализировать или скомпилировать другой шаблон Twig внутри этого метода.Вы можете получить данные, которые вам нужны для этого шаблона, внутри вашего нового метода в PHP, который вы затем передадите в шаблон Twig.Это один из подходов.

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

{% for bloc in post.blocks %}
    {% include 'blocs/' ~ bloc.acf_fc_layout ~ '.twig' ignore missing %}
{% endfor %}

Теперь вы можете определитьpost.blocks вот так:

class PostFlexible extends Timber\Post {
    public function blocks() {
        $blocks = array();

        foreach ( $this->meta( 'bloc' ) as $block ) {
            switch ( $block['acf_fc_layout'] ) {
                case 'slider':
                    // Fetch the data you need for each slider.
                    $block['my_slider_data'] = 'something';
                    break;
            }

            $blocks[ $block ];
        }

        return $blocks;
    }
}

Метод извлекает метаданные, проходит по гибким полям и добавляет необходимые данные в зависимости от имени макета (acf_fc_layout).Таким образом, вы по-прежнему определяете большую часть логики в PHP, а в Twig вы только отображаете данные.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...