Skip to content

[Form] Customizing Error Output #3542

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dlondero opened this issue Feb 5, 2014 · 4 comments
Closed

[Form] Customizing Error Output #3542

dlondero opened this issue Feb 5, 2014 · 4 comments

Comments

@dlondero
Copy link
Contributor

dlondero commented Feb 5, 2014

Looks like there's a typo when explaining how to customize error output for global errors in forms.

In the docs you can read:

To override how errors are rendered for all fields, simply copy, paste and customize the form_errors fragment.

and just a few lines below:

To customize only the markup used for these errors, follow the same directions as above, but now call the block form_errors (Twig) / the file form_errors.html.php (PHP).

Both changes apply to form_errors...is that right?

@mtrojanowski
Copy link
Contributor

Actually it was not a typo but some leftovers from the 2.0. documentation. In Sf 2.0. you used two different blocks for customizing errors: field_errors and form_errors with the former applied to fields and the latter to global errors.

As of Sf 2.1. you use only form_errors block and differentiate between different types of errors by checking the value of compound.

From the Upgrade 2.1. doc:

Before:

{% block form_errors %}
    {% spaceless %}
        ... form code ...
    {% endspaceless %}
{% endblock form_errors %}

{% block field_errors %}
    {% spaceless %}
        ... field code ...
    {% endspaceless %}
{% endblock field_errors %}

After:

{% block form_errors %} 
    {% spaceless %}
        {% if compound %}
             ... form code ...
        {% else %}
              ... field code ...
        {% endif %}
    {% endspaceless %}
{% endblock form_errors %}

@dlondero
Copy link
Contributor Author

dlondero commented Feb 5, 2014

I wonder why that's not here. Or am I looking in the wrong place?

@mtrojanowski
Copy link
Contributor

By default the errors are rendered in the same way regardless of the fact if it's a field or global error.

@dlondero
Copy link
Contributor Author

dlondero commented Feb 5, 2014

That's right, so adding that (the compound thingy I mean) to the docs is a must have IMHO.

weaverryan added a commit that referenced this issue Mar 18, 2014
…rojanowski)

This PR was merged into the 2.3 branch.

Discussion
----------

Fix the definition of customizing form's global errors.

The documentation for customizing global errors was actually still referring to the way it was done in 2.0. (where two different blocks were used: `field_errors` and `form_errors`). Since 2.1. only `form_errors` is used and errors are differentiated using the `compound` variable (set to `true` for form errors).

| Q             | A
| ------------- | ---
| Doc fix?      | yes
| New docs?     | no
| Applies to    | 2.3+
| Fixed tickets | #3542

Commits
-------

6f6fcca Applied some changes according to comments.
e3b20d8 Minor rewording. Added tip about meaning of `compound` var and expanded the example code to contain `else` statements.
1e278c4 Added note about customizing errors for different field types.
236d06b Fix the definition of customizing form's global errors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants