We can't guarantee that search backends are able to search on a queryset
that has been filtered by a relation such as tags (see #459). The JS code
currently avoids applying a tag filter and a search query at the same
time; this change makes that behaviour explicit at the view level too.
Searching by tag only works under Elasticsearch, so clicking on 'popular tags' is broken
in the default install. As a workaround, add a new 'tag' parameter to the chooser view
that allows us to filter on tags using plain SQL lookup, as a separate operation to search.
If the Wagtail install has only one site, link to the homepage of that
site from the dashboard page summary instead of the root page of the
hierarchy.
Hopefully this will prevent some of the confusion causing people to
create pages under the root page, where they are inaccessible. See #1612
for more information around this issue.
Wagtail installs with multiple (or zero) sites retain the old behaviour
of linking to the root page.
Two new assertions have been added: `assertAllowedSubpageTypes` and
`assertAllowedParentPageTypes`. They both take a Page class, and a set
of Page classes, and compares the allowed subpage / parent page models
for the Page class to the set passed in.
`wagtail.tests.utils.WagtailPageTests` is a new `TestCase` subclass that
helps developers write tests for their Wagtail sites. It currently
includes three assert methods:
`assertCanCreateAt(parent_model, child_model)`, which asserts that a
child page of a certain type could be created underneath a parent page.
This is useful for making assertions around the business rules of your
site.
`assertCanNotCreateAt(parent_model, child_model)` is the inverse of the
above.
`assertCanCreate(parent, child_model, data)` asserts that a child page
can be added underneath the given parent page, by POSTing `data` at the
correct page in the Wagtail admin. This checks that the developer has
correctly configured their `content_panels` and related options.
These methods are just a start, and could be expanded further. More
methods could be added, asserting that Snippets can be created, for
example. The current methods could be extended further, to validate more
about the Wagtail admin page editor.
Previously, if a developer wanted to use a custom Manager on their Page
subclass, some fairly hacky hacks were required. Now, the `objects`
attribute is only overridden if it is a plain `Manager`. If it is
anything else, it is left alone. A system check has been added to ensure
that all `Page` managers inherit from `PageManager`
