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

Issue:
Site history displays "Draft saved" for saved snippets
### Issue Summary

The 2.15rc has audit logging for all models.

When a snippet is saved, it displays "Draft saved" in site history. Should be "Saved", as snippets does not have a workflow and thus does not have a 'draft' state.

### Steps to Reproduce

1. Use Wagtail 2.15rc and bakerydemo
2. Edit a snippet. Eg: http://127.0.0.1:8000/admin/breads/breadtype/edit/15/
3. Go to Site history at http://127.0.0.1:8000/admin/reports/site-history/
4. It reads: "Draft saved", expects "Saved". 

* I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: Yes

### Technical details

* Python version: Python 3.9.7
* Django version: Django==3.2.8
* Wagtail version: 2.15rc


Discussion:

Resolving patch:
diff --git a/wagtail/core/models/__init__.py b/wagtail/core/models/__init__.py
--- a/wagtail/core/models/__init__.py
+++ b/wagtail/core/models/__init__.py
@@ -4063,6 +4063,14 @@ def __str__(self):
     def object_id(self):
         return self.page_id
 
+    @cached_property
+    def message(self):
+        # for page log entries, the 'edit' action should show as 'Draft saved'
+        if self.action == 'wagtail.edit':
+            return _("Draft saved")
+        else:
+            return super().message
+
 
 class Comment(ClusterableModel):
     """
diff --git a/wagtail/core/wagtail_hooks.py b/wagtail/core/wagtail_hooks.py
--- a/wagtail/core/wagtail_hooks.py
+++ b/wagtail/core/wagtail_hooks.py
@@ -97,7 +97,7 @@ def register_core_log_actions(actions):
     actions.register_model(Page, PageLogEntry)
 
     actions.register_action('wagtail.create', _('Create'), _('Created'))
-    actions.register_action('wagtail.edit', _('Save draft'), _('Draft saved'))
+    actions.register_action('wagtail.edit', _('Edit'), _('Edited'))
     actions.register_action('wagtail.delete', _('Delete'), _('Deleted'))
     actions.register_action('wagtail.publish', _('Publish'), _('Published'))
     actions.register_action('wagtail.publish.scheduled', _("Publish scheduled draft"), _('Published scheduled draft'))


Test patch:
Repository: wagtail/wagtail

Issue:
Stray checkbox on locked pages report
### Issue Summary

The Locked Pages report (and possibly others inheriting from PageReportView) has a stray additional column with a checkbox, presumably from the bulk actions feature, which causes the column headings to get out of step:

![Screenshot 2021-11-04 at 14 38 33](https://user-images.githubusercontent.com/85097/140334621-38a41691-f20d-48b5-b38c-3d2d7ed69519.png)

Thanks to @Tijani-Dia for reporting.

### Steps to Reproduce

1. Start a new project with `wagtail start myproject` / `./manage.py migrate` / `./manage.py createsuperuser`
2. Log in, edit the homepage, select 'Lock' from the action menu
3. Go to Reports -> Locked pages

* I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes


### Technical details

* Python version: 3.8.0
* Django version: 3.2.8
* Wagtail version: 2.15
* Browser version: Chrome 95.0.4638.54



Discussion:
Hi, I made a PR for this in #7687. Let me know if there are any other changes needed. Thanks!

Resolving patch:
diff --git a/wagtail/admin/views/pages/listing.py b/wagtail/admin/views/pages/listing.py
--- a/wagtail/admin/views/pages/listing.py
+++ b/wagtail/admin/views/pages/listing.py
@@ -95,6 +95,8 @@ def index(request, parent_page_id=None):
         paginator = Paginator(pages, per_page=50)
         pages = paginator.get_page(request.GET.get('p'))
 
+    show_ordering_column = request.GET.get('ordering') == 'ord'
+
     context = {
         'parent_page': parent_page.specific,
         'ordering': ordering,
@@ -103,7 +105,8 @@ def index(request, parent_page_id=None):
         'do_paginate': do_paginate,
         'locale': None,
         'translations': [],
-        'show_ordering_column': request.GET.get('ordering') == 'ord'
+        'show_ordering_column': show_ordering_column,
+        'show_bulk_actions': not show_ordering_column,
     }
 
     if getattr(settings, 'WAGTAIL_I18N_ENABLED', False) and not parent_page.is_root():


Test patch:
Repository: wagtail/wagtail

Issue:
Slim sidebar always showing scrollbars
On Wagtail 2.15.1, with Firefox 93, scrollbars are always showing on the slim sidebar, causing the logo to be clipped:

![image](https://user-images.githubusercontent.com/1093808/144216312-86e761d0-5813-410b-956f-e88da39cabab.png)
Slim sidebar always showing scrollbars
On Wagtail 2.15.1, with Firefox 93, scrollbars are always showing on the slim sidebar, causing the logo to be clipped:

![image](https://user-images.githubusercontent.com/1093808/144216312-86e761d0-5813-410b-956f-e88da39cabab.png)


Discussion:

Resolving patch:
diff --git a/wagtail/admin/ui/sidebar.py b/wagtail/admin/ui/sidebar.py
--- a/wagtail/admin/ui/sidebar.py
+++ b/wagtail/admin/ui/sidebar.py
@@ -123,19 +123,6 @@ def js_args(self):
         ]
 
 
-@adapter('wagtail.sidebar.CustomBrandingModule', base=BaseSidebarAdapter)
-class CustomBrandingModule:
-    def __init__(self, html, collapsible=False):
-        self.html = html
-        self.collapsible = collapsible
-
-    def js_args(self):
-        return [
-            self.html,
-            self.collapsible,
-        ]
-
-
 @adapter('wagtail.sidebar.SearchModule', base=BaseSidebarAdapter)
 class SearchModule:
     def __init__(self, search_area):


Test patch:
diff --git a/wagtail/admin/tests/ui/test_sidebar.py b/wagtail/admin/tests/ui/test_sidebar.py
--- a/wagtail/admin/tests/ui/test_sidebar.py
+++ b/wagtail/admin/tests/ui/test_sidebar.py
@@ -5,8 +5,8 @@
 
 from wagtail.admin.search import SearchArea
 from wagtail.admin.ui.sidebar import (
-    CustomBrandingModule, LinkMenuItem, MainMenuModule, PageExplorerMenuItem, SearchModule,
-    SubMenuItem, WagtailBrandingModule)
+    LinkMenuItem, MainMenuModule, PageExplorerMenuItem, SearchModule, SubMenuItem,
+    WagtailBrandingModule)
 from wagtail.core.telepath import JSContext
 from wagtail.tests.utils import WagtailTestUtils
 
@@ -150,30 +150,6 @@ def test_adapt(self):
         })
 
 
-class TestAdaptCustomBrandingModule(TestCase):
-    def test_adapt(self):
-        packed = JSContext().pack(CustomBrandingModule('<h1>My custom branding</h1>'))
-
-        self.assertEqual(packed, {
-            '_type': 'wagtail.sidebar.CustomBrandingModule',
-            '_args': [
-                '<h1>My custom branding</h1>',
-                False
-            ]
-        })
-
-    def test_collapsible(self):
-        packed = JSContext().pack(CustomBrandingModule('<h1>My custom branding</h1>', collapsible=True))
-
-        self.assertEqual(packed, {
-            '_type': 'wagtail.sidebar.CustomBrandingModule',
-            '_args': [
-                '<h1>My custom branding</h1>',
-                True
-            ]
-        })
-
-
 class TestAdaptSearchModule(TestCase):
     def test_adapt(self):
         packed = JSContext().pack(SearchModule(SearchArea("Search", '/search/')))
Repository: wagtail/wagtail

Issue:
Add banner to docs (for Wagtail Space or in general)
We want to add a banner to the docs to advertise Wagtail Space. 

We're referencing #4986, and we could just do the same as it, but for the upcoming Wagtail Space. One potential difficulty is getting it into a tag that will show in the stable version of the docs.

Another option would be to add a banner page to [wagtail.io](https://wagtail.io/) or some other place we can update without a PR, and have the docs pull that banner if it exists. This would allow us to update the banner without having to put in a PR to Wagtail core, and more importantly would mean that going forward, changing that banner would change it for all versions of the docs from now on. I'm not sure what pitfalls this might have around cross origin or caching, which could be considerations for this option.

@vsalvino has offered to do some looking into this!


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -309,7 +309,6 @@
 
 
 def setup(app):
-    app.add_css_file('css/custom.css')
     app.add_js_file('js/banner.js')
 
     github_doc_root = 'https://github.com/wagtail/wagtail/tree/main/docs/'


Test patch:
Repository: wagtail/wagtail

Issue:
Add support for Pinterest embeds
Hi everybody , i want to embed url of pinterest , but in oembed.py file don't have for pinterest,
May someone help me , thank you
I started issue in stackoverflow
https://stackoverflow.com/questions/57182566/how-to-embed-pinterest-link-to-wagtail?noredirect=1#comment100969146_57182566


Discussion:
Hello @ozanteoman,

Pinterest does support oembed. So this is possible.
https://developers.pinterest.com/docs/rich-pins/products/

You are correct, Wagtail does not have Pinterest oembed support by default.
https://github.com/wagtail/wagtail/blob/master/wagtail/embeds/oembed_providers.py#L645-L658

Does Embedly have Pinterest? You can use Embedly as provider.
https://docs.wagtail.io/en/v2.6/advanced_topics/embeds.html#embed-ly

You can also specify your own custom oembed finder and work with any oembed provider you like. See the Wagtail docs:
https://docs.wagtail.io/en/v2.6/advanced_topics/embeds.html#custom-embed-finder-classes

Note that Github issues are for development of Wagtail. Asking support can be done via other channels, [like pointed out before](https://github.com/wagtail/wagtail/issues/5450).

Since Wagtail is open source we are happy to accept pull requests to add Pinterest support.
Reopening this as a feature request ticket.
I'm poking around looking for easy issues on account of Hacktoberfest, and wanted to correct a comment earlier in this thread - Pinterest isn't, as far as I can tell, an oEmbed *provider* -- they're an oEmbed *consumer* for the purposes of creating Rich Pins within their site. So, I'm not sure if there's any path to add this without a parser just for Pinterest, which is a whole other can of worms.
Looks like Pinterest is a provider but I have not tested a URL myself - https://oembed.com/providers.json

Marking this with good first issue.

```
    {
        "provider_name": "Pinterest",
        "provider_url": "https://www.pinterest.com",
        "endpoints": [
            {
                "schemes": [
                    "https://www.pinterest.com/*"
                ],
                "url": "https://www.pinterest.com/oembed.json",
                "discovery": true
            }
        ]
    },
```
Hi @lb I'd like to work on this issue.
@Dharma-09 go for it, reach out if you need a hand. 

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
@@ -141,6 +141,15 @@
     ],
 }
 
+pinterest = {
+    "endpoint": "https://www.pinterest.com/oembed.json",
+    "urls": [
+        r"^https?://[-\w]+\.pinterest\.com\.?[a-z]*/.+$",
+        r"^https?://in\.pinterest\.com/.+$",
+        r"^https?://pin\.it/.+$",
+    ],
+}
+
 kinomap = {
     "endpoint": "https://www.kinomap.com/oembed",
     "urls": [
@@ -725,4 +734,5 @@
     vidyard,
     reddit,
     tidal,
+    pinterest,
 ]


Test patch:
Repository: wagtail/wagtail

Issue:
wagtail.core.utils should be updated to wagtail.coreutils on 3.0 upgrade
The contents of `wagtail.core.utils` have been moved to `wagtail.coreutils` rather than `wagtail.utils`, but the release note doesn't mention this and the `wagtail upgrademodulepaths` command doesn't account for it.


Discussion:

Resolving patch:
diff --git a/wagtail/bin/wagtail.py b/wagtail/bin/wagtail.py
--- a/wagtail/bin/wagtail.py
+++ b/wagtail/bin/wagtail.py
@@ -152,6 +152,7 @@ class UpdateModulePaths(Command):
         ),
         # Added in Wagtail 3.0
         (re.compile(r"\bwagtail\.tests\b"), "wagtail.test"),
+        (re.compile(r"\bwagtail\.core\.utils\b"), "wagtail.coreutils"),
         (re.compile(r"\bwagtail\.core\b"), "wagtail"),
         (re.compile(r"\bwagtail\.admin\.edit_handlers\b"), "wagtail.admin.panels"),
         (


Test patch:
Repository: wagtail/wagtail

Issue:
patternlibrary_override_tags breaks all non-development installations
#8665 added a `patternlibrary_override_tags` tag library to wagtail.admin, which depends on the django-pattern-library package listed in our testing_extras dependencies. However, this tag library will be loaded on all environments that have `wagtail.admin` in their INSTALLED_APPS, so any Wagtail installation that doesn't include testing_extras is currently broken.

As a non-frontend dev, I don't know what this tag library is for, and there's no documentation for me to find out. Deleting it and uninstalling django-pattern-library doesn't break any tests, so it seems to me that it doesn't really belong in the testing dependencies. (If it really is a testing dependency, I'd suggest that moving patternlibrary_override_tags.py into one of the test apps in wagtail/test/ would let it do whatever it's meant to do without breaking non-testing environments.)


Discussion:
@gasman my apologies - I assumed that was installed as we use pattern library already.

To be honest - not super sure on how to work around this so maybe I should just revert that PR for now?

I might not have time to look into this fully sorry. But agree this should be documented correctly.

cc @thibaudcolas 

Resolving patch:
diff --git a/wagtail/admin/templatetags/patternlibrary_override_tags.py b/wagtail/admin/templatetags/patternlibrary_override_tags.py
deleted file mode 100644
--- a/wagtail/admin/templatetags/patternlibrary_override_tags.py
+++ /dev/null
@@ -1,5 +0,0 @@
-from pattern_library.monkey_utils import override_tag
-
-from wagtail.admin.templatetags.wagtailadmin_tags import register
-
-override_tag(register, name="test_page_is_public")


Test patch:
Repository: wagtail/wagtail

Issue:
Pin beautifulsoup4 to a newer version
### Is your proposal related to a problem?

The current `install_requires` requires `beautifulsoup4>=4.8,<4.10`. The latest release of Beautifulsoup4 4.9 goes back to 2020. The problem with this release is that it relies on a `use_2to3` feature removed in setuptools 58+, meaning Wagtail can’t be installed in environments that use setuptools 58+.

### Describe the solution you'd like

Upgrade the pinned version of Beautifulsoup4. I’m using 4.11.1 in a personal project and everything works fine and the Wagtail tests pass.

### Describe alternatives you've considered

None.

### Additional context

None.



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -28,7 +28,7 @@
     "django-filter>=2.2,<23",
     "draftjs_exporter>=2.1.5,<3.0",
     "Pillow>=4.0.0,<10.0.0",
-    "beautifulsoup4>=4.8,<4.10",
+    "beautifulsoup4>=4.8,<4.12",
     "html5lib>=0.999,<2",
     "Willow>=1.4,<1.5",
     "requests>=2.11.1,<3.0",


Test patch:
Repository: wagtail/wagtail

Issue:
Move "delete" from save draft drop up
We want to remove the delete action from the publishing menu and instead have it in the three dots "more" menu up by the breadcrumbs.

---

Note from @kaedroho: the Delete button should remain available even when the page is locked.


Discussion:

Resolving patch:
diff --git a/wagtail/admin/action_menu.py b/wagtail/admin/action_menu.py
--- a/wagtail/admin/action_menu.py
+++ b/wagtail/admin/action_menu.py
@@ -209,21 +209,6 @@ def get_url(self, context):
         return reverse("wagtailadmin_pages:unpublish", args=(context["page"].id,))
 
 
-class DeleteMenuItem(ActionMenuItem):
-    name = "action-delete"
-    label = _("Delete")
-    icon_name = "bin"
-    classname = "action-secondary"
-
-    def is_shown(self, context):
-        if context["view"] == "edit":
-            perms_tester = self.get_user_page_permissions_tester(context)
-            return not perms_tester.page_locked() and perms_tester.can_delete()
-
-    def get_url(self, context):
-        return reverse("wagtailadmin_pages:delete", args=(context["page"].id,))
-
-
 class SaveDraftMenuItem(ActionMenuItem):
     name = "action-save-draft"
     label = _("Save Draft")
@@ -265,7 +250,6 @@ def _get_base_page_action_menu_items():
     if BASE_PAGE_ACTION_MENU_ITEMS is None:
         BASE_PAGE_ACTION_MENU_ITEMS = [
             SaveDraftMenuItem(order=0),
-            DeleteMenuItem(order=10),
             UnpublishMenuItem(order=20),
             PublishMenuItem(order=30),
             CancelWorkflowMenuItem(order=40),


Test patch:
Repository: wagtail/wagtail

Issue:
__str__ method doesn't return a string.
This code sample:

    >>> from wagtail.contrib.forms.models import FormSubmission

    >>> FormSubmission.objects.count()
    1
    >>> FormSubmission.objects.first()
    Traceback (most recent call last):
      File "<console>", line 1, in <module>
      File "lib64/python3.10/site-packages/django/db/models/base.py", line 580, in __repr__
        return "<%s: %s>" % (self.__class__.__name__, self)
      TypeError: __str__ returned non-string (type dict)

This method:

https://github.com/wagtail/wagtail/blob/18ad15a18f8e533b858ccde7d060b9d4e85dcfd4/wagtail/contrib/forms/models.py#L61-L62

should be:

    def __str__(self):
        return f"{self.form_data}"

 


Discussion:
Looks like this broke with https://github.com/wagtail/wagtail/pull/8230

Have confirmed it's an issue

Thanks for raising @xbello 

Resolving patch:
diff --git a/wagtail/contrib/forms/models.py b/wagtail/contrib/forms/models.py
--- a/wagtail/contrib/forms/models.py
+++ b/wagtail/contrib/forms/models.py
@@ -59,7 +59,7 @@ def get_data(self):
         }
 
     def __str__(self):
-        return self.form_data
+        return f"{self.form_data}"
 
     class Meta:
         abstract = True


Test patch:
diff --git a/wagtail/contrib/forms/tests/test_models.py b/wagtail/contrib/forms/tests/test_models.py
--- a/wagtail/contrib/forms/tests/test_models.py
+++ b/wagtail/contrib/forms/tests/test_models.py
@@ -183,6 +183,26 @@ def test_invalid_from_address(self):
         with self.assertRaises(ValidationError):
             make_form_page(from_address="not an email")
 
+    def test_string_representation_form_submission(self):
+        """
+        Ensure that a form submission can be logged / printed without error.
+        Broke when converting field to JSON - see #8927
+        """
+
+        self.client.post(
+            "/contact-us/",
+            {
+                "your_email": "bob@example.com",
+                "your_message": "hello world",
+                "your_choices": {},
+            },
+        )
+
+        self.assertGreaterEqual(FormSubmission.objects.count(), 1)
+
+        submission = FormSubmission.objects.first()
+        self.assertIn("hello world", str(submission))
+
 
 class TestFormWithCustomSubmission(TestCase, WagtailTestUtils):
     def setUp(self):
Repository: wagtail/wagtail

Issue:
Add missing required asterisk to title field’s placeholder
In our design system, the page title has a "required' asterisk next to its placeholder:

![Image](https://user-images.githubusercontent.com/877585/185309249-fe19740f-44c4-441f-b6e7-7f0941786c62.png)

This feels tricky to do in HTML/CSS, but it would be nice to find a way nonetheless. If possible without having to change the markup specifically for this field, so we keep field-specific customisations contained.

Currently, this title field’s custom styles are defined in: https://github.com/wagtail/wagtail/blob/9aeb2e3e49bb98201029d99fa613b0da9c6f1865/client/scss/components/forms/_title.scss#L34

To make matters worse, we currently support three widget types as title (CharField single-line, TextField multiline, RichTextField Draftail). It would be nice if we at least had the asterisk for the simplest single-line case. 


Discussion:
Discussing this with Ben – we’re ok with the asterisk not being the correct color for the time being. So this will just include adding a ` *` at the end of the page title text here: https://github.com/wagtail/wagtail/blob/6814d0beea34ca3e868811210ff2210934e72ec3/wagtail/admin/panels.py#L1204

There might be tests to update as well but I’m not sure. This should make for a nice first contribution to Wagtail!
Hi @thibaudcolas, I'm interested in working on this, can you assign it to me?
I'm interested as an outreachy applicant 
Hi @maryojo @damli40, no need to ask! You can just go for it, first come first serve. Do confirm here if you decide to work on this, so we avoid multiple people working on the same task.
Alright, I will work on it @thibaudcolas, thanks!

Resolving patch:
diff --git a/wagtail/admin/panels.py b/wagtail/admin/panels.py
--- a/wagtail/admin/panels.py
+++ b/wagtail/admin/panels.py
@@ -1201,7 +1201,7 @@ def set_default_page_edit_handlers(cls):
         FieldPanel(
             "title",
             classname="title",
-            widget=forms.TextInput(attrs={"placeholder": gettext_lazy("Page title")}),
+            widget=forms.TextInput(attrs={"placeholder": gettext_lazy("Page title*")}),
         ),
     ]
 


Test patch:
Repository: wagtail/wagtail

Issue:
Wagtail version number in admin has an extra dot
This is tagged as a [**good first issue**](https://github.com/wagtail/wagtail/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22good+first+issue%22) – if you want to take it on, please leave a comment below to say so, no need to ask for permission, first come first serve! State your intent and share any questions / plans you have on how to approach the task.

### Issue Summary

In the Settings menu, we display Wagtail’s version number at the bottom:

<img width="409" alt="dot-menu" src="https://user-images.githubusercontent.com/877585/195653500-98c8c982-f39f-4f24-a8df-3ebbc7401af1.png">

This has been there for a while and I don’t think there is a specific reason for it. It’d be nice to display the version numbers the same as what we do in the docs.

So rather than `v.2.16.1` – `v2.16.1`.

### Steps to Reproduce

1. Open the Wagtail admin
2. Open the Settings menu and look at the bottom

### Technical details

-   Wagtail version: tested in v.2.16.1

### Proposed solution

I believe this could be as simple as removing the "." here: https://github.com/wagtail/wagtail/blob/main/wagtail/admin/wagtail_hooks.py#L105

```diff
-footer_text="Wagtail v." + __version__,
+footer_text="Wagtail v" + __version__,
```

We’d need to test that this doesn’t affect our other code relying on version numbers.


Discussion:
I would love to work on this @thibaudcolas 

I would love to work on this 

Resolving patch:
diff --git a/wagtail/admin/wagtail_hooks.py b/wagtail/admin/wagtail_hooks.py
--- a/wagtail/admin/wagtail_hooks.py
+++ b/wagtail/admin/wagtail_hooks.py
@@ -102,7 +102,7 @@ def render_component(self, request):
             self.menu.render_component(request),
             icon_name=self.icon_name,
             classnames=self.classnames,
-            footer_text="Wagtail v." + __version__,
+            footer_text="Wagtail v" + __version__,
         )
 
 


Test patch: