mirror of
https://github.com/wagtail/wagtail.git
synced 2024-11-29 01:22:07 +01:00
7bc819640d
Django's standard behaviour is to preserve managers that are set on abstract superclasses, so this allows us to eliminate the metaclass hackery. Fixes #2933
39 lines
1.5 KiB
ReStructuredText
39 lines
1.5 KiB
ReStructuredText
============================================
|
|
Wagtail 1.6.1 release notes - IN DEVELOPMENT
|
|
============================================
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 1
|
|
|
|
|
|
What's new
|
|
==========
|
|
|
|
Bug fixes
|
|
~~~~~~~~~
|
|
|
|
* Wagtail's middleware classes are now compatible with Django 1.10's `new-style middleware <https://docs.djangoproject.com/en/1.10/releases/1.10/#new-style-middleware>`_ (Karl Hobley)
|
|
* The :meth:`~wagtail.wagtailcore.models.Page.can_create_at` method is now checked in the create page view (Mikalai Radchuk)
|
|
* Fixed regression on Django 1.10.1 causing Page subclasses to fail to use PageManager (Matt Westcott)
|
|
|
|
|
|
Upgrade considerations
|
|
======================
|
|
|
|
Multi-level inheritance and custom managers
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The inheritance rules for :ref:`custom_page_managers` have been updated to match Django's standard behaviour. In the vast majority of scenarios there will be no change. However, in the specific case where a page model with a custom ``objects`` manager is subclassed further, the subclass will be assigned a plain ``Manager`` instead of a ``PageManager``, and will now need to explicitly override this with a ``PageManager`` to function correctly:
|
|
|
|
.. code-block:: python
|
|
|
|
class EventPage(Page):
|
|
objects = EventManager()
|
|
|
|
|
|
class SpecialEventPage(EventPage):
|
|
# Previously SpecialEventPage.objects would be set to a PageManager automatically;
|
|
# this now needs to be set explicitly
|
|
objects = PageManager()
|