ACF как архитектура контента, а не просто набор полей

Например, блок «Преимущества». Создаётся поле advantages типа Повторитель. Внутри описывается структура строки: title, text, icon.

Каждая добавленная строка — это отдельный набор этих подпольей. Если добавлено 4 строки, значит хранится 4 структурированных элемента.

Подполя не существуют глобально. title внутри advantages и title в другом блоке — это разные данные, потому что ACF хранит их внутри родительского поля.

Если строка сама содержит список, используется вложенный Repeater. Например, тарифы с перечнем услуг.

Структура выглядит так:

• tariffs (Repeater)
  • title
  • price
  • features (Repeater)
    • item

Каждый тариф хранит собственный список features. Вложенный цикл работает внутри текущей строки родителя.

Сначала выполняется цикл по родительскому повторителю tariffs. Затем внутри каждой строки запускается вложенный цикл по features.

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

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

• page_builder — Гибкий контент
• layout: text_section — заголовок, текст (WYSIWYG)
• layout: list_section — заголовок, repeater с пунктами списка
• layout: image_text_section — изображение, заголовок, текст
• layout: faq_section — repeater с вопросами и ответами

Layout задаёт тип блока, а вложенные поля определяют его структуру данных.

Шаблон проверяет наличие блоков и последовательно обрабатывает каждый layout.

<?php if (have_rows('page_builder')): ?>
<?php while (have_rows('page_builder')): the_row(); ?>
<?php if (get_row_layout() === 'text_section'): ?>
<?php get_template_part('template-parts/blocks/text-section'); ?>
<?php endif; ?>
<?php if (get_row_layout() === 'list_section'): ?>
<?php get_template_part('template-parts/blocks/list-section'); ?>
<?php endif; ?>
<?php if (get_row_layout() === 'image_text_section'): ?>
<?php get_template_part('template-parts/blocks/image-text-section'); ?>
<?php endif; ?>
<?php if (get_row_layout() === 'faq_section'): ?>
<?php get_template_part('template-parts/blocks/faq-section'); ?>
<?php endif; ?>
<?php endwhile; ?>
<?php endif; ?>

Каждый layout выносится в отдельный файл. Это упрощает поддержку и исключает перегруженные шаблоны.

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

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

Текст кейса при этом не копируется. Сохраняется только связь: услуга → кейс 1, кейс 2, кейс 3.

• Услуга → связанные кейсы
  На странице услуги выводятся проекты, относящиеся к ней.
• Кейс → связанная услуга
  Внутри кейса указывается, к какой услуге он относится.
• Статья → связанные материалы
  Внизу статьи выводятся публикации по теме.
• Проект → технологии
  Выбираются записи типа «Технологии» и выводятся в проекте.

Без поля Родственные связи обычно:

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

Поле Родственные связи даёт контроль над связями. Можно точно указать, какие записи должны быть показаны, независимо от таксономий и автоматической фильтрации.

В базе данных сохраняются ID выбранных записей. Это не копия текста и не дублирование информации.

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

Ниже пример вывода записей, выбранных в поле related_cases.

<?php
$related_cases = get_field('related_cases');
if ($related_cases):
   foreach ($related_cases as $post):
      setup_postdata($post);?>
   <article class="case-card">
      <h3><?php the_title(); ?></h3>
      <a href="<?php the_permalink(); ?>">Подробнее</a>
   </article>
 <?php
   endforeach;
   wp_reset_postdata();
endif;
?>

Поле возвращает массив выбранных записей. Шаблон проходит по нему и выводит данные каждой записи.

• если нужно вручную управлять связанными материалами
• если категории не отражают реальную структуру проекта
• если логика связей не линейная

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

Например: нужно изменить номер телефона, обновить блок FAQ или заменить связанные кейсы у услуги. Без структуры это означает:

• Редактировать данные в нескольких местах
• Искать, где именно используется нужное значение
• Рисковать оставить устаревшую информацию
• Усложнять шаблоны дополнительными проверками
• Тратить время на повторяющиеся правки

С ACF: данные хранятся централизованно, блоки имеют структуру, связи управляются вручную. Изменение делается один раз и корректно отображается везде.

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

Раздел будет дополняться примерами построения типов записей, логики связей и структуры админки. Планирую разобрать проектирование полей до начала вёрстки, разделение сущностей, настройку Flexible Content, Relationship и Options Page, а также принципы именования и организации групп полей.

Часть материалов уже вынесена в отдельные публикации раздел ACF.

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