Кастомные поля вместо конструктора: когда сайту нужен ACF

Кастомные поля нужны, когда редактор правит текст и попутно ломает вёрстку. ACF разделяет содержимое и разметку: в админке остаются подписанные поля под цену, срок и описание, а структура страницы закрыта. Конструктор такой границы не проводит.

Классическая история: клиент открывает визуальный редактор, чтобы поправить цену в карточке услуги, задевает мышкой соседнюю колонку, и вёрстка на мобильном разъезжается. Он не виноват, редактор дал ему доступ к структуре страницы там, где нужен был доступ только к тексту. Дальше два часа моей работы на восстановление того, что раньше делалось за пять минут. Расскажу, что реально даёт Advanced Custom Fields на сайте малого бизнеса, какой набор полей нужен под типовой сайт услуг и в каких случаях городить это всё не имеет смысла.

Проблема: текст и вёрстка лежат вместе

В визуальных конструкторах вроде Elementor, Divi или блочных сборках на голом Gutenberg текст живёт внутри той же структуры, что отвечает за расположение, отступы и колонки. Хотите поменять цену тарифа, открываете тот же интерфейс, что отвечает за сетку из трёх карточек. Один случайный клик, перетаскивание блока на пиксель в сторону, удаление колонки вместо текста внутри неё, и страница либо ломается визуально, либо теряет часть контента без предупреждения.

На практике это выливается в звонки в духе «сайт сломался, я просто хотел поправить телефон». У меня в работе таких случаев за последние пару лет было больше десятка, причём чаще всего страдают именно карточки услуг и прайс-листы, потому что там сложнее всего вёрстка и чаще всего правки.

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

Что делают кастомные поля на практике

ACF решает это разделением: вёрстка живёт в PHP-шаблоне темы, контент, специфичный для конкретной записи, живёт в отдельных полях. Редактор в админке видит форму с понятными подписями: «Цена от», «Название услуги», «Что входит», а не визуальный редактор страницы целиком. Тронуть вёрстку физически нельзя, потому что доступа к ней в этом интерфейсе просто нет.

В шаблоне это выглядит так:

<div class="service-card">
  <h3><?php the_title(); ?></h3>
  <p class="price">от <?php the_field('price_from'); ?> руб.</p>
  <ul class="includes">
    <?php while (have_rows('includes')): the_row(); ?>
      <li><?php the_sub_field('item_text'); ?></li>
    <?php endwhile; ?>
  </ul>
</div>

Клиент в админке видит поле «Цена от» и повторяющийся блок «Что входит» с кнопкой «Добавить пункт». Он может отредактировать текст, добавить строку, убрать строку, но структуру карточки, отступы и сетку он не видит и, соответственно, не может сломать.

Типовой набор полей для сайта услуг

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

Группа полей	Тип в ACF	Куда крепится
Цена и условия	Число, текст	Запись типа «Услуга»
Буллиты «что входит»	Повторитель (repeater)	Запись типа «Услуга»
FAQ по услуге	Повторитель: вопрос плюс ответ	Запись типа «Услуга»
Отзывы	Отдельный тип записи с полями «автор», «компания», «текст»	Свой Custom Post Type
Реквизиты и контакты	Текст, телефон, email	Страница опций (Options Page)
Тексты секций лендинга	Текст, WYSIWYG, картинка	Страница опций (Options Page)

Страницы опций, ACF Options Page, отдельного упоминания заслуживают: это глобальные поля, не привязанные к конкретной записи. Телефон, реквизиты, тексты хедера и футера логичнее хранить именно там, а не дублировать в каждой странице. У меня на собственном сайте вся текстовая часть лендинга, тарифы и прайс-лист лежат именно в Options, а не разбросаны по отдельным страницам, редактировать это одно место быстрее, чем искать нужный кусок текста по всей структуре.

Гибкий контент, flexible content field, для малого сайта услуг чаще избыточен: он даёт конструктор из блоков внутри ACF, что снова возвращает часть проблем визуального редактора, просто на новом уровне. Для сайта с устойчивой структурой страниц repeater и обычные поля почти всегда достаточны.

ACF против конструкторов: что меняется технически

Разница не только в удобстве редактирования, она ощутима и в технических метриках.

Конструкторы вроде Elementor генерируют разметку динамически и добавляют собственные CSS и JS файлы почти на каждую страницу, даже если используется десятая часть их возможностей. На типовом сайте услуг это добавляет 100-200 килобайт лишнего веса и заметный вклад в задержку до интерактивности. Подробнее о том, что реально тормозит сайт на конструкторах и что с этим делать, я писал в материале про конструкторы лендингов против классической вёрстки.

При ACF вёрстка статична, лежит в теме, компилируется один раз при разработке. Никакого рантайм-генератора разметки, никакого лишнего CSS, который грузится «на всякий случай». Разница в весе страницы и в числе HTTP-запросов заметна сразу в PageSpeed Insights, обычно на 15-25 пунктов при прочих равных.

Зависимость от плагина тоже разная по характеру. Если ACF PRO (лицензия сейчас порядка 60-70 долларов в год за один сайт) внезапно отключить, контент никуда не денется: данные хранятся в стандартной таблице wp_postmeta, шаблон просто перестанет находить значения полей и покажет пустоту вместо текста, но сайт не рухнет фатальной ошибкой. У визуальных конструкторов разрыв больнее: без плагина страница, собранная в Elementor, может не отрендериться вообще, потому что вся структура хранится в его собственном формате JSON внутри _elementor_data.

Есть способ подстраховаться и от зависимости на уровне полей: ACF умеет экспортировать структуру полей прямо в PHP-код через acf_add_local_field_group(). Тогда поля регистрируются кодом темы, а не хранятся только в базе, и переезд на новый сайт или смена хостинга проходит без риска потерять структуру полей при кривом экспорте базы.

Где ACF лишний

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

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

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

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

Чек-лист, когда ACF действительно оправдан:

• [ ] Контент повторяется по шаблону: карточки услуг, отзывы, кейсы, тарифы
• [ ] Клиент сам вносит правки в текст без участия разработчика
• [ ] На сайте больше пяти-семи страниц однотипной структуры
• [ ] Планируется рост контента: новые услуги, новые отзывы, новые статьи
• [ ] Важна скорость загрузки и минимальный вес разметки

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

Отдельно стоит сказать про бесплатную версию ACF: с 2024 года она принадлежит WP Engine, а часть сообщества параллельно развивает форк Secure Custom Fields. Для простых полей и repeater разницы почти нет, но flexible content, блоки для Gutenberg и Options Page в бесплатной версии либо урезаны, либо отсутствуют. Если клиенту нужна страница опций для реквизитов и текстов лендинга, экономить на лицензии PRO не советую: цена одной лицензии на сайт ниже стоимости часа работы среднего подрядчика, а без неё придётся городить костыли через стандартные хуки WordPress.

Как переносить существующий сайт постепенно

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

Порядок, который у меня стабильно работает на переезде клиентов, в том числе тех, кто раньше сидел на конструкторах Tilda с их зеро-блоками (о специфике таких блоков у меня есть отдельный разбор про кастомные блоки Tilda Zero Block):

1. Сначала переносится самый проблемный тип контента, обычно карточки услуг или прайс-лист, то, что клиент правит чаще всего и чаще всего ломает.
2. Дальше отзывы и кейсы, потому что это растущий контент, который логично сразу вести в структурированном виде.
3. После этого статичные блоки лендинга: хедер, футер, контакты, реквизиты, переносятся в Options Page одним заходом.
4. В последнюю очередь второстепенные страницы, которые редактируют раз в год: политика конфиденциальности, страница вакансий, разовые лендинги под акции.

На каждом шаге старая версия страницы остаётся рабочей, пока новая не проверена вживую. Это особенно важно, если сайт переезжает не только по структуре контента, но и по движку целиком, тогда стоит заранее свериться с материалом о безопасных плагинах для WordPress, чтобы не тащить на новый стек случайные уязвимости вместе с привычными инструментами. А если перенос идёт именно с Tilda на WordPress, у меня есть пошаговый разбор в статье про перенос сайта с Tilda на WordPress, там расписан порядок миграции контента, включая как раз перевод текстовых блоков на кастомные поля.

Итог

ACF не панацея и не обязательный атрибут «серьёзного» сайта. Это инструмент для конкретной задачи: разделить контент и вёрстку там, где клиент реально редактирует сайт сам и где структура контента повторяется. Если оба условия выполняются, разница ощущается уже в первый месяц: меньше звонков про сломанную вёрстку, быстрее обновление контента, легче поддержка со стороны подрядчика.

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

Частые вопросы

Зачем кастомные поля вместо конструктора

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

Какой набор полей нужен сайту услуг

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

Чем ACF отличается от конструктора технически

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

Когда ACF лишний

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