Description

We ran into the problem that a search term (on a non-wagtail page model) was resulting in more than 100 results that could therefore not be fully displayed. The entry we wanted to find was not included in the 100 items and therefore the search (icontains-filter) was not prioritizing our expected result.

Suggestion

It would be great if one could implement a function like autocomplete_custom_queryset_filter in the model-to-search so that one can implement a different prioritization or improve the search in general as needed.

Add possibility for custom filter function #138

Since it is not possible to improve the search currently a check was implemented to look for a custom search function in the model to filter. If one is found it is called and the result is validated to be a queryset of the expected type.

Format code to full fill restrictions

Add documentation

Merge pull request #139 from simon-retsch/feature/138-add-possibility-to-replace-queryset-filter-with-custom-function

Feature/138 add possibility to replace queryset filter with custom function

Resolves https://github.com/wagtail/wagtail-autocomplete/issues/138

Updates copyright

Adds a11y-webring

I think I would propose having them as a selection on the existing page type. I think editors are already used to adding newsletter as blog pages, so I think keeping the same flow is good. In fact there is not much difference between the newsletter and current blog template. The only differences are:

• Blog posts show a "In the Database" section, and newsletter don't. But right now, even in Blog posts we are not showing that.
• The CTA for blog posts is "Return to Blog" and for Newsletter is "Donate"
• The treemap which I think we can do as a separate PR.
• CTAs on top to subscribe and to visit archives

So I think the architecture we can have is :

• [ ] Have 3 separate templates - _default_blog.html, _newsletter.html, _special_blog.html
• [ ] Have a dropdown in admin to select the type of blog: Default, Newsletter, Special
• [ ] Depending on the type selected by the editor, we chose in blog_page.html which of the 3 templates to include.
• [ ] Default Blog:
  • [ ] Add the "In the Database" section to show the 4 latest incidents. (We can probably also allow the editor to curate these 4 incidents based on the content of the blog? Not sure if that will be too much extra work for the editors)
• [ ] Newsletter:
  • [ ] Copy almost same structure as _default_blog
  • [ ] Replace "Return to Blog" CTA with "Donate" button
  • [ ] Add "Go to archived editions" and "Sign up to the newsletter" CTA before the blog details table
  • [ ] "Go to archived edition" button takes the user to the blog index page, filtered by type=newsletter
  • [ ] "Sign up to the newsletter" button takes users to the standalone newsletter page
• [ ] Special Blog
  • [ ] Copy the same structure as _default_blog apart from the header part
  • [ ] Use the lead_image for the blog as the hero image background.

Few questions that I have:

• Newsletters have right now don't have any headings or other structures much. In the design it's proposed a "Feedback & Your Support" section. Should I leave it to the editors to structure it that way in the newsletter body? Or should I enforce a separate section in the admin? In either case, there will be a little discrepancy between old newsletters and the new ones.
• The newsletter design has a "Read incidents" section in between the body. Not sure if we are to implement that and if anyone has any suggestions how. I could think of providing a separate block with incident choosers which the editors can then decide if they want and where they want.
• For the Special blog, I am little worried about the color contrast. Since the navigations are in black but the title of the blog and credits are in white, the image always needs to be of the format that the top of the image is light and bottom is dark. Else we will have a color contrast issue. I can add a black gradient to ensure the bottom is always darker, but still not sure with having the navigations in black.

cc @harrislapiroff

Describe the bug In the "Who we server" page, the images under the "Areas of focus" have placehold alt text and not proper alt text.

To Reproduce Steps to reproduce the behavior:

1. Go to https://scidsg.org/who-we-serve.html#users
2. Check the alt attribute of any of the images. They are all "Unless the image is decorative, add alt text."

Expected behavior Images should ideally have a proper alt text, i.e. "avatar representing a journalist", "avatar representing an activist". If we are not too sure about the text, we can just remove them so that the images are treated as decorative and removed from the accessibility DOM tree.

An accessibility statement helps in saying to the viewers that we care about accessibility and all our users. It also gives further information aout the standards that we are following, known accessiility issues we have and also a way for people to report any accessibility issues they find in our website.

Refs & examples:

• https://www.w3.org/WAI/planning/statements/
• https://www.a11yproject.com/accessibility-statement/
• https://wagtail.org/accessibility/

In some pages like teams page or who-we-serve page, we have multiple <nav> elements for multiple navigations. It's best practise that if there are multiple elements of the same landmark, then one should add an aria-label to denote what each of these landmarks mean. So i think we can just update the HTML to add aria-labels, e.g.:

• aria-label: "Main navigation" for the top navigation
• aria-label: "Page navigation" for the tabs pointing to different sections of the page (Can suggest some other text as well which is more meaningful maybe @glenn-sorrentino ?)

