Плагин Advanced Custom Fields используется в WordPress повсеместно, за свою карьеру я встретил лишь несколько сайтов которые обходились без него (весьма специфические). Большой набор типов полей, хороший интерфейс для админов, обширная документация для разработчиков. Казалось бы, чего проще, вывести поля на фронт сайта. Но на практике это делается довольно некрасиво, и занимает гораздо больше времени, чем можно было бы ожидать. Я расскажу как вывести любые ACF поля на фронт без кодинга (и без visual page builders), очень быстро и не превращая код темы в черную дыру спагетти код.

Проблемы кодинга

<p><?php the_field('some_field'); ?></p>

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

Проблема №1. Постоянное посещение ACF группы в админке

Во первых это имя поля. По названию (label) далеко не всегда (а на практике - никогда) можно узнать имя поля, и каждый раз приходится идти в список групп, находить текущую и смотреть имя поля. Ладно, с этим мы разобрались. Теперь что по поводу возвращаемого значения? Хорошо если мы говорим про текстовое поле. А если это изображение, select или post? А тут у нас оказывается полный зоопарк, кроме того что у нас есть множество типов (это же хорошо) у каждого типа есть разные return_format-ы. А это значит что нужно в той же группе проверять настройки конкретного поля. Хорошо если возвращается ID или объект (WP_Post). А если массив? (например опция изображения). Какие там ключи? Конечно, когда выводишь ACF поля ежедневно, их имена всегда в памяти, а если был занят другим?

Проблема №2. Постоянное посещение ACF документации

Таким образом мы подходим ко второй проблеме. Чтобы узнать детали return_format-а, ключи возвращаемого массива или как получить label поля вместе со значением приходится часто наведываться в ACF документацию для соответствующего типа поля. Благо документация хорошая. Но время таки уходит.

Проблема №3. Синхронизация изменений

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

Проблема №4 (Опциональная). Спагетти код

Чего только тут мои глаза не видели. Особенно когда вносятся правки, а не создается страница с нуля. Про кучу спагетти кода в шаблонах, где нельзя понять (даже при большом желании) где начало и где конец я просто не упоминаю. В лучшем случае разработчик прямо в functions.php добавляет регистрацию шорткода и в нем делает вывод нужных полей, и далее устанавливает шорткод в нужное место. (И откровенно говоря, когда вносишь правки в такие "веселые" темы, нет ни времени ни желания что либо менять, просто рядом создаешь еще один и стараешься забыть поскорее все что ты видел) Проблема с таким functions.php что в один день это становится файлом в 3-7 тысяч строк кода, без структуры, без начало и конца. И совсем не понятно, зачем нужен определенный кусок кода, где это используется. Про последствия такого подхода я умолчу, думаю ужасы редактирования, отладки и оптимизации всплывут у всех видевших подобное.

Проблема №5. Стилизация и CSS конфликты

Разметка полей обычно делается на скорую руку и классы в разметке используются из тех, что первые приходят на ум. (К сожалению про BEM слышали далеко не все, а используют еще меньше). В худшем случае стили для этих полей будут добавлены глобально, в лучшем только для целевой страницы. В первом случае будет проблема неиспользуемого CSS кода (привет нулевой Google Page Speed) и конфликтов с другими элементами (названия классов то общие), во втором - проблема переиспользования на других страницах.

Суммируя вышесказанное

Эти проблемы замедляют время разработки и внезапно, чтобы вывести 4 поля у разработчика уходит не 1 минута, а 10, и кроме созданного вывода также создаются множество проблем для того, кто это будет править/поддерживать.

Решение. Вывод полей без кодинга с помощью шорткодов

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

Речь про новый (и бесплатный) ACF Views плагин, который предоставляет шорткоды для вывода полей. И если первое что вам пришло в голову - шорткод для вывода значения по имени поля - вы ошиблись.

ACF Views плагин позволяет вам создавать Views (внутри обычные CPT items) в которых вы:

1. Выбираете ACF поле для вывода
   (одно или несколько, можно с разных групп. Выбор через обычный select)

2. Сохраняете View, копируете шорткод
   (из серии [acf_views view-id="2221" name="Car"])

3. Используете шорткод где угодно
   (Выбранные поля должны быть заполнены на том объекте, где устанавливается шорткод, будь то страница или CPT объект. Или нужно использовать object-id аргумент шорткода, чтобы указать id объекта, откуда брать эти поля)

Во время выполнения шорткод будет обработан плагином, и заменен HTML разметкой, которая будет сгенерированна (автоматически) в зависимости от типа поля и значения поля. (Плагин поддерживает все типы полей, включая изображния и select-ы) Это упрощает задачу в разы, и решает вышеупомянутые проблемы:

Проблема №1. Постоянное посещение ACF группы в админке

Вы выбираете поле (или поля) из списка, не нужно искать имя, не нужно заботится о типе и return-format-е.

Проблема №2. Постоянное посещение ACF документации

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

Проблема №3. Синхронизация изменений

Плагин сохраняет id выбранных полей и получает информацию о полях от ACF динамически. Это значит что мы можем менять поле как угодно, включая имя и тип, не говоря про return-format и абсолютно никаких обновлений от нас не потребуется. Разметка будет всегда актуальной.

Проблема №4 (Опциональная). Спагетти код

Теперь никакого хаоса в functions.php. Отдельный пункт меню в WordPress админке со списком всех View (вы можете задавать им имена и краткие описания), с поиском по ним.

Проблема №5. Стилизация и CSS конфликты

Теперь это мой любый пункт. Разметка генерируется в BEM стиле, так что больше никаких конфликтов. Кроме этого, каждое View имеет свое поле для CSS кода, где вы можете написать стили для этих полей. Этот CSS: a) никогда не создаст конфликтов (BEM стиль + используется id этой View) b) появляется только на страницах где используется текущая View, так что никаких глобальных стилей.

Суммируя вышесказанное

Используя ACF Views плагин (бесплатный) можно вывести любые ACF поля на фронт очень быстро и не создавая проблем для того, кто это будет править/поддерживать. Подробнее узнать о плагине можно на его официальном сайте, где вы сможете найти ссылку на их YouTube канал, который наглядно демонстрирует использование плагина.

У опытных разработчиков наверняка возникнет вопрос, а что по накладным расходам? Это обертка и вероятно это гораздо медленнее чем обычный код. А вот и нет. Авторы плагина уделили особое внимание вопросам производительности (например использовали JSON в вместо мета полей для хранения Views данных) и даже опубликовали тест, который показывает что разницу с кодом будет невозможно заметить на глаз.

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

P.S. Функциональность данного плагина выходит за рамки этой статьи. Если вам будет интересно, то я расскажу что еще можно сделать используя данный плагин. (Например, выбирать и отображать посты, к примеру отобразить 4 последних WooCoomerce продукта без кодинга).