Wagtail 1.11 release notes¶
What’s new¶
Privacy settings on documents¶
Privacy settings can now be configured on collections, to restrict access to documents either by shared password or by user account. See: Private pages.
This feature was developed by Ulrich Wagner and Matt Westcott. Thank you to Wharton Research Data Services of The Wharton School for sponsoring this feature.
Other features¶
- Optimised page URL generation by caching site paths in the request scope (Tobias McNulty, Matt Westcott)
- The current live version of a page is now tracked on the revision listing view (Matheus Bratfisch)
- Each block created in a
StreamField
is now assigned a globally unique identifier (Matt Westcott)- Mixcloud oEmbed pattern has been updated (Alice Rose)
- Added
last_published_at
field to the Page model (Matt Westcott)- Added
show_in_menus_default
flag on page models, to allow “show in menus” to be checked by default (LB (Ben Johnston))- “Copy page” form now validates against copying to a destination where the user does not have permission (Henk-Jan van Hasselaar)
- Allows reverse relations in
RelatedFields
for elasticsearch & PostgreSQL search backends (Lucas Moeskops, Bertrand Bordage)- Added oEmbed support for Facebook (Mikalai Radchuk)
- Added oEmbed support for Tumblr (Mikalai Radchuk)
Bug fixes¶
- Unauthenticated AJAX requests to admin views now return 403 rather than redirecting to the login page (Karl Hobley)
TableBlock
optionsafterChange
,afterCreateCol
,afterCreateRow
,afterRemoveCol
,afterRemoveRow
andcontextMenu
can now be overridden (Loic Teixeira)- The lastmod field returned by wagtailsitemaps now shows the last published date rather than the date of the last draft edit (Matt Westcott)
- Document chooser upload form no longer renders container elements for hidden fields (Jeffrey Chau)
- Prevented exception when visiting a preview URL without initiating the preview (Paul Kamp)
Upgrade considerations¶
Caching of site-level URL information throughout the request cycle¶
The get_url_parts
and relative_url
methods on Page
now accept an optional request
keyword argument.
Additionally, two new methods have been added, get_url
(analogous to the url
property) and get_full_url
(analogous to the full_url
) property. Whenever possible, these methods should be used instead of the property
versions, and the request passed to each method. For example:
page_url = my_page.url
would become:
page_url = my_page.get_url(request=request)
This enables caching of underlying site-level URL information throughout the request cycle, thereby significantly reducing the number of cache or SQL queries your site will generate for a given page load. A common use case for these methods is any custom template tag your project may include for generating navigation menus. For more information, please refer to Page URLs.
Furthermore, if you have overridden get_url_parts
or relative_url
on any of your page models, you will need to
update the method signature to support this keyword argument; most likely, this will involve changing the line:
def get_url_parts(self):
to:
def get_url_parts(self, *args, **kwargs):
and passing those through at the point where you are calling get_url_parts
on super
(if applicable).
See also: wagtail.core.models.Page.get_url_parts()
, wagtail.core.models.Page.get_url()
,
wagtail.core.models.Page.get_full_url()
, and wagtail.core.models.Page.relative_url()
“Password required” template for documents¶
This release adds the ability to password-protect documents as well as pages. The template used for the “password required” form is distinct from the one used for pages; if you have previously overridden the default template through the PASSWORD_REQUIRED_TEMPLATE
setting, you may wish to provide a corresponding template for documents through the setting DOCUMENT_PASSWORD_REQUIRED_TEMPLATE
. See: Private pages
Elasticsearch 5.4 is incompatible with ATOMIC_REBUILD
¶
While not specific to Wagtail 1.11, users of Elasticsearch should be aware that the ATOMIC_REBUILD
option is not compatible with Elasticsearch 5.4.x due to a bug in the handling of aliases. If you wish to use this feature, please use Elasticsearch 5.3.x or 5.5.x (when available).