internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: wagtail/wagtail

Issue:
Refactor Avatar styles into UI component
We currently have an "avatar" component as reusable CSS styles that are copy-pasted with the relevant HTML across the admin. This feels like a good candidate to refactor to a UI component:

- [ ] With a template partial in the `shared` folder for us to `{% include %}` where needed
- [ ] With Storybook stories for different variations of that component
- [ ] Refactoring some of the current usage to that template partial as appropriate
- [ ] In particular, updating the styleguide to use the template partial.

This shouldn’t change the component’s rendering in any way, just how it’s included in different places (and introduce a way for us to test the variations more easily in Storybook).


Discussion:
Update: Ignore this - ~~While we are at it. It would be good adopt `w-avatar` as the class and adopt BEM classes if needed.~~

There is also this PR that would be good to get merged in before any refactoring of styles. https://github.com/wagtail/wagtail/pull/8521

Finally, the styles should move from scss/objects to scss/components as this is not really an object in the ITCSS framework 
@lb- Steve is only meant to help with our usage of Storybook for the time being so I’ve told him not to attempt any CSS refactorings – it’s beyond what he has time for, and will also make any changes trickier for me to review.
I was able to reproduce this and figure out what's happening 
I'm currently on this issue.
@stevedya if it's ok - I'll un-assign you for now - Thibaud let me know if that's an issue. 
should i pick this one too ? since i have already worked  with https://github.com/wagtail/wagtail/issues/8656 status tags 
Go for it @salty-ivy

Resolving patch:
diff --git a/wagtail/admin/templatetags/wagtailadmin_tags.py b/wagtail/admin/templatetags/wagtailadmin_tags.py
--- a/wagtail/admin/templatetags/wagtailadmin_tags.py
+++ b/wagtail/admin/templatetags/wagtailadmin_tags.py
@@ -589,6 +589,22 @@ def bulk_action_choices(context, app_label, model_name):
     return {"buttons": bulk_action_buttons}
 
 
