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

Issue:
Group index page lost default ordering in 5.2
### Issue Summary

The IndexView for groups [defines a `default_ordering`](https://github.com/wagtail/wagtail/blob/stable/5.2.x/wagtail/users/views/groups.py#L63) but it is not being used in Wagtail 5.2. Reverting to Wagtail 5.1 shows the expected ordering by name without `?ordering=name` in the url.

### Steps to Reproduce

1. Use your favorite method to spin up Bakery Demo
2. Go to http://localhost:8000/admin/groups/ and add a new Group with a name starting with something after "M". The new group should appear after "Moderators" in the listing page but instead it will appear at the top of the list. 

Any other relevant information. 

Explicit sorting is working fine (http://localhost:8000/admin/groups/?ordering=name and http://localhost:8000/admin/groups/?ordering=-name sort by name ascending and descending). It is only the default_ordering that is getting lost.

-   I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

### Technical details

-   Python version: 3.8.18
-   Django version: 4.0.10
-   Wagtail version: wagtail source at bdc454d3cb 




Discussion:

Resolving patch:
diff --git a/wagtail/users/views/groups.py b/wagtail/users/views/groups.py
--- a/wagtail/users/views/groups.py
+++ b/wagtail/users/views/groups.py
@@ -59,8 +59,6 @@ class IndexView(generic.IndexView):
     search_fields = ["name"]
     context_object_name = "groups"
     paginate_by = 20
-    ordering = ["name"]
-    default_ordering = "name"
 
     columns = [
         TitleColumn(
@@ -157,6 +155,7 @@ class DeleteView(generic.DeleteView):
 class GroupViewSet(ModelViewSet):
     icon = "group"
     model = Group
+    ordering = ["name"]
     add_to_reference_index = False
     _show_breadcrumbs = False
 


Test patch:
diff --git a/wagtail/users/tests/test_admin_views.py b/wagtail/users/tests/test_admin_views.py
--- a/wagtail/users/tests/test_admin_views.py
+++ b/wagtail/users/tests/test_admin_views.py
@@ -1347,6 +1347,15 @@ def test_search(self):
         self.assertEqual(response.status_code, 200)
         self.assertEqual(response.context["search_form"]["q"].value(), "Hello")
 
+    def test_default_ordering(self):
+        # This group should display after the default groups but will display
+        # before them if default_ordering is lost.
+        Group.objects.create(name="Photographers")
+        response = self.get()
+        # groups should be returned in alpha order by name
+        names = [group.name for group in response.context_data["object_list"]]
+        self.assertEqual(names, ["Editors", "Moderators", "Photographers"])
+
 
 class TestGroupIndexResultsView(WagtailTestUtils, TestCase):
     def setUp(self):
Repository: wagtail/wagtail

Issue:
When WAGTAILIMAGES_FEATURE_DETECTION_ENABLED = True, upload of svg files gives an error
Uploading svg-images fails when WAGTAILIMAGES_FEATURE_DETECTION_ENABLED = True. 

We get an AttributeError at /admin/images/multiple/add/ : 
'SvgImageFile' object has no attribute 'detect_faces'

We are working on Debian and have the following packages installed (amongst others) in our virtual env:
wagtail==5.1.3
Willow==1.6.2
Pillow==10.1.0
pillow-heif==0.13.1
Wand==0.6.11
opencv-python==4.8.1.78

In our settings:
WAGTAILIMAGES_EXTENSIONS = ["gif", "jpg", "jpeg", "png", "webp", "svg"] 
WAGTAILIMAGES_FEATURE_DETECTION_ENABLED = True

Commenting the last line allows for svg uploads.

Python 3.9.2
Django==4.2.7

In the Firefox browser. Thanks for looking into this! 


Discussion:

Resolving patch:
diff --git a/wagtail/images/models.py b/wagtail/images/models.py
--- a/wagtail/images/models.py
+++ b/wagtail/images/models.py
@@ -377,6 +377,11 @@ def set_focal_point(self, rect):
             self.focal_point_height = None
 
     def get_suggested_focal_point(self):
+        if self.is_svg():
+            # We can't run feature detection on SVGs, and don't provide a
+            # pathway from SVG -> raster formats, so don't try it.
+            return None
+
         with self.get_willow_image() as willow:
             faces = willow.detect_faces()
 


Test patch:
diff --git a/wagtail/images/tests/test_models.py b/wagtail/images/tests/test_models.py
--- a/wagtail/images/tests/test_models.py
+++ b/wagtail/images/tests/test_models.py
@@ -28,7 +28,12 @@
 )
 from wagtail.test.utils import WagtailTestUtils, override_settings
 
-from .utils import Image, get_test_image_file, get_test_image_filename
+from .utils import (
+    Image,
+    get_test_image_file,
+    get_test_image_file_svg,
+    get_test_image_filename,
+)
 
 
 class CustomStorage(Storage):
@@ -123,6 +128,18 @@ def test_file_hash(self):
             self.image.get_file_hash(), "4dd0211870e130b7e1690d2ec53c499a54a48fef"
         )
 
+    def test_get_suggested_focal_point_svg(self):
+        """
+        Feature detection should not be run on SVGs.
+
+        https://github.com/wagtail/wagtail/issues/11172
+        """
+        image = Image.objects.create(
+            title="Test SVG",
+            file=get_test_image_file_svg(),
+        )
+        self.assertIsNone(image.get_suggested_focal_point())
+
 
 class TestImageQuerySet(TransactionTestCase):
     fixtures = ["test_empty.json"]
Repository: wagtail/wagtail

Issue:
LookupError for invalid bulk action URL
### Issue Summary

500 LookupError for invalid bulk actions URL. 

### Steps to Reproduce

```
pip install wagtail==5.2.2
wagtail start mysite
cd mysite
./manage.py makemigrations
./manage.py migrate
./manage.py createsuperuser
./manage.py runserver
```

Go to: http://127.0.0.1:8000/admin/bulk/test/test/test/

See a 500:

LookupError at /admin/bulk/test/test/test/
No installed app with label 'test'.

-   I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

### Technical details

-   Python version: 3.12 / any
-   Django version: 5.0 / any
-   Wagtail version: 5.2.2 / main
-   Browser version: n/a

### Working on this

Following up with a PR shortly.



Discussion:

Resolving patch:
diff --git a/wagtail/admin/views/bulk_action/dispatcher.py b/wagtail/admin/views/bulk_action/dispatcher.py
--- a/wagtail/admin/views/bulk_action/dispatcher.py
+++ b/wagtail/admin/views/bulk_action/dispatcher.py
@@ -5,7 +5,10 @@
 
 
 def index(request, app_label, model_name, action):
-    model = apps.get_model(app_label, model_name)
+    try:
+        model = apps.get_model(app_label, model_name)
+    except LookupError:
+        raise Http404
     action_class = registry.get_bulk_action_class(app_label, model_name, action)
     if action_class is not None:
         return action_class(request, model).dispatch(request)


Test patch:
diff --git a/wagtail/admin/tests/pages/test_bulk_actions/test_bulk_action.py b/wagtail/admin/tests/pages/test_bulk_actions/test_bulk_action.py
--- a/wagtail/admin/tests/pages/test_bulk_actions/test_bulk_action.py
+++ b/wagtail/admin/tests/pages/test_bulk_actions/test_bulk_action.py
@@ -20,3 +20,15 @@ def test_bulk_action_invalid_action(self):
         )
         response = self.client.get(url)
         self.assertEqual(response.status_code, 404)
+
+    def test_bulk_action_invalid_model(self):
+        url = reverse(
+            "wagtail_bulk_action",
+            args=(
+                "doesnotexist",
+                "doesnotexist",
+                "doesnotexist",
+            ),
+        )
+        response = self.client.get(url)
+        self.assertEqual(response.status_code, 404)
Repository: wagtail/wagtail

Issue:
Documentation required for AbstractImage.get_upload_to and AbstractRendition.get_upload_to
These two methods give site implementors control over where image files are stored but are not yet documented anywhere. This should probably be located in the advanced topics => images section.



Discussion:
I will give a start to this 
@Dharma-09 start with the python docstrings and then use the documentation autodoc system - this way we can also see nice docs in the code. 
Hello
I'm an outreachy applicant and I'd love to contribute to this issue @thibaudcolas 
@MaryAyobami - there is already a PR with feedback but no response since March. 

https://github.com/wagtail/wagtail/pull/8228

Please comment to the author of that PR and see if they are still intending to complete the requested changes. 

If you don't hear back in a day or so - feel free to copy that PR's changes (or see what was done), read the feedback and put a new PR up. 

Please ensure you reference the original PR AND this issue in your PR's description so we can track the contributors and close the older PR. 
Go for it @gyanaranjans - please read the previous comments as it links to an existing PR that has this job partially done. 
We do not normally assign issues outside of the core team. 
@gyanaranjans are you still working on this issue?

I want to work on this issue. kindly give me permission and access to work on this issue

Resolving patch:
diff --git a/wagtail/images/models.py b/wagtail/images/models.py
--- a/wagtail/images/models.py
+++ b/wagtail/images/models.py
@@ -300,6 +300,11 @@ def _set_image_file_metadata(self):
         self.file.seek(0)
 
     def get_upload_to(self, filename):
+        """
+        Generates a file path in the "original_images" folder.
+        Ensuring ASCII characters and limiting length to prevent filesystem issues during uploads.
+        """
+
         folder_name = "original_images"
         filename = self.file.field.storage.get_valid_name(filename)
 
@@ -1264,6 +1269,9 @@ def __html__(self):
         return self.img_tag()
 
     def get_upload_to(self, filename):
+        """
+        Generates a file path within the "images" folder by combining the folder name and the validated filename.
+        """
         folder_name = "images"
         filename = self.file.field.storage.get_valid_name(filename)
         return os.path.join(folder_name, filename)


Test patch:
Repository: wagtail/wagtail

Issue:
`to_python` throws `AttributeError` on `TableBlock` when value is None
### Issue Summary

Similar to: https://github.com/wagtail/wagtail/issues/4822

After upgrading one of our sites to 6.0, attempting to update some of our pages' indices results in a server error.

```
  File "/venv/lib/python3.8/site-packages/wagtail/contrib/table_block/blocks.py", line 135, in to_python
    if not value.get("table_header_choice", ""):
AttributeError: 'NoneType' object has no attribute 'get'
```

This is because, in Wagtail 6.0, the following code has been added:
https://github.com/wagtail/wagtail/commit/fe1a306285da6c48b66506c589abc2c66b51668a#diff-f058d7a36746222950f678ed6b178205778e4e1e5b85f0299c2a7c3b9d6c8939R129

### Steps to Reproduce

1. Create a page with an empty TableBlock in its body
2. Before Wagtail 6.0, this should save and render OK
3. After upgrading to 6.0, editing the same page will throw an error.
4. Looking at the logs, you should see the error above

A workaround is to identify those pages and remove the empty TableBlocks, but this would prove to be a tedious task if there are many page instances.

A possible fix would be to check if the value is not None first:
```
if value and not value.get("table_header_choice", ""):
```


Discussion:
Thanks for the report! I can confirm this issue using the bakerydemo by creating a new Recipe page with an empty table block.

Resolving patch:
diff --git a/wagtail/contrib/table_block/blocks.py b/wagtail/contrib/table_block/blocks.py
--- a/wagtail/contrib/table_block/blocks.py
+++ b/wagtail/contrib/table_block/blocks.py
@@ -132,7 +132,7 @@ def to_python(self, value):
         value for the header choice. I would really like to have this default to "" and force the
         editor to reaffirm they don't want any headers, but that would be a breaking change.
         """
-        if not value.get("table_header_choice", ""):
+        if value and not value.get("table_header_choice", ""):
             if value.get("first_row_is_table_header", False) and value.get(
                 "first_col_is_header", False
             ):


Test patch:
diff --git a/wagtail/contrib/table_block/tests.py b/wagtail/contrib/table_block/tests.py
--- a/wagtail/contrib/table_block/tests.py
+++ b/wagtail/contrib/table_block/tests.py
@@ -439,6 +439,12 @@ def test_merge_cells_render(self):
         """
         self.assertHTMLEqual(result, expected)
 
+    def test_empty_table_block_to_python(self):
+        # Should not raise an error
+        # See https://github.com/wagtail/wagtail/issues/11816
+        block = TableBlock()
+        self.assertIsNone(block.to_python(None))
+
 
 class TestTableBlockForm(WagtailTestUtils, SimpleTestCase):
     def setUp(self):
Repository: wagtail/wagtail

Issue:
Rename of `wagtail.models.collections` to `wagtail.models.media` breaks custom document/image model migrations
### Issue Summary

In https://github.com/wagtail/wagtail/commit/e6aebc65a804a0e0e0ced24601da6bea0e786fc7 (from #8085 / #11555) the Collection model definition was moved from `wagtail.models.collections` to `wagtail.models.media`. This was assumed to be safe as models in the Wagtail core app are conventionally imported from `wagtail.models`, with the submodules being an implementation detail.

However, migrations for a custom image or document model created via `./manage.py makemigrations` on an earlier Wagtail version have an embedded reference to `import wagtail.models.collections`, which is brought in by the `CollectionMember` mixin having a reference to the `get_root_collection_id` function as the `collection` field's default value. These migrations fail with a ModuleNotFoundError under Wagtail 6.1rc1.

### Steps to Reproduce

1. Start a new project with `wagtail start myproject` under Wagtail 6.0
2. Add a `mydocuments` app with a `models.py` containing:

```python
from django.db import models
from wagtail.documents.models import AbstractDocument, Document


class CustomDocument(AbstractDocument):
    source = models.CharField(max_length=255, blank=True, default="")
    admin_form_fields = (*Document.admin_form_fields,"source")
```

3. Run `./manage.py makemigrations` and `./manage.py migrate`
4. Observe that the resulting migration in mydocuments contains the line `import wagtail.models.collections`
5. Install Wagtail 6.1rc1
6. Re-run `./manage.py migrate`
7. Receive the error `ModuleNotFoundError: No module named 'wagtail.models.collections'`

-   I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: no



Discussion:
Can confirm this issue. Just cropped up as I'm working on the project code for the tutorial that @vossisboss and I are presenting at PyCon US :)
Changing the import to `wagtail.models.media` and changing a reference from `wagtail.models.collection.get_root_collection_id` to `wagtail.models.media.get_root_collection_id` allowed the migrations to run.
Thanks for raising @gasman - sorry I missed this when reviewing the PR. I'm not super familiar with how to fix something like this, beyond just reverting the whole change. 

Is there a way to make sure that any existing migrations will be able to import from the new location? Maybe we make a module that just redirects to the new place. 


Alternatively, can we provide a script to get migrations updated?

Resolving patch:
diff --git a/wagtail/models/collections.py b/wagtail/models/collections.py
new file mode 100644
--- /dev/null
+++ b/wagtail/models/collections.py
@@ -0,0 +1,5 @@
+# wagtail.models.collections was moved to wagtail.models.media in #11555;
+# this import is retained to accommodate migration files importing from the old location.
+# See #11874
+
+from wagtail.models.media import get_root_collection_id  # noqa


Test patch:
Repository: fonttools/fonttools

Issue:
I find the font's line height is bigger than original font.
 I have tried pyftsubset  with command line option --no-recalc-bounds ,
but the generated subfont's line height is still bigger than original font.

I used html font-face render font.
@font-face {
            font-family: 'freetype';
            src: url('font.ttf') format('truetype');
 }

the font file is microsoft chinese liti.ttf.



Discussion:

Resolving patch:
diff --git a/Lib/fontTools/ttLib/tables/_v_h_e_a.py b/Lib/fontTools/ttLib/tables/_v_h_e_a.py
--- a/Lib/fontTools/ttLib/tables/_v_h_e_a.py
+++ b/Lib/fontTools/ttLib/tables/_v_h_e_a.py
@@ -35,7 +35,8 @@ def decompile(self, data, ttFont):
 		sstruct.unpack(vheaFormat, data, self)
 
 	def compile(self, ttFont):
-		self.recalc(ttFont)
+		if ttFont.isLoaded('glyf') and ttFont.recalcBBoxes:
+			self.recalc(ttFont)
 		return sstruct.pack(vheaFormat, self)
 
 	def recalc(self, ttFont):


Test patch:
Repository: fonttools/fonttools

Issue:
How bad is OTLOffsetOverflowError?
I discovered a warning from ttx with the last release of Mozilla's Fira - https://github.com/mozilla/Fira/issues/146 - and this is the warning:

```
WARNING: Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 8, 'SubTableIndex:', None, 'ItemName:', None, 'ItemIndex:', None)
```

Is this a problem? OTS passes.



Discussion:
No, this is fonttools working as intended.  We should change that from a warning to an informational log message.


Resolving patch:
diff --git a/Lib/fontTools/ttLib/tables/otBase.py b/Lib/fontTools/ttLib/tables/otBase.py
--- a/Lib/fontTools/ttLib/tables/otBase.py
+++ b/Lib/fontTools/ttLib/tables/otBase.py
@@ -95,7 +95,7 @@ def __init__(self, tableType):
 					raise # Oh well...
 
 				overflowRecord = e.value
-				log.warning("Attempting to fix OTLOffsetOverflowError %s", e)
+				log.info("Attempting to fix OTLOffsetOverflowError %s", e)
 				lastItem = overflowRecord
 
 				ok = 0


Test patch:
Repository: fonttools/fonttools

Issue:
[feaLib] can't get include(...) to work
I somehow can't get feaLib to handle an `include()`. It gives me this exception:

`fontTools.feaLib.error.FeatureLibError: myfeatures.fea:3:22: Expected feature, languagesystem, lookup, markClass, table, or glyph class definition`

Am I missing something obvious? Run the `addfeatures.py` script in the attached folder.

[feaLibIncludeTest.zip](https://github.com/behdad/fonttools/files/385432/feaLibIncludeTest.zip)



Discussion:
It's the semicolon.

https://github.com/behdad/fonttools/commit/7eed24725f33c76d033e40888d865e13d47622c2

/cc @brawer

I found a fix, I'll send a PR shortly. Can I use your test feature files in feaLib tests?


Resolving patch:
diff --git a/Lib/fontTools/feaLib/parser.py b/Lib/fontTools/feaLib/parser.py
--- a/Lib/fontTools/feaLib/parser.py
+++ b/Lib/fontTools/feaLib/parser.py
@@ -49,6 +49,8 @@ def parse(self):
             elif self.is_cur_keyword_("valueRecordDef"):
                 statements.append(
                     self.parse_valuerecord_definition_(vertical=False))
+            elif self.cur_token_type_ is Lexer.SYMBOL and self.cur_token_ == ";":
+                continue
             else:
                 raise FeatureLibError(
                     "Expected feature, languagesystem, lookup, markClass, "


Test patch:
diff --git a/Lib/fontTools/feaLib/parser_test.py b/Lib/fontTools/feaLib/parser_test.py
--- a/Lib/fontTools/feaLib/parser_test.py
+++ b/Lib/fontTools/feaLib/parser_test.py
@@ -1242,6 +1242,8 @@ def test_languagesystem(self):
     def test_empty_statement_ignored(self):
         doc = self.parse("feature test {;} test;")
         self.assertFalse(doc.statements[0].statements)
+        doc = self.parse(";;;")
+        self.assertFalse(doc.statements)
 
     def setUp(self):
         self.tempdir = None
Repository: fonttools/fonttools

Issue:
hmtx code should round values
Currently, float values result in exception:

```
    self._writeTable(masterTable, writer, done)
  File "/usr/local/lib/python2.7/dist-packages/fonttools-3.0-py2.7.egg/fontTools/ttLib/__init__.py", line 648, in _writeTable
    tabledata = self.getTableData(tag)
  File "/usr/local/lib/python2.7/dist-packages/fonttools-3.0-py2.7.egg/fontTools/ttLib/__init__.py", line 659, in getTableData
    return self.tables[tag].compile(self)
  File "/usr/local/lib/python2.7/dist-packages/fonttools-3.0-py2.7.egg/fontTools/ttLib/tables/_h_m_t_x.py", line 68, in compile
    allMetrics = array.array("h", allMetrics)
TypeError: integer argument expected, got float
```

Possibly warn?  Though it will become annoying if we do.



Discussion:

Resolving patch:
diff --git a/Lib/fontTools/ttLib/tables/_h_m_t_x.py b/Lib/fontTools/ttLib/tables/_h_m_t_x.py
--- a/Lib/fontTools/ttLib/tables/_h_m_t_x.py
+++ b/Lib/fontTools/ttLib/tables/_h_m_t_x.py
@@ -78,14 +78,14 @@ def compile(self, ttFont):
 				lastIndex = 1
 				break
 		additionalMetrics = metrics[lastIndex:]
-		additionalMetrics = [sb for advance, sb in additionalMetrics]
+		additionalMetrics = [int(round(sb)) for _, sb in additionalMetrics]
 		metrics = metrics[:lastIndex]
 		numberOfMetrics = len(metrics)
 		setattr(ttFont[self.headerTag], self.numberOfMetricsName, numberOfMetrics)
 
 		allMetrics = []
-		for item in metrics:
-			allMetrics.extend(item)
+		for advance, sb in metrics:
+			allMetrics.extend([int(round(advance)), int(round(sb))])
 		metricsFmt = ">" + self.longMetricFormat * numberOfMetrics
 		try:
 			data = struct.pack(metricsFmt, *allMetrics)


Test patch:
diff --git a/Lib/fontTools/ttLib/tables/_h_m_t_x_test.py b/Lib/fontTools/ttLib/tables/_h_m_t_x_test.py
--- a/Lib/fontTools/ttLib/tables/_h_m_t_x_test.py
+++ b/Lib/fontTools/ttLib/tables/_h_m_t_x_test.py
@@ -160,6 +160,19 @@ def test_compile_struct_out_of_range(self):
         with self.assertRaises(struct.error):
             mtxTable.compile(font)
 
+    def test_compile_round_float_values(self):
+        font = self.makeFont(numGlyphs=3, numberOfMetrics=2)
+        mtxTable = font[self.tag] = newTable(self.tag)
+        mtxTable.metrics = {
+            'A': (0.5, 0.5),  # round -> (0, 0)
+            'B': (0.1, 0.9),  # round -> (0, 1)
+            'C': (0.1, 0.1),  # round -> (0, 0)
+        }
+
+        data = mtxTable.compile(font)
+
+        self.assertEqual(data, deHexStr("0000 0000 0000 0001 0000"))
+
     def test_toXML(self):
         font = self.makeFont(numGlyphs=2, numberOfMetrics=2)
         mtxTable = font[self.tag] = newTable(self.tag)