Get fields error

Based on @Jay Seth’s answer, I made a version of FormErrors class especially for Ajax Forms:

// src/AppBundle/Form/FormErrors.php
namespace AppBundleForm;

class FormErrors
{

    /**
     * @param SymfonyComponentFormForm $form
     *
     * @return array $errors
     */
    public function getArray(SymfonyComponentFormForm $form)
    {
        return $this->getErrors($form, $form->getName());
    }

    /**
     * @param SymfonyComponentFormForm $baseForm
     * @param SymfonyComponentFormForm $baseFormName
     *
     * @return array $errors
     */
    private function getErrors($baseForm, $baseFormName) {
        $errors = array();
        if ($baseForm instanceof SymfonyComponentFormForm) {
            foreach($baseForm->getErrors() as $error) {
                $errors[] = array(
                    "mess"      => $error->getMessage(),
                    "key"       => $baseFormName
                );
            }

            foreach ($baseForm->all() as $key => $child) {
                if(($child instanceof SymfonyComponentFormForm)) {
                    $cErrors = $this->getErrors($child, $baseFormName . "_" . $child->getName());
                    $errors = array_merge($errors, $cErrors);
                }
            }
        }
        return $errors;
    }
}

Usage (e.g. in your action):

$errors = $this->get('form_errors')->getArray($form);

Symfony version: 2.8.4

Example JSON response:

{
    "success": false,
    "errors": [{
        "mess": "error_message",
        "key": "RegistrationForm_user_firstname"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_user_lastname"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_user_email"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_user_zipCode"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_user_password_password"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_terms"
    }, {
        "mess": "error_message2",
        "key": "RegistrationForm_terms"
    }, {
        "mess": "error_message",
        "key": "RegistrationForm_marketing"
    }, {
        "mess": "error_message2",
        "key": "RegistrationForm_marketing"
    }]
}

The error object contains the «key» field, which is the id of the input DOM element, so you can easily populate error messages.

If you have child forms inside the parent, don’t forget to add the cascade_validation option inside the parent form’s setDefaults.

Первая часть
Вторая часть

7 Проверка и сообщения об ошибках

Большинство наших форм должны показывать сообщения проверки, чтобы информировать пользователя об ошибках, которые он сделал.

Thymeleaf предлагает несколько инструментов для этого: несколько функций в объекте #fields, атрибуты th:errors и th:errorclass.

7.1 Field errors

Давайте посмотрим, как мы можем установить конкретный класс CSS для поля, если оно содержит ошибку:

<input type="text" th:field="*{datePlanted}" 
                   th:class="${#fields.hasErrors('datePlanted')}? fieldError" />

Как видите, функция #fields.hasErrors(…) получает выражение поля в качестве параметра (datePlanted) и возвращает логическое значение, указывающее, существуют ли какие-либо ошибки проверки для этого поля.

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

<ul>
  <li th:each="err : ${#fields.errors('datePlanted')}" th:text="${err}" />
</ul>

Вместо итерации мы могли бы также использовать th:errors, специализированный атрибут, который создает список со всеми ошибками для указанного селектора, разделенными <br />:

<input type="text" th:field="*{datePlanted}" />
<p th:if="${#fields.hasErrors('datePlanted')}" th:errors="*{datePlanted}">Incorrect date</p>

Упрощение стилей CSS на основе ошибок: th:errorclass

Пример, который мы видели выше, установка CSS-класса для input формы, если в этом поле есть ошибки, настолько распространена, что Thymeleaf предлагает специальный атрибут для точного выполнения: th:errorclass.

Примененный к тегу поля формы (input, select, textarea…), он будет считывать имя поля, которое нужно проверить, из любых существующих атрибутов name или th:field в том же теге, а затем добавлять указанный класс CSS к тегу, если такое поле имеет какие-либо связанные ошибки:

<input type="text" th:field="*{datePlanted}" class="small" th:errorclass="fieldError" />

Если в datePlanted есть ошибки, это будет выглядеть так:

<input type="text" id="datePlanted" name="datePlanted" value="2013-01-01" class="small fieldError" />

7.2 Все ошибки

А что если мы хотим показать все ошибки в форме? Нам просто нужно запросить методы #fields.hasErrors(…) и #fields.errors(…) с константами ‘*‘ или ‘all‘ (которые эквивалентны):

<ul th:if="${#fields.hasErrors('*')}">
  <li th:each="err : ${#fields.errors('*')}" th:text="${err}">Input is incorrect</li>
