Save is handled by the 'is this a form submission' check, and preview was probably
never needed at all (preview opens in a new window and does not unload the page,
unless there's a validation error, which is handled separately)
When the page edit form is redisplayed on validation errors, we set alwaysDirty on the
dirty form handler logic so that navigating away triggers the unsaved changes warning
even if no further changes are made. However, the old code tested `form.errors`, which
fails to catch validation errors originating from formsets.
The Jinja2 template config here isn't currently used at all - having
the same APP_DIRS / DIRS config as the Django template engine (which
has higher precedence) means that it will never be selected for
rendering templates, and the existing jinja2 tests bypass Django's
template engine selection and call the jinja2 engine directly.
By giving jinja2 templates their own dedicated location, we can reliably
control which engine is used for which templates.
Ever since the test settings got their own file, this has pointed to
the 'tests' folder instead. Luckily this had no ill effects, since
it's only used as the base for the temporary STATIC_ROOT / MEDIA_ROOT
folders.
* Renamed search backend classes
* DBSearch => DatabaseSearch
* ElasticSearchBackend => ElasticsearchSearchBackend
This probably looks a little funny. I need to inject the number 2 into this name somewhere for the Elasticsearch 2 backend. I think Elasticsearch2SearchBackend is the best name so need rename the current backend for consistency.
* Deprecation warning for referencing renamed backend in settings
When the API was originally created, this was not possible to do with Wagtail search. So I added a check to prevent people from doing it.
Custom ordering was implemented in Wagtailsearch in #1815 so this can now be switched on.
Partially fixes#2513 - Firefox and Chrome (and hopefully Edge >=13) do not trigger
onbeforeunload events when following these links. Safari and IE don't currently
support it, though.
test_group_form_includes_non_registered_permissions_in_initial_data fails in
Django 1.10rc1 because the native value of a ManyToManyField (as reflected in
form.initial) is now a queryset rather than a list of PKs. However, this test
is not actually testing anything meaningful. It asserts that the initial
value of the 'permissions' field includes any permissions the group has which
are not included in registered_permissions; however, since these permissions
don't appear in the form, it's inconsequential whether they're included or not.
Mikalai Radchuk