We don't really need its __iter__ implementation, but Django added a
check in
e4a2e22ddb
that requires ModelIterable to be used when using in_bulk() with
values() or values_list().
This template is useful for other page listings where we may also want
to enable bulk actions, e.g. the search view – and later, the workflows
usage view, as well as the page type usage view.
This is a separate commit just so git knows we're just renaming. We'll
reinstate the pages/index.html as a no-op extension of this
pages/listing.html template.
Now that the listing_results.html template supports rendering the "There
are x matches" message, we can enforce the consistency between the view
class and the template. Previously there were BaseListingView subclasses
(that are not IndexView subclasses) that used the index_results.html
template just to get that message when filtering.
- Use a single class with index_url_name, index_results_url_name,
template_name, and results_template_name
- Extend generic/listing.html and generic/listing_results.html templates
- Set page_title and header_icon to show breadcrumbs properly
- Set is_searchable = True and keep using the custom search and
filtering logic with the full get_queryset override to prevent scope
creep for now
This is now possible thanks to ViewSet.UNDEFINED. Previously, we would
be getting the unbound cached property instance from the view class,
only to pass it back to the view during as_view() – which results in a
broken state.
We want to remove all breadcrumbs_items check in the templates
eventually (as we want all listing views to use breadcrumbs). Instead of
having both BaseListingView's listing.html and IndexView's index.html
templates support the non-breadcrumbs case, do this only for the
index.html template.
The reasoning is because the BaseListingView was extracted more recently
as part of the Universal Listings work. When the filtering support was
moved from the IndexView to BaseListingView in 130c7ff, we still had to
support the non-breadcrumbs case due to the report views still using the
old filters implementation.
Now that we have migrated the report views to use the new AJAX-based
filtering, it's much less likely there's a BaseListingView subclass out
there that uses the non-breadcrumbs version. For such views, it's likely
they would work with IndexView too (as we haven't really documented
BaseListingView since its creation). So, put the interim support in the
IndexView template for now.
We could also completely drop the non-breadcrumbs case for both views,
but this would mean any custom listing view that uses filters now _must_
implement a results-only view _and_ enable breadcrumbs, or include the
filtering template themselves...
Add a base implementation of get_breadcrumbs_items() in BaseListingView
that uses the page_title and page_subtitle for the main breadcrumbs item
(the final, big one).
Then, remove the implementation in generic IndexView in favour of the base
one. Note that this changes the main breadcrumbs item label on IndexView
subclasses to prioritise the page_title attribute over the model's
verbose name plural.
This makes more sense – if you set page_title, you'd presumably want this
to be the one that shows up as the big title at the top too. This also
makes it consistent with how the <title> tag is generated. Previously,
they would go out of sync, as can be seen in Tasks and Users: the
breadcrumbs say 'Tasks' while the <title> tag says 'Workflow tasks', and
if a custom user model is used, the breadcrumbs say 'Custom user' while
the <title> tag only says Users.
---
Most of core views that extend from BaseListingView (including IndexView
subclasses) already use breadcrumbs at this point. Any custom listing
views, provided that they use the documented approaches, i.e.:
- ModelViewSet and SnippetViewSet index views
- Custom report views
- Custom form submission listing views
- Custom GroupViewSet and UserViewSet index views
also already use the breadcrumbs.
In core, the only BaseListingView subclass that doesn't yet use
breadcrumbs is the ContentTypeUseView (the "pages that use X type"
view). With this change, the view now nicely uses the breadcrumbs.
As for the generic/listing.html template, the only non-BaseListingView
view that uses it without breadcrumbs is the workflows usage view. It's
currently still a function-based view and the template overrides the
whole 'content' block, so it's unaffected.
Other than the above two, the only possible cases of a listing view that
doesn't use breadcrumbs in Wagtail core mean that they are:
- not a BaseListingView subclass, or
- not using a template that extends generic/listing.html
For code outside of Wagtail core, the only likely possibilities of a listing
view without breadcrumbs that would be affected by this change are:
- if a BaseListingView or IndexView subclass is registered directly (without
being part of the above viewsets). In this case, they can set
_show_breadcrumbs to False to undo the effect (but they really shouldn't).
- if the _show_breadcrumbs flag is already set to False on the view class
or via the viewset. In this case, they won't be affected by the change.
For both cases, instead of setting _show_breadcrumbs to False
(essentially ignoring any problems), they should start looking into
fixing any issues they find with the breadcrumbs (if any – there likely
isn't).
We are planning to enforce breadcrumbs everywhere, so eventually we'll
drop the _show_breadcrumbs flag altogether. This commit starts from the
listing views, by setting it to True directly on the BaseListingView
instead of the subclasses.
- Create a deploy section of the documentation
- Move fly.io deployment from tutorial to it's own page under deploy
- Clean up deployment docs and references throughout documentation
The patch for filesizeformat in particular is quite heavyweight, and we don't want our CI to never test against the real version (for example, if it changes in a future Django release).
Address bugs caused by the `USE_THOUSAND_SEPARATOR=True` setting inserting commas where they are invalid, such as image width/height attributes. All numbers output on templates are now passed through one of `|unlocalize` (for numbers that must never have separators), `|intcomma` (for numbers displayed to users which should always include separators) or `|localize` (for when the choice is delegated to the project-wide setting).
This helps protect the secret key by using a smaller digest, ensuring the previously-discarded data is included in the output hash. Using a salt and personalization also goes to further obscure the values.
Sage Abdullah