+@register.inclusion_tag("wagtailadmin/shared/avatar.html")
+def avatar(user=None, classname=None, size=None, tooltip=None):
+    """
+    Displays a user avatar using the avatar template
+    Usage:
+    {% load wagtailadmin_tags %}
+    ...
+    {% avatar user=request.user size='small' tooltip='JaneDoe' %}
+    :param user: the user to get avatar information from (User)
+    :param size: default None (None|'small'|'large'|'square')
+    :param tooltip: Optional tooltip to display under the avatar (string)
+    :return: Rendered template snippet
+    """
+    return {"user": user, "classname": classname, "size": size, "tooltip": tooltip}
+
+
 @register.simple_tag
 def message_level_tag(message):
     """


Test patch:
Repository: wagtail/wagtail

Issue:
Update djhtml to support Stimulus `data-action` attributes
### Is your proposal related to a problem?

Using `click->` caused the HTML formatter to cause issues.

```
<a class="skiplink button" href="#main" data-controller="w-skip-link" data-action="click->w-skip-link#skip">{% trans 'Skip to main content' %}</a>
```

The formatter has a problem with `>` in HTML attributes.

### Describe the solution you'd like

Upgrading dhtml should solve this https://github.com/rtts/djhtml/issues/57

### Describe alternatives you've considered

We can use `verbatim` as a work around for now.

Using the shorthand version did not make the formatter freak out https://stimulus.hotwired.dev/reference/actions#event-shorthand

```
<a class="skiplink button" href="#main" data-controller="w-skip-link" data-action="w-skip-link#skip">{% trans 'Skip to main content' %}</a>
```


### Additional context

* https://github.com/wagtail/wagtail/pull/9818#discussion_r1066393372
* _Originally posted by @lb- in https://github.com/wagtail/wagtail/pull/9952#discussion_r1085993495_
* https://github.com/rtts/djhtml/issues/57


Discussion:
@Lovelyfin00  this should be simply a matter of updating the reference in `setup.py`

https://github.com/wagtail/wagtail/blob/main/setup.py#L68

From `"djhtml==1.4.13",` to "djhtml==1.5.2",`
Great thanks 
Will do that👍
Loveth - once updated locally, you will need to do a pip install again and then also run the formatter - there may be some subtle changes to the existing formatting from the new version.

Also see the actual fix that was put into the library for reference https://github.com/rtts/djhtml/pull/62

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -65,7 +65,7 @@
     # For templates linting
     "curlylint==0.13.1",
     # For template indenting
-    "djhtml==1.4.13",
+    "djhtml==1.5.2",
     # for validating string formats in .po translation files
     "polib>=1.1,<2.0",
     # For streamfield migration toolkit


Test patch:
Repository: wagtail/wagtail

Issue:
Tests fail against Django's `main` (5.0) branch
<!--
Found a bug? Please fill out the sections below. 👍
-->

### Issue Summary

Our tests seem to fail against Django's `main` branch with `AttributeError: 'IndexView' object has no attribute 'add_facets'` as of a few days ago.

Possible cause: https://github.com/django/django/pull/16495

Will investigate later.


Discussion:

Resolving patch:
diff --git a/wagtail/contrib/modeladmin/views.py b/wagtail/contrib/modeladmin/views.py
--- a/wagtail/contrib/modeladmin/views.py
+++ b/wagtail/contrib/modeladmin/views.py
@@ -316,6 +316,10 @@ class IndexView(SpreadsheetExportMixin, WMABaseView):
     # template tag - see https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.sortable_by
     sortable_by = None
 
+    # add_facets is required by the django.contrib.admin.filters.ListFilter.choices method
+    # as of Django 5.0 - see https://github.com/django/django/pull/16495
+    add_facets = False
+
     @method_decorator(login_required)
     def dispatch(self, request, *args, **kwargs):
         # Only continue if logged in user has list permission


Test patch:
Repository: wagtail/wagtail

Issue:
Make Wagtail’s icon set easier to browse
The nitpicking of the day :) :)

When using wagtail.contrib.styleguide I mostly use it to see the icons that are availalble. I think that is for most developers.
However the icons are at the bottom of the page. Maybe as a very small improvement this is better placed at the top.



Discussion:
Hey @onno-timmerman, I like this suggestion. Alternatively we’ve been wondering whether it would be better to have the icons directly in the Wagtail docs: https://github.com/wagtail/wagtail/pull/6028#discussion_r590144224

Do you think that would work well / better?
yes absolute in docs so you can refrence to them
For anyone interested in this – I’ll be working on this in a couple of weeks. I’m leaning towards adding all the icons to `docs.wagtail.org`, so I’ll try this first.

Resolving patch:
diff --git a/wagtail/contrib/styleguide/views.py b/wagtail/contrib/styleguide/views.py
--- a/wagtail/contrib/styleguide/views.py
+++ b/wagtail/contrib/styleguide/views.py
@@ -1,8 +1,15 @@
+import itertools
+import os
+import re
+from collections import defaultdict
+
 from django import forms
 from django.core.paginator import Paginator
+from django.template.loader import render_to_string
 from django.template.response import TemplateResponse
 from django.utils.translation import gettext as _
 
+from wagtail import hooks
 from wagtail.admin import messages
 from wagtail.admin.forms.search import SearchForm
 from wagtail.admin.rich_text import get_rich_text_editor_widget
@@ -84,6 +91,9 @@ def __init__(self, *args, **kwargs):
     snippet_chooser = forms.BooleanField(required=True)
 
 
+icon_id_pattern = re.compile(r"id=\"icon-([a-z0-9-]+)\"")
+
+
 def index(request):
 
     form = SearchForm(placeholder=_("Search something"))
@@ -109,10 +119,28 @@ def index(request):
     paginator = Paginator(list(range(100)), 10)
     page = paginator.page(2)
 
+    icon_hooks = hooks.get_hooks("register_icons")
+    registered_icons = itertools.chain.from_iterable(hook([]) for hook in icon_hooks)
+    all_icons = defaultdict(list)
+    for icon_path in registered_icons:
+        source, filename = os.path.split(icon_path)
+        icon = render_to_string(icon_path)
+        id_match = icon_id_pattern.search(icon)
+
+        all_icons[source].append(
+            {
+                "source": source,
+                "file_path": icon_path,
+                "id": id_match.group(1) if id_match else None,
+                "icon": icon,
+            }
+        )
+
     return TemplateResponse(
         request,
         "wagtailstyleguide/base.html",
         {
+            "all_icons": all_icons.items(),
             "search_form": form,
             "example_form": example_form,
             "example_page": page,


Test patch:
Repository: wagtail/wagtail

Issue:
Add support for Pillow 10.0.0
### Is your proposal related to a problem?

Pillow 10.0.0 [has just been released.](https://github.com/python-pillow/Pillow/releases/tag/10.0.0) Wagtail 5.0.2 [restricts Pillow support to <10.0.0.](https://github.com/wagtail/wagtail/blob/a68f69f2d7f46943cc23b7f65349448b23044869/setup.py#L30)

Adding support for the new Pillow release is desired.

### Describe the solution you'd like

Add support for Pillow 10.0.0


### Describe alternatives you've considered

Not applicable.

### Additional context

This is a relevant dependency to the project, and to sites running it.



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -27,7 +27,7 @@
     "djangorestframework>=3.11.1,<4.0",
     "django-filter>=2.2,<24",
     "draftjs_exporter>=2.1.5,<3.0",
-    "Pillow>=4.0.0,<10.0.0",
+    "Pillow>=9.1.0,<11.0.0",
     "beautifulsoup4>=4.8,<4.12",
     "html5lib>=0.999,<2",
     "Willow>=1.5,<1.6",


Test patch:
Repository: wagtail/wagtail

Issue:
{% page_header_buttons %} crashes when used due to typo in the first line
### Issue Summary

The `{% page_header_buttons %}` template tag from `wagtailadmin_tags` crashes when used.

### Steps to Reproduce

1. Put `{% page_header_buttons None None %}` anywhere in a template that includes `{% load wagtailadmin_tags %}`. Any other arguments work, too, as the crash happens before they get used.

-   I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

### Technical details

The problem is that the first line of code is 
```
    next_url = context.request.path
```
It should instead be:
```
    next_url = context["request"].path
```

@gasman fixed a similar issue with the `{% page_listing_buttons %}` template tag last month, as part of #10592.

I submitted #10731 as a fix.


Discussion:

Resolving patch:
diff --git a/wagtail/admin/templatetags/wagtailadmin_tags.py b/wagtail/admin/templatetags/wagtailadmin_tags.py
--- a/wagtail/admin/templatetags/wagtailadmin_tags.py
+++ b/wagtail/admin/templatetags/wagtailadmin_tags.py
@@ -473,7 +473,7 @@ def page_listing_buttons(context, page, page_perms):
     "wagtailadmin/pages/listing/_page_header_buttons.html", takes_context=True
 )
 def page_header_buttons(context, page, page_perms):
-    next_url = context.request.path
+    next_url = context["request"].path
     button_hooks = hooks.get_hooks("register_page_header_buttons")
 
     buttons = []


Test patch:
Repository: wagtail/wagtail

Issue:
FieldPanel with read_only=True does not work for a choice field whose labels are translatable
### Issue Summary

`FieldPanel('myfield', read_only=True)` does not work for a choice field whose labels are translatable (using `gettext_lazy`)

### Steps to Reproduce

1. Create a model containing a CharField using translatable choices:

```python

AUDIENCE_CHOICES = (
    ("public", _("Public")),
    ("private", _("Private")),
)

class Event(model.Model):
    
    audience = models.CharField(
        max_length=255,
        choices=AUDIENCE_CHOICES,
        editable=False
    )
        
    edit_handler = MultiFieldPanel(
        [
            FieldPanel("audience", read_only=True)
        ]
    )
```
2. Make the appropriate migration and migrate your instance
3. Open the edit form of your Event model in the admin of Wagtail

Here is the end of the traceback you will obtain:

```console
  File "/home/florent/dev/wagtail-raw/wagtail/wagtail/admin/panels/field_panel.py", line 120, in format_value_for_display
    return ", ".join(display_values)
TypeError: sequence item 0: expected str instance, __proxy__ found
```

-   I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

### Technical details

-   Python version: 3.10.12
-   Django version: 4.0.10 and 4.2.3
-   Wagtail version: 5.1

Here is a simple diff that makes the unit test `wagtail.admin.tests.test_edit_handlers.TestFieldPanel.test_format_value_for_display_with_choicefield` fail with the same error:

```diff
diff --git a/wagtail/test/testapp/models.py b/wagtail/test/testapp/models.py
index 63c4840..debf5e8 100644
--- a/wagtail/test/testapp/models.py
+++ b/wagtail/test/testapp/models.py
@@ -81,8 +81,8 @@ from wagtail.snippets.models import register_snippet
 from .forms import FormClassAdditionalFieldPageForm, ValidatedPageForm
 
 EVENT_AUDIENCE_CHOICES = (
-    ("public", "Public"),
-    ("private", "Private"),
+    ("public", _("Public")),
+    ("private", _("Private")),
 )
```




Discussion:

Resolving patch:
diff --git a/wagtail/admin/panels/field_panel.py b/wagtail/admin/panels/field_panel.py
--- a/wagtail/admin/panels/field_panel.py
+++ b/wagtail/admin/panels/field_panel.py
@@ -109,7 +109,7 @@ def format_value_for_display(self, value):
         if not isinstance(choices, ModelChoiceIterator) and choices:
             labels = dict(choices)
             display_values = [
-                labels.get(v, v)  # Use raw value if no match found
+                str(labels.get(v, v))  # Use raw value if no match found
                 for v in (
                     # Account for single AND multiple choice fields
                     tuple(value)


Test patch:
diff --git a/wagtail/test/testapp/models.py b/wagtail/test/testapp/models.py
--- a/wagtail/test/testapp/models.py
+++ b/wagtail/test/testapp/models.py
@@ -81,8 +81,8 @@
 from .forms import FormClassAdditionalFieldPageForm, ValidatedPageForm
 
 EVENT_AUDIENCE_CHOICES = (
-    ("public", "Public"),
-    ("private", "Private"),
+    ("public", _("Public")),
+    ("private", _("Private")),
 )
Repository: wagtail/wagtail

Issue:
Collection title is not interpolated into success_message
When I delete a collection, the "success message" does not have the name of the collection in the message. Instead it has the string with the python formatting markup still in it. I found this in a project running 5.1.1 but have not verified it on a new project or a new project running off the current main branch. 

![Screenshot 2023-08-22 at 11 52 39 AM](https://github.com/wagtail/wagtail/assets/5952/0bcc395a-9c94-40ab-a003-a7617dee37e3)


For folks looking for a good first issue, the first step should be to verify this problem in a fresh dev setup. 



Discussion:

Resolving patch:
diff --git a/wagtail/admin/views/collections.py b/wagtail/admin/views/collections.py
--- a/wagtail/admin/views/collections.py
+++ b/wagtail/admin/views/collections.py
@@ -182,6 +182,6 @@ def post(self, request, pk):
             # collection is non-empty; refuse to delete it
             return HttpResponseForbidden()
 
+        messages.success(request, self.get_success_message())
         self.object.delete()
-        messages.success(request, self.success_message.format(self.object))
         return redirect(self.index_url_name)


Test patch:
diff --git a/wagtail/admin/tests/test_collections_views.py b/wagtail/admin/tests/test_collections_views.py
--- a/wagtail/admin/tests/test_collections_views.py
+++ b/wagtail/admin/tests/test_collections_views.py
@@ -600,6 +600,12 @@ def test_post(self):
         # Should redirect back to index
         self.assertRedirects(response, reverse("wagtailadmin_collections:index"))
 
+        # Check the message content
+        self.assertEqual(
+            response.context["message"],
+            "Collection 'Holiday snaps' deleted.",
+        )
+
         # Check that the collection was deleted
         with self.assertRaises(Collection.DoesNotExist):
             Collection.objects.get(id=self.collection.id)
Repository: wagtail/wagtail

Issue:
Spotify oembed request gets 308 redirect response, and does not follow redirect
<!--
Found a bug? Please fill out the sections below. 👍
-->

### Issue Summary

When you try and embed a spotify URL, urllib gets a 308 response from spotify and raises an exception.
<!--
A summary of the issue.
-->

### Steps to Reproduce

1. try and embed a spotify URL, for example https://open.spotify.com/playlist/37i9dQZF1DWUZ5bk6qqDSy
2. a validation error occurs ("Cannot find an embed for this URL.")

By looking at the response body, I have found that it could be fixed by removing the trailing slash in the oembed spotify definition. 

So adding this workaround to my settings fixes it for me:

```python
_spotify = {
    # Only change: removed trailing slash (was "https://embed.spotify.com/oembed/"):
    "endpoint": "https://embed.spotify.com/oembed",
    "urls": [
        r"^https?://open\.spotify\.com/.+$",
        r"^https?://spoti\.fi/.+$",
    ],
}

WAGTAILEMBEDS_FINDERS = [
    {
        'class': 'wagtail.embeds.finders.oembed',
        'providers': [_spotify],
    },
    {
        'class': 'wagtail.embeds.finders.oembed',
    }
]
```

I can make a PR for this if that would be useful.

The other way you could fix this is by making it follow redirects when trying to do an embed, I suppose.

### Technical details

-   Python version: 3.10.8
-   Django version: 4.2.3
-   Wagtail version: 5.0.2



Discussion:
A PR would be great, thank you. 
Can confirm this issue exists

<img width="1181" alt="Screenshot 2023-09-26 at 5 34 28 am" src="https://github.com/wagtail/wagtail/assets/1396140/383ec33a-c28b-4a5d-a2ac-6565005a2d1a">


 Flagging as a good first issue as this should be a small change `wagtail/embeds/oembed_providers.py` update required as noted. Once the trailing slash is removed it works (screenshot below).

<img width="1240" alt="Screenshot 2023-09-26 at 5 35 15 am" src="https://github.com/wagtail/wagtail/assets/1396140/a07f750c-c771-4b4a-9868-743214f12abe">

I would like to work on this!
Go for it @rohitsrma 

Resolving patch:
diff --git a/wagtail/embeds/oembed_providers.py b/wagtail/embeds/oembed_providers.py
--- a/wagtail/embeds/oembed_providers.py
+++ b/wagtail/embeds/oembed_providers.py
@@ -520,7 +520,7 @@
 
 
 spotify = {
-    "endpoint": "https://embed.spotify.com/oembed/",
+    "endpoint": "https://open.spotify.com/oembed",
     "urls": [
         r"^https?://open\.spotify\.com/.+$",
         r"^https?://spoti\.fi/.+$",


Test patch:
Repository: wagtail/wagtail

Issue:
SetActiveStateBulkAction is missing translatable label
### Issue Summary

"Mark as active" is not translated when using this bulk action

More technically: the `mark_as_active` field is missing an explicit label in `ActivityForm`, it is generated from its name, hence not translated


### Steps to Reproduce

1. Configure your wagtail site into a fully translated language
2. Go to users list and create one
3. Check it and use the "Set active state" button
4. The form presented has a radio field which is not translated


Discussion:
Can confirm this issue (ignore my initial deleted comment, I was looking at the wrong thing).

<img width="1425" alt="Screenshot 2023-09-29 at 7 19 39 am" src="https://github.com/wagtail/wagtail/assets/1396140/ece461d2-9c20-4351-a37e-81800e576fba">

Flagging this as a good first issue, should just be a matter of adding a form label here https://github.com/wagtail/wagtail/blob/main/wagtail/users/views/bulk_actions/set_active_state.py#L11

```diff
class ActivityForm(forms.Form):
    mark_as_active = forms.TypedChoiceField(
        choices=((True, _("Active")), (False, _("Inactive"))),
+++     label=_("Mark as active"),
        widget=forms.RadioSelect,
        coerce=lambda x: x == "True",
    )
```

Hi @lb-  I'm interested in working on this issue and making the label translateable. To achieve this, should i use the ``{% trans %}`` tag. 

Could you please point me to any other file in the project where a similar approach has been used for translating labels? This would help me better understand the existing conventions and ensure consistency in my implementation. 

Looking forward to your guidance! 🚀
@rohitsrma as @lb- stated, `_("Mark as active")` is sufficient, it is aliased to `gettext_lazy` and will be picked up by `./manage.py makemessages`
You can read more about how these translation utils work here. 
https://docs.djangoproject.com/en/4.2/topics/i18n/translation/#standard-translation

And about form labels here https://docs.djangoproject.com/en/4.2/ref/forms/fields/#label

Resolving patch:
diff --git a/wagtail/users/views/bulk_actions/set_active_state.py b/wagtail/users/views/bulk_actions/set_active_state.py
--- a/wagtail/users/views/bulk_actions/set_active_state.py
+++ b/wagtail/users/views/bulk_actions/set_active_state.py
@@ -9,6 +9,7 @@
 class ActivityForm(forms.Form):
     mark_as_active = forms.TypedChoiceField(
         choices=((True, _("Active")), (False, _("Inactive"))),
+        label=_("Mark as active"),
         widget=forms.RadioSelect,
         coerce=lambda x: x == "True",
     )


Test patch: