It should be max and min value - not length. See [here](07c3ba84fb/wagtail/wagtailcore/blocks/field_block.py (L306)).
So this would work
`blocks.IntegerBlock(max_value=10, min_value=0)`
but this wouldn't do anything
`blocks.IntegerBlock(max_length=10, min_length=0)`
This is where developers expect it to be, similar to Django and other
projects. The version info still exists at the old `wagtail.wagtailcore`
location, for backwards compatibility.
Fixes #2557
Client-side validation fails on forms with prefilled file upload fields -
see https://code.djangoproject.com/ticket/27037. This is fixed in Django 1.10.1,
so as a workaround we disable client-side validation (using the 'novalidate'
attribute) for forms with enctype="multipart/form-data" on Django 1.10 only.
Fixes #2897
Partially addresses #2401; adapted from #2463.
Updates the explorer-nav logic to take the user's permissions into account.
The menu now begins at the closest common ancestor node of all pages they
have add/edit/publish/lock permission for - as a result, users with
permission over a specific deep section of the tree don't have to redundantly
drill down to it, and we're a step closer to true 'multi-homed' installations
where the user is not made aware of tree structure that exists outside of
their own remit.
Nested objects that are defined using RelatedFields were being mapped into Elasticsearch using the parent model's mapping.
For example, if we index a page with tags, the tags were being mapped with the Page mapping instead of the Tag mapping.
This doesn't make any difference for Elasticsearch 1, but Elasticsearch 2 needs to prefix fields if there are defined on a child model and it was doing this across the related fields as well.
This fix is covered by the tests coming in the Elasticsearch 2 backend.
We need to prefix some fields in Elasticsearch 2 but not Elasticsearch 1. Moving this code into the ElasticsearchMapping class allows us to override it.
It also makes sense to have this sort of thing in the backend rather than the core as other search backends we add in the future may want different behaviour as well.
