According to the ARIA spec:
> A region that contains mostly site-oriented content, rather than page-specific content.
> Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.
Where the `banner` role was applied was more page-specific than
site-specific. In addition, tags with `banner` roles should not live
under another landmark. To rectify, removed the misused banner roles.
Remove inappropriate contentinfo landmarks
According to ARIA spec 1.1
> A large perceivable region that contains information about the parent document.
> Examples of information included in this region of the page are copyrights and links to privacy statements.
They don't apply to the action buttons on where this was applied to.
Add main landmark to 404 page
- fixes#5099
- test_copy_page_with_excluded_parental_and_child_relations
- ensure the tests are wrapped in a try/finally so that the model is always reset back even if tests fail
- update page model tests
Fixeswagtail/wagtail#5937
This reverts Wagtail's behaviour to match Django's, where an error is
raised as a safety mechanism.
Projects relying on the non-safe behaviour should update e.g.
`MyModel.objects.delete()` to `MyModel.objects.all().delete()`.
Currently a select set of StreamField blocks like PageChooserBlock
expose a bulk_to_python method that is used to optimize their
retrieval from the database. As reported in issue 5926, ListBlock could
take advantage of this so that its child items are loaded at once,
instead of one at a time.
This change modifies how ListBlock.to_python works so that it calls its
child block's bulk_to_python, if defined. This allows for a single query
instead of one query per child item.
Note that this change doesn't add bulk_to_python to ListBlock itself,
meaning that individual ListBlocks in a StreamField or StructBlock are
still retrieved independently. But it does optimize the lookup for each
ListBlock.
Image operations sometimes calculate a target width or height of zero, which
make Willow raise a ValueError.
If an user uploads one such image it's possible to break the whole Wagtail
image manager/picker/uploader for all users.
The fix is to use a minimum of 1 pixel for either the target height or the
width. The image might lose some aspect ratio, but it's better than an
exception.
* Implement MultipleChoiceBlock (squashed commits from #5592)
* Omit widget from frozen kwargs
* Rename get_callable_choices to indicate it is an internal method
* Add release notes for MultipleChoiceBlock
Currently it is possible to pass the target attribute to a button
created using ModelAdmin's ButtonHelper framework. This allows you to
generate button links like <a ... target="_blank">.
For example, if adding a new button and modeling it after the existing
edit_button code [0], you can add {'target': "_blank"} to the returned
dict and it'll get passed to the template when the button is rendered.
To be consistent with PR 4844, and to be consistent with what seems to
be the best practice ([1], [2]), we should also support passing the rel
attribute, which would allow for creation of button links like <a ...
target="_blank" rel="noopener noreferrer">.
[0] 5e2f50403b/wagtail/contrib/modeladmin/helpers/button.py (L61-L73)
[1] https://developers.google.com/web/tools/lighthouse/audits/noopener
[2] https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
Matt Westcott