This documentation change clarifies that MultipleChooserPanel can only
be used when the inline model has a ForeignKey to a model that
implements Wagtail's chooser interface. Currently the docs mention
"a chooser for a ForeignKey relation" but it's not obvious how that
restricts which models can be pointed to or how to implement this for a
non-(image, document, snippet, page) model.
Relates to #10646.
It is only shown for screen readers, which is inconsistent with the actual visible text.
It also makes the captions unnecessarily verbose, as the dimensions info is not very useful in the image listings
To safely handle non-integer primary keys. This is mostly useful for
snippets, but do it everywhere for consistency and in case of custom
document and image models.
If the aria-label is too specific, e.g. 'Select page', 'Select document'
(and in the case of images it's 'Select image <image title> <image
dimensions>), it is hard for voice control users to click on the
checkbox because they have to specify the full label.
Instead, enforce a simple 'Select' aria-label and use aria-describedby
to describe the checkbox by referring to the title in the title column.
This ensures that people upgrading to Django 5.0 will have a compatible version. Now that Python <3.8 and Django <3.2 are EOL, there's no reason for anyone to be running an older version.
At this point wagtailadmin/shared/field.html is still used by FieldPanel, as well as third-party code. Replace this by a template that simply pulls the relevant context variables from the template and passes them on to `{% formattedfield %}` (which renders them using the old template, now renamed formatted_field.html). This will allow us to move logic from the template to the tag function without breaking the existing wagtailadmin/shared/field.html API.
This distinguishes the use case of wrapping form fields that are defined manually in HTML, versus working with Django form field objects which will shortly be given a `formattedfield` tag. We could have called these `rawfield` and `field`, but this avoids weirdness like `{% field field=field %}` (or just `{% field %}` which can easily be confused with `{{ field }}`) and better clarifies the purpose of the tag (and in particular why you shouldn't use it for hidden fields).
Previously, the locale will be set even if the view doesn't set a model
attribute. This means that it will load the default locale or the locale
specified by the query param.
However, in practice, this mixin is typically used for views that work
with a translatable model.
Setting the locale when the view doesn't set a model will still cause a
query to get the locale. Since it's unlikely that the view actually
needs to work with a locale if it doesn't set a model, just drop the
support for it so we can eliminate that extra query.
The model_opts is already supplied by generic
IndexView.get_context_data(), and can_add_snippet is already covered by
the can_add context variable in the generic view. For the template, the
only differences are:
- the title tag no longer says 'Snippet <model name>' and instead only
says '<model name>'
- the body class for the model has been removed
The base_actions was added in 252c4015a0
for the sole purpose of fixing the position of the locale switcher on
snippets index view.
With the upcoming Universal Listings work, all of the actions and
filters will likely be moved to the slim header (breadcrumbs), so this
will be eliminated anyway. However, doing this allows us to refactor the
snippets index view to reuse as much of the generic index view code and
template as possible (see next commit).
Reduce template overrides and make it more consistent with the page
listing header, including using
PagePermissionTester.can_view_revisions() when rendering the link.
When the history button is turned into a proper side panel, we can
refactor this further.
The is_root check for the side panels is moved to the view code. For the
"Live" link, the check is already covered by the
page_status_tag_new.html template that checks for page.live and
page.url.
This allows the more "adventurous" to update their requirements so they
can install the next latest Django version (5.1 and 5.2) even if we
haven't officially supported it. As long as we're on top of Django's
updates, this should be OK for the duration of this Wagtail release's
active support period.
However, do not update the default project template's requirements yet,
since we don't want new projects to be installed with Django versions we
haven't officially supported.