There are few items which I feel can benefit from better HTML tags. Ideally we can maybe update the CSS to be applied on tag instead of a class in the design system if there is a fixed style for the elements, but I don't mind keeping the designs in class instead of HTML tags. Some elements I noticed:

• [ ] Highlighted text: Let's use <mark> for anywhere we are using highlighted text.
• [ ] Striked out text: Let's use <s> for striked out text, e.g. prices
• [ ] <div role="main"> : Let's replace this with <main>

Usuall it's a good practise to add a skip-to-content link at the very beginning of the page that is visible only in tab-navigation. This allows keyboard users to skip the navigation links and jump to the content of the page. We don't have a super long list of navigation, so I won't say it's absolutely necessary, but still a good to have.

Implementation: https://css-tricks.com/how-to-create-a-skip-to-content-link/

role=button should be avoided as much as possible and instead the <button> tag should be used. It doesn't matter if a link aesthetically looks like a button. What really decides whether an interactive element is a button or a link is this:

• Does clicking on it take you to a different page, or a different view, or a different section of the same page? It's a Link
• Does clicking on it open a modal, switch a tab panel, toggle some item, open navigation in smaller screen? Basically it stays in the same page and doesn't go somewhere else. It's a Button

For example in the home page, all the "Learn More" links are given a role=button which is wrong since it goes to a separate page. So it's a link. We should remove all such role=button because it acts just like a <button> tag for assistive technology and confusing for users.

Refs: https://www.youtube.com/watch?v=8XjwDq9zG4I

Based on conversation below, the fix here is to get the dataset field to render a useful field error when set to "--------"

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/wagtail/admin/urls/__init__.py", line 170, in wrapper
    return view_func(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/wagtail/admin/auth.py", line 182, in decorated_view
    response = view_func(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/wagtail/admin/views/generic/preview.py", line 30, in dispatch
    return super().dispatch(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/views/generic/base.py", line 98, in dispatch
    return handler(request, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/wagtail/admin/views/generic/preview.py", line 74, in post
    is_valid = form.is_valid()
  File "/usr/local/lib/python3.9/site-packages/wagtail/admin/forms/pages.py", line 176, in is_valid
    return super().is_valid()
  File "/usr/local/lib/python3.9/site-packages/modelcluster/forms.py", line 344, in is_valid
    formsets_are_valid = all(formset.is_valid() for formset in self.formsets.values())
  File "/usr/local/lib/python3.9/site-packages/modelcluster/forms.py", line 344, in <genexpr>
    formsets_are_valid = all(formset.is_valid() for formset in self.formsets.values())
  File "/usr/local/lib/python3.9/site-packages/django/forms/formsets.py", line 321, in is_valid
    self.errors
  File "/usr/local/lib/python3.9/site-packages/django/forms/formsets.py", line 304, in errors
    self.full_clean()
  File "/usr/local/lib/python3.9/site-packages/django/forms/formsets.py", line 361, in full_clean
    form_errors = form.errors
  File "/usr/local/lib/python3.9/site-packages/django/forms/forms.py", line 170, in errors
    self.full_clean()
  File "/usr/local/lib/python3.9/site-packages/django/forms/forms.py", line 374, in full_clean
    self._post_clean()
  File "/usr/local/lib/python3.9/site-packages/django/forms/models.py", line 413, in _post_clean
    self.instance.full_clean(exclude=exclude, validate_unique=False)
  File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py", line 1236, in full_clean
    self.clean()
  File "/django/common/models/pages.py", line 249, in clean
    validate_dataset_params(self.dataset, self.params)
  File "/django/statistics/validators.py", line 22, in validate_dataset_params
    fn = NUMBERS[dataset]
KeyError: ''

The path was /admin/pages/4/edit/preview/

Page with id = 4 appears to be the Arrest category page.

Kibana

stats: Fix unhandled exception if validating missing dataset

1. Add a default value to the dataset choices field. I'm just using the first item in the choices list. This prevents choosing an empty dataset.

2. If validating a dataset that can't be located, raise a Validation Error, which will be handled by the wagtail admin.

Merge pull request #1572 from freedomofpress/handle-missing-dataset

Fix unhandled exception if validating missing dataset

Fixes #1571

1. Add a default value to the dataset choices field. I'm just using the first item in the choices list. This prevents choosing an empty dataset.

2. If validating a dataset that can't be located, raise a Validation Error, which will be handled by the wagtail admin.

Updates copyright year

Updates copyright years

It definitely should auto-connect. I verified that it is working in my Debian OS. I will test it out in windows and check if there is some bug.

Remove public autocomplete URLs

This functionality is part of the old site design and no longer needs to be exposed to the public.

Merge pull request #1569 from freedomofpress/remove-public-autocomplete

Remove public autocomplete URLs

Merge pull request #1570 from freedomofpress/develop

Deploy 2023.01.12