The StreamField editing interface has been rebuilt on a client-side rendering model, powered by the `telepath <https://wagtail.github.io/telepath/>`_ library. This provides better performance, increased customisability and UI enhancements including the ability to duplicate blocks. For further background, see the blog post `Telepath - the next evolution of StreamField <https://wagtail.org/blog/telepath/>`_.
This feature was developed by Matt Westcott and Karl Hobley and sponsored by `YouGov <https://yougov.co.uk/>`_, inspired by earlier work on `react-streamfield <https://github.com/wagtail/wagtail-react-streamfield>`_ completed by Bertrand Bordage through the `Wagtail's First Hatch <https://www.kickstarter.com/projects/noripyt/wagtails-first-hatch>`_ crowdfunder.
In Wagtail 2.12 we shipped the new localisation support, but in order to translate content an external library had to be used, such as `wagtail-localize <https://www.wagtail-localize.org>`_.
In this release, a new contrib app has been introduced called :doc:`simple_translation </reference/contrib/simple_translation>`. This allows you to create copies of pages and translatable snippets in other languages and translate them as regular Wagtail pages. It does not include any more advanced translation features such as using external services, PO files, or an interface that helps keep translations in sync with the original language.
The page editor now supports leaving comments on fields and StreamField blocks, by entering commenting mode (using the button in the top right of the editor). Inline comments are available in rich text fields using the Draftail editor.
The "Account settings" section available at the bottom of the admin menu has been updated to include all settings on a single form. This feature was developed by Karl Hobley.
The `documentation <https://docs.wagtail.org/>`_ now uses our brand new `Sphinx Wagtail Theme <https://github.com/wagtail/sphinx_wagtail_theme>`_, with a search feature powered by `Algolia DocSearch <https://docsearch.algolia.com/>`_.
Feedback and feature requests for the theme may be reported to the `sphinx_wagtail_theme issue list <https://github.com/wagtail/sphinx_wagtail_theme/issues>`_, and to Wagtail’s issues for the search.
Thank you to Storm Heg, Tibor Leupold, Thibaud Colas, Coen van der Kamp, Olly Willans, Naomi Morduch Toubman, Scott Cranfill, and Andy Chosak for making this happen!
* Support passing multiple models as arguments to ``type()``, ``not_type()``, ``exact_type()`` and ``not_exact_type()`` methods on ``PageQuerySet`` (Andy Babic)
Wagtail 2.13 will be the last Wagtail release to support IE11. Users accessing the admin with IE11 will be shown a warning message advising that support is being phased out.
The rules for determining whether a StreamField is required (i.e. at least one block must be provided) have been simplified and made consistent with other field types. Non-required fields are now indicated by ``blank=True`` on the ``StreamField`` definition; the default is ``blank=False`` (the field is required). In previous versions, to make a field non-required, it was necessary to define a top-level ``StreamBlock`` with ``required=False`` (which applied the validation rule) as well as setting ``blank=True`` (which removed the asterisk from the form field). You should review your use of StreamField to check that ``blank=True`` is used on the fields you wish to make optional.
For the majority of cases, the new StreamField implementation in this release will be a like-for-like upgrade, and no code changes will be necessary - this includes projects where custom block types have been defined by extending ``StructBlock``, ``ListBlock`` and ``StreamBlock``. However, certain complex customisations may need to be reimplemented to work with the new client-side rendering model:
* When customising the form template for a ``StructBlock`` using the ``form_template`` attribute, the HTML of each child block must be enclosed in an element with a ``data-contentpath`` attribute equal to the block's name. This attribute is used by the commenting framework to attach comments to the correct fields. See :ref:`custom_editing_interfaces_for_structblock`.
* If a ``StructBlock`` subclass overrides the ``get_form_context`` method as part of customising the form template, and that method contains logic that causes the returned context to vary depending on the block value, this will no longer work as intended. This is because ``get_form_context`` is now invoked once with the block's default (blank) value in order to construct a template for the client-side rendering to use; previously it was called for each block in the stream. In the new implementation, any Python-side processing that needs to happen on a per-block-value basis can be performed in the block's ``get_form_state`` method; the data returned from that method will then be available in the client-side ``render`` method.
* If ``FieldBlock`` is used to wrap a Django widget with non-standard client-side behaviour - such as requiring a JavaScript function to be called on initialisation, or combining multiple HTML elements such that it is not possible to read or write its data by accessing a single element's ``value`` property - then you will need to supply a JavaScript handler object to define how the widget is rendered and populated, and how to extract data from it.
* Packages that replace the StreamField interface at a low level, such as ``wagtail-react-streamfield``, are likely to be incompatible (but the new StreamField implementation will generally offer equivalent functionality).
Setting menu items now use SVG icons by default. For sites reusing built-in Wagtail icons, no changes should be required. For sites using custom font icons, update the menu items’ definition to use the ``classnames`` attribute:
