Mar 18, 2014 · Feb 5, 2014 · Feb 5, 2014 · Feb 20, 2014 · Mar 16, 2014 · Feb 20, 2014
diff --git a/cookbook/form/form_customization.rst b/cookbook/form/form_customization.rst
    See :ref:`cookbook-form-theming-methods` for how to apply this customization.

 You can also customize the error output for just one specific field type.
 For example, certain errors that are more global to your form (i.e. not specific
 to just one field) are rendered separately, usually at the top of your form:
 To customize *only* the markup used for these errors, follow the same directions
 as above but put the contents in a relative ``_errors`` block (or file in case
 of PHP templates). For example: ``text_errors`` (or ``text_errors.html.php``).

 .. tip::

    See :ref:`form-template-blocks` to find out which specific block or file you
    have to customize.

 Certain errors that are more global to your form (i.e. not specific to just one
 field) are rendered separately, usually at the top of your form:

 .. configuration-block::

        <?php echo $view['form']->render($form); ?>

 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). Now, when errors for the ``form`` type are rendered, your customized
 fragment will be used instead of the default ``form_errors``.
 as above, but now check if the ``compound`` variable is set to ``true``. If it
 is ``true``, it means that what's being currently rendered is a collection of
 fields (e.g. a whole form), and not just an individual field.

 .. configuration-block::

    .. code-block:: html+jinja

        {# form_errors.html.twig #}
        {% block form_errors %}
            {% spaceless %}
                {% if errors|length > 0 %}
                    {% if compound %}
                        <ul>
                            {% for error in errors %}
                                <li>{{ error.message }}</li>
                            {% endfor %}
                        </ul>
                    {% else %}
                        {# ... display the errors for a single field #}
                    {% endif %}
                {% endif %}
            {% endspaceless %}
        {% endblock form_errors %}

    .. code-block:: html+php

        <!-- form_errors.html.php -->
        <?php if ($errors): ?>
            <?php if ($compound): ?>
                <ul>
                    <?php foreach ($errors as $error): ?>
                        <li><?php echo $error->getMessage() ?></li>
                    <?php endforeach; ?>
                </ul>
            <?php else: ?>
                <!-- ... render the errors for a single field -->
            <?php endif; ?>
        <?php endif ?>


 Customizing the "Form Row"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
Original file line number	Diff line number	Diff line change
Expand Up		@@ -771,8 +771,17 @@ and customize the ``form_errors`` fragment.
		See :ref:`cookbook-form-theming-methods` for how to apply this customization.

		You can also customize the error output for just one specific field type.
		For example, certain errors that are more global to your form (i.e. not specific
		to just one field) are rendered separately, usually at the top of your form:
		To customize only the markup used for these errors, follow the same directions
		as above but put the contents in a relative ``_errors`` block (or file in case
		of PHP templates). For example: ``text_errors`` (or ``text_errors.html.php``).

		.. tip::

		See :ref:`form-template-blocks` to find out which specific block or file you
		have to customize.

		Certain errors that are more global to your form (i.e. not specific to just one
		field) are rendered separately, usually at the top of your form:

		.. configuration-block::

Expand All		@@ -785,9 +794,46 @@ to just one field) are rendered separately, usually at the top of your form:
		<?php echo $view['form']->render($form); ?>

		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). Now, when errors for the ``form`` type are rendered, your customized
		fragment will be used instead of the default ``form_errors``.
		as above, but now check if the ``compound`` variable is set to ``true``. If it
		is ``true``, it means that what's being currently rendered is a collection of
		fields (e.g. a whole form), and not just an individual field.

		.. configuration-block::

		.. code-block:: html+jinja

		{# form_errors.html.twig #}
		{% block form_errors %}
		{% spaceless %}
		{% if errors\|length > 0 %}
		{% if compound %}
		<ul>
		{% for error in errors %}
		<li>{{ error.message }}</li>
		{% endfor %}
		</ul>
		{% else %}
Copy link ContributorAuthor mtrojanowskiFeb 20, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. There is now an`else` part in both examples. I filled the`else` part only with comments so as not to confuse people.
		{# ... display the errors for a single field #}
		{% endif %}
Copy link Member weaverryanFeb 11, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. What about the else? We're not trying to customize the else case here, but of course without it, non-compound errors won't show up - so we'll need something :) Copy link Member weaverryanFeb 11, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. btw,@mtrojanowski happy to see you around here lately :)
		{% endif %}
		{% endspaceless %}
		{% endblock form_errors %}

		.. code-block:: html+php

		<!-- form_errors.html.php -->
		<?php if ($errors): ?>
		<?php if ($compound): ?>
		<ul>
		<?php foreach ($errors as $error): ?>
Copy link Member wouterjFeb 21, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. I think our standard is to put a space before`:` Copy link Member xabbuhFeb 25, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. Really? Copy link Member wouterjFeb 25, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. I always did it, and afaik I have started creating php template code blocks in the docs. Copy link Member xabbuhFeb 25, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. We should indeed be consistent. Can you link to an example? At least,the templating chapter doesn't use spaces this way. Copy link Member weaverryanMar 8, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. No spaces - check out the`form_errors.html.php` used in the core for form theming :)
		<li><?php echo $error->getMessage() ?></li>
		<?php endforeach; ?>
Copy link Member wouterjFeb 21, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. we never use the trailing semi colon when using "templating PHP" Copy link Member weaverryanMar 8, 2014 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. Then I guess we should - shows up in`form_errors.html.php` in core
		</ul>
		<?php else: ?>
		<!-- ... render the errors for a single field -->
		<?php endif; ?>
		<?php endif ?>


		Customizing the "Form Row"
		~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down