</ul>

Как и в приведенных выше примерах, мы могли бы получить все ошибки и итерировать по ним …

<ul>
  <li th:each="err : ${#fields.errors('*')}" th:text="${err}" />
</ul>

… а также создать разделенный <br /> список:

<p th:if="${#fields.hasErrors('all')}" th:errors="*{all}">Incorrect date</p>

Наконец, обратите внимание, что #fields.hasErrors(‘*’) эквивалентно #fields.hasAnyErrors(), и #fields.errors(‘*’) эквивалентно #fields.allErrors(). Используйте тот синтаксис, который вы предпочитаете:

<div th:if="${#fields.hasAnyErrors()}">
  <p th:each="err : ${#fields.allErrors()}" th:text="${err}">...</p>
</div>

7.3 Глобальные ошибки

В форме Spring существует третий тип ошибок: глобальные ошибки. Это ошибки, которые не связаны с какими-либо конкретными полями в форме, но все еще существуют.
Thymeleaf предлагает константу global для доступа к этим ошибкам:

<ul th:if="${#fields.hasErrors('global')}">
  <li th:each="err : ${#fields.errors('global')}" th:text="${err}">Input is incorrect</li>
</ul>

<p th:if="${#fields.hasErrors('global')}" th:errors="*{global}">Incorrect date</p>

… a также эквивалентные вспомогательные методы #fields.hasGlobalErrors() и #fields.globalErrors():

7.4 Отображение ошибок вне форм

Ошибки проверки формы также могут отображаться вне форм с помощью переменных (${…}) вместо выражений выбора (*{…}) и префикса имени компонента, поддерживающего форму:

<div th:errors="${myForm}">...</div>
<div th:errors="${myForm.date}">...</div>
<div th:errors="${myForm.*}">...</div>

<div th:if="${#fields.hasErrors('${myForm}')}">...</div>
<div th:if="${#fields.hasErrors('${myForm.date}')}">...</div>
<div th:if="${#fields.hasErrors('${myForm.*}')}">...</div>

<form th:object="${myForm}">
    ...
</form>

7.5 Богатые объекты ошибок

Thymeleaf предлагает возможность получения информации об ошибках формы в виде bean-компонентов (вместо простых строк) с атрибутами fieldName (String), message (String) и global (boolean).

Эти ошибки могут быть получены с помощью служебного метода #fields.detailedErrors():

<ul>
    <li th:each="e : ${#fields.detailedErrors()}" th:class="${e.global}? globalerr : fielderr">
        <span th:text="${e.global}? '*' : ${e.fieldName}">The field name</span> |
        <span th:text="${e.message}">The error message</span>
    </li>
</ul>

8 Это все еще прототип!

Наше приложение готово. Но давайте еще раз посмотрим на .html страницу, которую мы создали …

Одним из самых приятных последствий работы с Thymeleaf является то, что после всех этих функций, которые мы добавили в наш HTML, мы все равно можем использовать этот HTML в качестве прототипа (мы говорим, что это Natural Template). Давайте откроем seedstartermng.html прямо в нашем браузере, не запуская наше приложение:

Вот оно! Это не работающее приложение, это не реальные данные … но это совершенно правильный прототип, составленный из прекрасно отображаемого HTML-кода.

9 Служба конверсии (The Conversion Service)

9.1 Конфигурирование

Как объяснялось ранее, Thymeleaf может использовать Службу преобразования, зарегистрированную в контексте приложения. Наш класс конфигурации приложения, расширяя собственный помощник Spring WebMvcConfigurerAdapter, автоматически зарегистрирует такой сервис преобразования, который мы можем настроить, добавив необходимые средства форматирования. Давайте еще раз посмотрим, как это выглядит:

@Override
public void addFormatters(final FormatterRegistry registry) {
    super.addFormatters(registry);
    registry.addFormatter(varietyFormatter());
    registry.addFormatter(dateFormatter());
}

@Bean
public VarietyFormatter varietyFormatter() {
    return new VarietyFormatter();
}

@Bean
public DateFormatter dateFormatter() {
    return new DateFormatter();
}

9.2 Синтаксис двойной скобки

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

• Для переменных выражений: ${{…}}
• Для выражения выбора: *{{…}}

Так, например, учитывая преобразователь Integer-to-String, который добавляет запятые в качестве разделителя тысяч, это:

<p th:text="${val}">...</p>
<p th:text="${{val}}">...</p>

… должно привести к:

<p>1234567890</p>
<p>1,234,567,890</p>

9.3 Использование в формах

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

<input type="text" th:field="*{datePlanted}" />

… фактически эквивалентно:

<input type="text" th:field="*{{datePlanted}}" />

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

9.4 #conversions объект преобразования

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

<p th:text="${'Val: ' + #conversions.convert(val,'String')}">...</p>

Синтаксис для этого служебного объекта:

• #conversions.convert(Object, Class): преобразует объект в указанный класс
• #conversions.convert(Object, String): то же, что и выше, но с указанием целевого класса в виде String (обратите внимание, что пакет java.lang. может быть опущен)

10 Отрисовка фрагментов шаблона Template Fragments (AJAX etc)

Thymeleaf предлагает возможность визуализации только части шаблона в результате его выполнения: фрагмента.

Это может быть полезным инструментом компонентизации. Например, его можно использовать на контроллерах, которые выполняются при вызовах AJAX, которые могут возвращать фрагменты разметки страницы, которая уже загружена в браузер (для обновления выбора, включения/выключения кнопок…).

Фрагментарный рендеринг может быть достигнут с использованием спецификаций фрагментов Thymeleaf: объектов, реализующих интерфейс org.thymeleaf.fragment.IFragmentSpec.

Наиболее распространенной из этих реализаций является org.thymeleaf.standard.fragment.StandardDOMSelectorFragmentSpec, которая позволяет указывать фрагмент с помощью селектора DOM в точности так же, как те, что используются в th:include или th:replace.

10.1 Определение фрагментов в бине представления

Bean-компоненты представления — это bean-компоненты класса org.thymeleaf.spring4.view.ThymeleafView, объявленные в контексте приложения (аннотация Bean, если вы используете конфигурацию Java). Они позволяют задавать фрагменты следующим образом:

@Bean(name="content-part")
@Scope("prototype")
public ThymeleafView someViewBean() {
    ThymeleafView view = new ThymeleafView("index"); // templateName = 'index'
    view.setMarkupSelector("content");
    return view;
}

Учитывая приведенное выше определение bean-компонента, если наш контроллер возвращает content-part (имя вышеупомянутого bean-компонента)…

@RequestMapping("/showContentPart")
public String showContentPart() {
    ...
    return "content-part";
}

… Thymeleaf вернет только фрагмент content шаблона индекса — расположение которого, вероятно, будет примерно таким же, как /WEB-INF/templates/index.html, после применения префикса и суффикса. Таким образом, результат будет полностью эквивалентен указанию index :: content:

<!DOCTYPE html>
<html>
  ...
  <body>
    ...
    <div th:fragment="content">
      Only this div will be rendered!
    </div>
    ...
  </body>
</html>

Также обратите внимание, что благодаря мощным селекторам разметки Thymeleaf мы можем выделять фрагмент в шаблоне без каких-либо атрибутов th:fragment. Давайте используем атрибут id, например:

@Bean(name="content-part")
@Scope("prototype")
public ThymeleafView someViewBean() {
    ThymeleafView view = new ThymeleafView("index"); // templateName = 'index'
    view.setMarkupSelector("#content");
    return view;
}

10.2 Определение фрагментов в возвращаемом значении контроллера

Вместо декларирования view beans, фрагменты могут быть определены из контроллера с использованием синтаксиса выражений фрагментов (fragment expressions). Просто как в аттрибутах th:insert или th:replace.

@RequestMapping("/showContentPart")
public String showContentPart() {
    ...
    return "index :: content";
}

Разумеется, снова доступна вся мощь селекторов DOM, поэтому мы можем выбрать наш фрагмент на основе стандартных атрибутов HTML, таких как id=«content»:

@RequestMapping("/showContentPart")
public String showContentPart() {
    ...
    return "index :: #content";
}

И мы также можем использовать параметры, такие как:

@RequestMapping("/showContentPart")
public String showContentPart() {
    ...
    return "index :: #content ('myvalue')";
}

11 Продвинутые интеграционные фичи

11.1 Интеграция с RequestDataValueProcessor

Thymeleaf легко интегрируется с интерфейсом Spring RequestDataValueProcessor. Этот интерфейс позволяет перехватывать URL-адреса ссылок, URL-адреса формы и значения полей формы до их записи в результат разметки, а также прозрачно добавлять скрытые поля формы, которые включают функции безопасности, например, такие как: защита против CSRF (подделка межсайтовых запросов).

Реализация RequestDataValueProcessor может быть легко настроена в контексте приложения. Он должен реализовать интерфейс org.springframework.web.servlet.support.RequestDataValueProcessor и иметь requestDataValueProcessor в качестве имени бина:

@Bean
public RequestDataValueProcessor requestDataValueProcessor() {
  return new MyRequestDataValueProcessor();
}

…и Thymeleaf будет использовать это следующим образом:

• th:href и th:src вызывают RequestDataValueProcessor.processUrl(…) перед отрисовкой URL
• th:action вызывает RequestDataValueProcessor.processAction(…) перед рендерингом атрибута action формы, и дополнительно он обнаруживает, когда этот атрибут применяется к тегу <form>, который в любом случае должен быть единственным местом, и в этом случае вызывает RequestDataValueProcessor.getExtraHiddenFields(…) и добавляет возвращенные скрытые поля непосредственно перед закрывающим тегом </form>
• th:value вызывает RequestDataValueProcessor.processFormFieldValue(…) для отрисовки значения, на которое оно ссылается, если только в том же теге нет th:field (в этом случае th:field сам позаботится)
• th:field вызывает RequestDataValueProcessor.processFormFieldValue(…) для отрисовки значения поля, к которому применяется (или тела тега, если им является <textarea>)

Обратите внимание, что существует очень мало сценариев, в которых вам нужно было бы явно реализовать RequestDataValueProcessor в вашем приложении. В большинстве случаев это будет автоматически использоваться библиотеками безопасности, которые вы прозрачно используете, например, например, Spring Security’s CSRF.

11.1 Построение URIs к контроллерам

Начиная с версии 4.1, Spring дает возможность создавать ссылки на аннотированные контроллеры непосредственно из представлений, без необходимости знать URI, на которые эти контроллеры отображаются.

В Thymeleaf это может быть достигнуто с помощью выражения #mvc.url(…), который позволяет задавать методы контроллера заглавными буквами класса контроллера, в котором они находятся, за которым следует имя метода. Это эквивалентно пользовательской функции spring:mvcUrlx(…) в JSP.

Например, для:

public class ExampleController {

    @RequestMapping("/data")
    public String getData(Model model) { ... return "template" }

    @RequestMapping("/data")
    public String getDataParam(@RequestParam String type) { ... return "template" }

}

Следующий код создаст ссылки на методы:

<a th:href="${(#mvc.url('EC#getData')).build()}">Get Data Param</a>
<a th:href="${(#mvc.url('EC#getDataParam').arg(0,'internal')).build()}">Get Data Param</a>

Вы можето почитать об этом механизме по ссылке http://docs.spring.io/spring-framework/docs/4.1.2.RELEASE/spring-framework-reference/html/mvc.html#mvc-links-to-controllers-from-views

12 Spring WebFlow интеграция

Интеграционные пакеты Thymeleaf + Spring включают интеграцию с Spring WebFlow (2.3+).

WebFlow включает некоторые возможности AJAX для рендеринга фрагментов отображаемой страницы при срабатывании определенных событий (переходов), и чтобы Thymeleaf мог отслеживать эти запросы AJAX, нам нужно будет использовать другую реализацию ViewResolver, настроенную так:

<bean id="thymeleafViewResolver" class="org.thymeleaf.spring4.view.AjaxThymeleafViewResolver">
    <property name="viewClass" value="org.thymeleaf.spring4.view.FlowAjaxThymeleafView" />
    <property name="templateEngine" ref="templateEngine" />
</bean>

… и тогда этот ViewResolver может быть сконфигурирован в WebFlow ViewFactoryCreator как:

<bean id="mvcViewFactoryCreator" 
      class="org.springframework.webflow.mvc.builder.MvcViewFactoryCreator">
    <property name="viewResolvers" ref="thymeleafViewResolver"/>
</bean>

Отсюда вы можете определить шаблоны Thymeleaf в вашем view-state’s:

<view-state id="detail" view="bookingDetail">
    ...
</view-state>

В приведенном выше примере bookingDetail — это шаблон Thymeleaf, указанный обычным способом, понятный любому из резолверов шаблона, настроенных в TemplateEngine.

12.2 AJAX фрагменты в Spring WebFlow

Обратите внимание, что здесь объясняется только способ создания фрагментов AJAX для использования с Spring WebFlow. Если вы не используете WebFlow, создание контроллера Spring MVC, который отвечает на запрос AJAX и возвращает кусок HTML, так же просто, как и создание любого другого контроллера, возвращающего шаблон, с единственным исключением, что вы, вероятно, будете возвращать фрагмент наподобие «main :: admin» из вашего метода контроллера.

WebFlow позволяет определить отрисовку через AJAX с <render> тегов, например так:

<view-state id="detail" view="bookingDetail">
    <transition on="updateData">
        <render fragments="hoteldata"/>
    </transition>
</view-state>

Эти фрагменты (в данном случае hoteldata) могут представлять собой разделенный запятыми список фрагментов, указанных в разметке с помощью th:fragment:

<div id="data" th:fragment="hoteldata">
    This is a content to be changed
</div>

Всегда помните, что указанные фрагменты должны иметь атрибут id, чтобы библиотеки Spring JavaScript, работающие в браузере, могли заменить разметку.

Теги <render> также можно указывать с помощью селекторов DOM:

<view-state id=«detail» view=«bookingDetail»>
/>

</view-state>

…и это означает, что нет нужды в th:fragment:

<div id="data">
    This is a content to be changed
</div>

Что касается кода, который запускает переход updateData, он выглядит следующим образом:

<script type="text/javascript" th:src="@{/resources/dojo/dojo.js}"></script>
<script type="text/javascript" th:src="@{/resources/spring/Spring.js}"></script>
<script type="text/javascript" th:src="@{/resources/spring/Spring-Dojo.js}"></script>

  ...

<form id="triggerform" method="post" action="">
    <input type="submit" id="doUpdate" name="_eventId_updateData" value="Update now!" />
</form>

<script type="text/javascript">
    Spring.addDecoration(
        new Spring.AjaxEventDecoration({formId:'triggerform',elementId:'doUpdate',event:'onclick'}));
</script>

I recently saw an old post on StackOverflow called
How to get form validation errors after binding the request to the form.
It has a lot of answers, most of them are only partially right and a lot
are outdated. So, I wanted to look at the right answer, and why it’s that
way :).

Debugging

First, if you’re trying to figure out what errors you have and which field
each is attached to, you should use the
Form::getErrorsAsString()
method that was introduced in Symfony 2.1 (so a long time ago!). Use it temporarily
in a controller to see what’s going on::

public function formAction(Request $request)
{
    $form = $this->createForm(new ProductType());

    $form->handleRequest($request);
    if ($form->isValid()) {
        // ... form handling
    }

    var_dump($form->getErrorsAsString());die;

    $this->render(
        'DemoBundle:Product:form.html.twig',
        array('form' => $form->createView())
    );
}

That’s it. To make things even simpler, you also have the Form panel of
the web debug toolbar in Symfony 2.4. So, debugging form errors

Why $form->getErrors() doesn’t Work

Raise your hand virtually if you’ve tried doing this to debug a form::

public function formAction(Request $request)
{
    $form = $this->createForm(new ProductType());

    $form->handleRequest($request);
    if ($form->isValid()) {
        // ... form handling
    }

    var_dump($form->getErrors());die;

    $this->render(
        'DemoBundle:Product:form.html.twig',
        array('form' => $form->createView())
    );
}

What do you get? Almost definitely an empty array, even when the form has
lots of errors. Yea, I’ve been there too.

The reason is that a form is actually more than just one Form object:
it’s a tree of Form objects. Each field is represented by its own Form
object and the errors for that field are stored on it.

Assuming the form has name and price fields, how can we get the errors
for each field?

$globalErrors = $form->getErrors()
$nameErrors = $form['name']->getErrors();
$priceErrors = $form['price']->getErrors();

By saying $form['name'], we get the Form object that represents just
the name field, which gives us access to just the errors attached to
that field. This means that there’s no one spot to get all of the errors
on your entire form. Saying $form->getErrors() gives you only «global»
errors, i.e. errors that aren’t attached to any specific field (e.g. a CSRF token
failure).

Render all the Errors at the Top of your Form

One common question is how you might render all of your errors in one big
list at the top of your form. Again, there’s no one spot where you can
get a big array of all of the errors, so you’d need to build it yourself::

// a simple, but incomplete (see below) way to collect all errors
$errors = array();
foreach ($form as $fieldName => $formField) {
    // each field has an array of errors
    $errors[$fieldName] = $formField->getErrors();
}

We can iterate over $form (a Form object) to get all of its fields.
And again, remember that each field ($formField here), is also a Form
object, which is why we can call
Form::getErrors()
on each.

