Wagtail 2.11 is designated a Long Term Support (LTS) release. Long Term Support releases will continue to receive maintenance updates as necessary to address security and data-loss related issues, up until the next LTS release (typically a period of 12 months).
Collections (for organising images, documents or other media) can now be managed as a hierarchy rather than a flat list. This feature was developed by Robert Rollins.
* Add ``before_edit_snippet``, ``before_create_snippet`` and ``before_delete_snippet`` hooks and documentation (Karl Hobley. Sponsored by the Mozilla Foundation)
* Add ``register_snippet_listing_buttons`` and ``construct_snippet_listing_buttons`` hooks and documentation (Karl Hobley. Sponsored by the Mozilla Foundation)
* Extend treebeard's ``fix_tree`` method with the ability to non-destructively fix path issues and add a --full option to apply path fixes (Matt Westcott)
* Make document ``content-type`` and ``content-disposition`` configurable via ``WAGTAILDOCS_CONTENT_TYPES`` and ``WAGTAILDOCS_INLINE_CONTENT_TYPES`` (Matt Westcott)
* Add ``register_snippet_action_menu_item`` and ``construct_snippet_action_menu`` hooks to modify the actions available when creating / editing a snippet (Karl Hobley)
This release begins the process of phasing out support for Internet Explorer. Please see :ref:`ie11` for details of the timeline over which support will be dropped.
The SiteMiddleware class (which provides the ``request.site`` property, and has been deprecated since Wagtail 2.9) has been moved to the ``wagtail.contrib.legacy`` namespace. On projects where this is still in use, the ``'wagtail.core.middleware.SiteMiddleware'`` entry in ``MIDDLEWARE`` should be changed to ``'wagtail.contrib.legacy.sitemiddleware.SiteMiddleware'``.
As part of the hierarchical collections support, the ``path`` field on the Collection model now enforces alphabetical ordering. Previously, collections were stored in the order in which they were created - and then sorted by name where displayed in the CMS. This change will be handled automatically through migrations when upgrading to Wagtail 2.11.
However, if your project creates new collections programmatically after migrations have run, and assigns the ``path`` field directly - for example, by loading from a fixture file - this code will need to be updated to insert them in alphabetical order. Otherwise, errors may occur when subsequently adding new collections through the Wagtail admin. This can be done as follows:
* Update paths to match alphabetical order. For example, if you have a fixture that creates the collections ``Zebras`` and ``Aardvarks`` with paths ``00010001`` and ``00010002`` respectively, these paths should be swapped.
**Alternatively*, after creating the collections, run the Python code:
In previous releases, ``Site.get_site_root_paths`` returned a list of ``(site_id, root_path, root_url)`` tuples. To support the new internationalisation model, this has now been changed to a list of named tuples with the fields: ``site_id``, ``root_path``, ``root_url`` and ``language_code``. Existing code that handled this as a 3-tuple should be updated accordingly.
Basic StreamField block types such as CharBlock previously accepted a ``classname`` keyword argument, to specify a ``class`` attribute to appear on the page editing form. For consistency with StructBlock, this has now been changed to ``form_classname``. The ``classname`` argument is still recognised, but deprecated.