In reality, since a form can be many-levels deep, this solution isn’t good
enough. Fortunately, someone already posted a more complete one on
Stack Overflow (see the 2.1 version).

From here, you can pass these into your template and render each. Of course,
you’ll need to make sure that you don’t call {{ form_errors() }} on any
of your fields, since you’re printing the errors manually (and remember that
form_row calls form_errors automatically).

Accessing Errors Inside Twig

We can also do some magic in Twig with errors using magical things called
form variables. These guys are absolutely fundamental to customizing
how your forms render.

Normally, field errors are rendered in Twig by calling form_errors on
each individual field:

{{ form_errors(form) }}

{{ form_label(form.name) }}
{{ form_widget(form.name) }}
{{ form_errors(form.name) }}

Just like in the controller, the errors are attached to the individual fields
themselves. Hopefully it make sense now why form_errors(form) renders global
errors and form_errors(form.name) renders the errors attached to the
name field.

If you need to customize how the errors are rendered, you can always use
form theming. But you can also do it by leverage form variables:

{{ form_errors(form) }}

{{ form_label(form.name) }}
{{ form_widget(form.name) }}

{% if form.name.vars.errors|length > 0 %}
<ul class="form-errors name">
    {% for error in form.name.vars.errors %}
        {{ error }}
    {% endfor %}
</ul>
{% endif %}

The key here is form.name.vars: a strange array of «variables» that you
have access to on every field. One of the variables you have access to
is errors, but there are many others, like label and required.
Each variable is normally used internally to render the field, but you can
use them manually if you need to:

<label for="form.name.vars.id">
    {{ form.name.vars.label }} {{ form.name.vars.required ? '*' : '' }}
</label>

To find out what variables a field has, just dump them:

{{ dump(form.price.vars) }}

Now that you know about the magic form.vars, you could also use it to render
all validation errors at the top of your form. This will only work for simple forms
(i.e. forms without nested fields), which most forms are:

{% set messages = [] %}
{% for child in form.children %}
    {% for error in child.vars.errors %}
        {% set messages = messages|merge([error.message]) %}
    {% endfor %}
{% endfor %}
{% if messages|length %}
    <ul>
        {% for message in messages %}
            <li>{{ message }}</li>
        {% endfor %}
    </ul>
{% endif %}

Takeaways

The key lesson is this: each form is a big tree. The top level Form has
children, each which is also a Form object (or a FormView object
when you’re in Twig). If you want to access information about a field (is
it required? what are its errors?), you need to first get access to the child
form and go from there.

Learn More

Stuck on other Symfony topics or want to learn Symfony from the context of
an actual project? Check out our Getting Started with Symfony Series and
cut down on your learning curve!

Возвращает массив со всеми значениями пользовательских полей для определенной записи, пользователя, комментария, термина и так далее.

Хуков нет.

Возвращает

(Массив). Ассоциативный массив (field name => field value).

Использование

get_fields( $post_id, $format_value );

$post_id(mixed)

ID записи (пользователя, рубрики и .д.), для которой нужно получить метаполя.
По умолчанию: false (ID текущей записи в цикле)

$format_value(bool)

Применять ли форматирование, указанное в настройках поля.
По умолчанию: true

Примеры

$fields = get_fields();

if( $fields ): ?>
	<ul>
		<?php foreach( $fields as $name => $value ): ?>
			<li><b><?php echo $name; ?></b> <?php echo $value; ?></li>
		<?php endforeach; ?>
	</ul>
<?php endif; ?>

// Получим значения всех метаполей текущей записи.
$fields = get_fields();

// Получим значения всех метаполей записи с ID = 1.
$post_fields = get_fields( 1 );

// Получим значения всех метаполей пользователя с ID = 2.
$user_fields = get_fields( 'user_2' );

// Получим значения всех метаполей термина с ID = 3.
$term_fields = get_fields( 'term_3' );

// Получим значения всех метаполей термина с таксономией category и ID = 3.
$term_fields = get_fields( 'category_3' );

// Получим значения всех метаполей комментария с ID = 4.
$comment_fields = get_fields( 'comment_4' );

// Получим значения всех метаполей всех страниц опций, созданных ACF.
$option_fields = get_fields( 'options' );

// Или так.
$option_fields = get_fields( 'option' );

$fields = get_fields( 123, false );

Viewing 25 posts — 1 through 25 (of 88 total)