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

Issue:
Searching images without match is not displayed correctly (minor)
When searching for images, if you enter a query string which will not return resuls you will get the message Sorry, no images match "" (without the query string inside the ""). Beyon this, search works fine.



Discussion:
I think the problem you're talking of is already fixed. Mine shows the "string" (the quotes around)
http://imgur.com/PlWdOmL

This commit may have something to do with it: https://github.com/torchbox/wagtail/commit/db884758ac525c2f5f967270fb9c4676251b7d92

I changed the name of the template variable which stores the query string to "query_string" to make it more consistant with the other search pages in the admin interface. I might have forgotten to replace a reference to this somewhere. I'll take a look into this later

@kaedroho what's the status of this?

@kaedroho ping

I have tried entering search terms that won't match anything into various admin search boxes and can confirm that it works properly on the following pages: 

/admin/pages/search/
/admin/images/
/admin/documents/
/admin/snippets/
/admin/users/
/admin/redirects/

I have also checked @kaedroho's commit and can confirm that "q" was correctly changed to "query string" in wagatailimages/templates/wagtailimages/images/results.html.

The only page that does not display the correct text when searching for terms that won't match anything is /admin/search/editorspicks/. "Editor's picks" is going to be significantly altered by https://github.com/torchbox/wagtail/pull/223, so I will wait until after that pull request has been merged, then review this ticket again.


Resolving patch:
diff --git a/wagtail/wagtailsearch/views/editorspicks.py b/wagtail/wagtailsearch/views/editorspicks.py
--- a/wagtail/wagtailsearch/views/editorspicks.py
+++ b/wagtail/wagtailsearch/views/editorspicks.py
@@ -13,6 +13,7 @@
 @permission_required('wagtailadmin.access_admin')
 @vary_on_headers('X-Requested-With')
 def index(request):
+    is_searching = False
     page = request.GET.get('p', 1)
     query_string = request.GET.get('q', "")
 
@@ -21,6 +22,7 @@ def index(request):
     # Search
     if query_string:
         queries = queries.filter(query_string__icontains=query_string)
+        is_searching = True
 
     # Pagination
     paginator = Paginator(queries, 20)
@@ -33,11 +35,13 @@ def index(request):
 
     if request.is_ajax():
         return render(request, "wagtailsearch/editorspicks/results.html", {
+            'is_searching': is_searching,
             'queries': queries,
             'query_string': query_string,
         })
     else:
         return render(request, 'wagtailsearch/editorspicks/index.html', {
+            'is_searching': is_searching,
             'queries': queries,
             'query_string': query_string,
             'search_form': SearchForm(data=dict(q=query_string) if query_string else None, placeholder=_("Search editor's picks")),


Test patch:
Repository: wagtail/wagtail

Issue:
test_post_reorder in editors picks unit tests failing on Sqlite
Running the unit tests under sqlite:

```
DATABASE_ENGINE=django.db.backends.sqlite3 ./runtests.py
```

results in this test failure:

```
FAIL: test_post_reorder (wagtail.wagtailsearch.tests.test_editorspicks.TestEditorsPicksEditView)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vagrant/wagtail/wagtail/wagtailsearch/tests/test_editorspicks.py", line 222, in test_post_reorder
    self.assertEqual(models.Query.get("Hello").editors_picks.all()[0], self.editors_pick_2)
AssertionError: <EditorsPick: EditorsPick object> != <EditorsPick: EditorsPick object>

----------------------------------------------------------------------
Ran 446 tests in 36.358s

FAILED (failures=1, skipped=9, expected failures=1)
Destroying test database for alias 'default'...
```



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailsearch/models.py b/wagtail/wagtailsearch/models.py
--- a/wagtail/wagtailsearch/models.py
+++ b/wagtail/wagtailsearch/models.py
@@ -76,6 +76,9 @@ class EditorsPick(models.Model):
     sort_order = models.IntegerField(null=True, blank=True, editable=False)
     description = models.TextField(blank=True)
 
+    def __repr__(self):
+        return 'EditorsPick(query="' + self.query.query_string + '", page="' + self.page.title + '")'
+
     class Meta:
         ordering = ('sort_order', )
 
diff --git a/wagtail/wagtailsearch/views/editorspicks.py b/wagtail/wagtailsearch/views/editorspicks.py
--- a/wagtail/wagtailsearch/views/editorspicks.py
+++ b/wagtail/wagtailsearch/views/editorspicks.py
@@ -55,6 +55,9 @@ def save_editorspicks(query, new_query, editors_pick_formset):
         for i, form in enumerate(editors_pick_formset.ordered_forms):
             form.instance.sort_order = i
 
+            # Make sure the form is marked as changed so it gets saved with the new order
+            form.has_changed = lambda: True
+
         editors_pick_formset.save()
 
         # If query was changed, move all editors picks to the new query


Test patch:
diff --git a/wagtail/wagtailsearch/tests/test_editorspicks.py b/wagtail/wagtailsearch/tests/test_editorspicks.py
--- a/wagtail/wagtailsearch/tests/test_editorspicks.py
+++ b/wagtail/wagtailsearch/tests/test_editorspicks.py
@@ -218,6 +218,10 @@ def test_post_reorder(self):
         # User should be redirected back to the index
         self.assertRedirects(response, reverse('wagtailsearch_editorspicks_index'))
 
+        # Check that the ordering has been saved correctly
+        self.assertEqual(models.EditorsPick.objects.get(id=self.editors_pick.id).sort_order, 1)
+        self.assertEqual(models.EditorsPick.objects.get(id=self.editors_pick_2.id).sort_order, 0)
+
         # Check that the recommendations were reordered
         self.assertEqual(models.Query.get("Hello").editors_picks.all()[0], self.editors_pick_2)
         self.assertEqual(models.Query.get("Hello").editors_picks.all()[1], self.editors_pick)
Repository: wagtail/wagtail

Issue:
Search: Boosting the title to 100 is a bit extreme
I've not done any formal testing of this, but I think a value around 2 - 3 will be more appropriate.



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailcore/models.py b/wagtail/wagtailcore/models.py
--- a/wagtail/wagtailcore/models.py
+++ b/wagtail/wagtailcore/models.py
@@ -294,7 +294,7 @@ class Page(six.with_metaclass(PageBase, MP_Node, ClusterableModel, indexed.Index
     expired = models.BooleanField(default=False, editable=False)
 
     search_fields = (
-        indexed.SearchField('title', partial_match=True, boost=100),
+        indexed.SearchField('title', partial_match=True, boost=2),
         indexed.FilterField('id'),
         indexed.FilterField('live'),
         indexed.FilterField('owner'),


Test patch:
Repository: wagtail/wagtail

Issue:
"wagtail start project_name" fails to run on Windows 7
Hi. So everything is compiled perfectly inside the virtualenv and I'm trying to start a new project.

```
$ wagtail start wagtailtest
Creating a wagtail project called wagtailtest
Traceback (most recent call last):
  File "d:\VirtualEnvs\wagtail_env\Scripts\wagtail-script.py", line 9, in <module>
    load_entry_point('wagtail==0.6', 'console_scripts', 'wagtail')()
  File "d:\VirtualEnvs\wagtail_env\lib\site-packages\wagtail\bin\wagtail.py", line 75, in main
    COMMANDS[command](parser, options, args)
  File "d:\VirtualEnvs\wagtail_env\lib\site-packages\wagtail\bin\wagtail.py", line 51, in create_project
    project_name
  File "C:\Python27\Lib\subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\Lib\subprocess.py", line 710, in __init__
    errread, errwrite)
  File "C:\Python27\Lib\subprocess.py", line 958, in _execute_child
    startupinfo)
WindowsError: [Error 193] %1 is not a valid Win32 application
```

Windows 7 x64, Python 2.7 x32.



Discussion:
Seriously guys, is there a way I fix that? VS11 and 12 is installed.

The issue I opened refers to an installation with Visual Studio 12 installed and:

```
VS90COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
```

If I set the VS90COMNTOOLS to point to Visual Studio 11 tools directory, the output of wagtail-script.py or wagtail.exe is:

```
wagtail.exe: Bad file number
```


Resolving patch:
diff --git a/wagtail/bin/wagtail.py b/wagtail/bin/wagtail.py
--- a/wagtail/bin/wagtail.py
+++ b/wagtail/bin/wagtail.py
@@ -2,11 +2,11 @@
 from __future__ import print_function, absolute_import
 
 import os
-import subprocess
 import errno
 import sys
 
 from optparse import OptionParser
+from django.core.management import ManagementUtility
 
 
 def create_project(parser, options, args):
@@ -44,15 +44,15 @@ def create_project(parser, options, args):
     template_path = os.path.join(wagtail_path, 'project_template')
 
     # Call django-admin startproject
-    result = subprocess.call([
+    utility = ManagementUtility([
         'django-admin.py', 'startproject',
         '--template=' + template_path,
         '--name=Vagrantfile', '--ext=html,rst',
         project_name
     ])
+    utility.execute()
 
-    if result == 0:
-        print("Success! %(project_name)s is created" % {'project_name': project_name})
+    print("Success! %(project_name)s is created" % {'project_name': project_name})
 
 
 COMMANDS = {


Test patch:
Repository: wagtail/wagtail

Issue:
Need to document focal_point_key changes for people who use custom image models
Everyone who uses custom image models need to create a new migration to make the `focal_point_key` field on rendition not nullable. Also, South doesn't automatically add the `default=''` into the migration (even though it's set on the field) which would cause the migration to fail.

The migration may also fail if you have duplicate renditions (this applies to everyone, not just custom image model people). The following SQL query should delete them:

```
DELETE FROM wagtailimages_rendition WHERE image_id || '-' || filter_id IN (SELECT image_id || '-' || filter_id FROM (SELECT image_id, filter_id, COUNT(*) AS count FROM wagtailimages_rendition GROUP BY image_id, filter_id) AS renditions WHERE count > 1);
```



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py b/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py
--- a/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py
+++ b/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py
@@ -4,6 +4,13 @@
 from django.db import models, migrations
 
 
+def remove_duplicate_renditions(apps, schema_editor):
+    schema_editor.execute("""
+        DELETE FROM wagtailimages_rendition WHERE image_id || '-' || filter_id IN (
+            SELECT image_id || '-' || filter_id FROM wagtailimages_rendition WHERE focal_point_key IS NULL GROUP BY image_id, filter_id HAVING COUNT(*) > 1
+        ) AND focal_point_key IS NULL
+    """)
+
 class Migration(migrations.Migration):
 
     dependencies = [
@@ -11,6 +18,7 @@ class Migration(migrations.Migration):
     ]
 
     operations = [
+        migrations.RunPython(remove_duplicate_renditions),
         migrations.AlterField(
             model_name='rendition',
             name='focal_point_key',
diff --git a/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py b/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py
--- a/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py
+++ b/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py
@@ -10,6 +10,12 @@
 class Migration(SchemaMigration):
 
     def forwards(self, orm):
+        # remove duplicate renditions
+        db.execute("""
+            DELETE FROM wagtailimages_rendition WHERE image_id || '-' || filter_id IN (
+                SELECT image_id || '-' || filter_id FROM wagtailimages_rendition WHERE focal_point_key IS NULL GROUP BY image_id, filter_id HAVING COUNT(*) > 1
+            ) AND focal_point_key IS NULL
+        """)
 
         # Changing field 'Rendition.focal_point_key'
         db.alter_column('wagtailimages_rendition', 'focal_point_key', self.gf('django.db.models.fields.CharField')(max_length=255, default=''))


Test patch:
Repository: wagtail/wagtail

Issue:
Typo in wagtailforms.forms.FormBuilder.formfields
Line 86:

``` python
raise Exception("Unrecognised field type: " + form.field_type)
```

This raises `NameError: global name 'form' is not defined`

Ordinarily the flow of things wouldn't run into this line, but I was caught out when badly naming a form field in the json fixtures.



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailforms/forms.py b/wagtail/wagtailforms/forms.py
--- a/wagtail/wagtailforms/forms.py
+++ b/wagtail/wagtailforms/forms.py
@@ -83,7 +83,7 @@ def formfields(self):
             if field.field_type in self.FIELD_TYPES:
                 formfields[field.clean_name] = self.FIELD_TYPES[field.field_type](self, field, options)
             else:
-                raise Exception("Unrecognised field type: " + form.field_type)
+                raise Exception("Unrecognised field type: " + field.field_type)
 
         return formfields
 


Test patch:
Repository: wagtail/wagtail

Issue:
Allow use of MPO formatted JPEG images
Just tried loading some JPEG images into a website and was given an error "Not a valid JPEG image please use blah blah".

The images were from my Nikon D3300 which seems to create JPEG files in MPO format. This format is supported by Pillow but Wagtail is blocking them from being uploaded. I disabled the format validation and everything seemed to work fine.



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailimages/fields.py b/wagtail/wagtailimages/fields.py
--- a/wagtail/wagtailimages/fields.py
+++ b/wagtail/wagtailimages/fields.py
@@ -85,15 +85,19 @@ def check_image_file_format(self, f):
             # Couldn't get the PIL image, skip checking the internal file format
             return
 
-        image_format = extension
-        if extension == 'jpg':
-            image_format = 'jpeg'
+        image_format = extension.upper()
+        if image_format == 'JPG':
+            image_format = 'JPEG'
+
+        internal_image_format = image.format.upper()
+        if internal_image_format == 'MPO':
+            internal_image_format = 'JPEG'
 
         # Check that the internal format matches the extension
         # It is possible to upload PSD files if their extension is set to jpg, png or gif. This should catch them out
-        if image.format.upper() != image_format.upper():
+        if internal_image_format != image_format:
             raise ValidationError(self.error_messages['invalid_image_known_format'] % (
-                image_format.upper()
+                image_format,
             ), code='invalid_image_known_format')
 
     def check_image_file_size(self, f):


Test patch:
Repository: wagtail/wagtail

Issue:
Update all admin actions to work on the specific version of the page
Currently, the unpublish, delete, etc actions all work on the `Page` class. The downside of this is save/delete/clean methods are called on `Page` rather than on the specific class. Theres a couple of downsides to this:
- If someone's overridden the save/clean/delete methods on their Page class, these would not be called
- A post/pre save/delete signal hooked to a specific class will not be called, (instead, the signals on Page would be called)
- In search, the above issue will make the page be indexed twice (And in #714, it will not be reindexed at all)

I think we should update these to work on the specific object rather than the Page object



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailadmin/views/pages.py b/wagtail/wagtailadmin/views/pages.py
--- a/wagtail/wagtailadmin/views/pages.py
+++ b/wagtail/wagtailadmin/views/pages.py
@@ -363,7 +363,7 @@ def clean():
 
 @permission_required('wagtailadmin.access_admin')
 def delete(request, page_id):
-    page = get_object_or_404(Page, id=page_id)
+    page = get_object_or_404(Page, id=page_id).specific
     if not page.permissions_for_user(request.user).can_delete():
         raise PermissionDenied
 
@@ -500,7 +500,7 @@ def preview_loading(request):
 
 @permission_required('wagtailadmin.access_admin')
 def unpublish(request, page_id):
-    page = get_object_or_404(Page, id=page_id)
+    page = get_object_or_404(Page, id=page_id).specific
     if not page.permissions_for_user(request.user).can_unpublish():
         raise PermissionDenied
 
@@ -548,7 +548,7 @@ def move_choose_destination(request, page_to_move_id, viewed_page_id=None):
 
 @permission_required('wagtailadmin.access_admin')
 def move_confirm(request, page_to_move_id, destination_id):
-    page_to_move = get_object_or_404(Page, id=page_to_move_id)
+    page_to_move = get_object_or_404(Page, id=page_to_move_id).specific
     destination = get_object_or_404(Page, id=destination_id)
     if not page_to_move.permissions_for_user(request.user).can_move_to(destination):
         raise PermissionDenied
@@ -775,7 +775,7 @@ def preview_for_moderation(request, revision_id):
 @require_POST
 def lock(request, page_id):
     # Get the page
-    page = get_object_or_404(Page, id=page_id)
+    page = get_object_or_404(Page, id=page_id).specific
 
     # Check permissions
     if not page.permissions_for_user(request.user).can_lock():
@@ -800,7 +800,7 @@ def lock(request, page_id):
 @require_POST
 def unlock(request, page_id):
     # Get the page
-    page = get_object_or_404(Page, id=page_id)
+    page = get_object_or_404(Page, id=page_id).specific
 
     # Check permissions
     if not page.permissions_for_user(request.user).can_lock():


Test patch:
Repository: wagtail/wagtail

Issue:
Publishing a page removes its "last updated" date
This may be duplicate, but I couldn't find another report.
1. Create a page.
2. Save it and exit
3. Check its "updated" value in the page listing
4. Edit the page again
5. Publish it
6. "Updated" is now blank, meaning it gets ordered to the bottom of all the pages.

The correct behaviour is that the page should now appear at the top of the listing, with a last modified date of "0 secs ago" or similar. Publication is an update.



Discussion:

Resolving patch:
diff --git a/wagtail/wagtailcore/models.py b/wagtail/wagtailcore/models.py
--- a/wagtail/wagtailcore/models.py
+++ b/wagtail/wagtailcore/models.py
@@ -1034,6 +1034,7 @@ def as_page_object(self):
         obj.has_unpublished_changes = self.page.has_unpublished_changes
         obj.owner = self.page.owner
         obj.locked = self.page.locked
+        obj.latest_revision_created_at = self.page.latest_revision_created_at
 
         return obj
 


Test patch:
diff --git a/wagtail/wagtailcore/tests/test_page_model.py b/wagtail/wagtailcore/tests/test_page_model.py
--- a/wagtail/wagtailcore/tests/test_page_model.py
+++ b/wagtail/wagtailcore/tests/test_page_model.py
@@ -600,3 +600,22 @@ def test_allowed_parent_page_types(self):
         # BusinessSubIndex only allows BusinessIndex as a parent
         self.assertNotIn(ContentType.objects.get_for_model(SimplePage), BusinessSubIndex.allowed_parent_page_types())
         self.assertIn(ContentType.objects.get_for_model(BusinessIndex), BusinessSubIndex.allowed_parent_page_types())
+
+
+class TestIssue756(TestCase):
+    """
+    Issue 756 reports that the latest_revision_created_at
+    field was getting clobbered whenever a revision was published
+    """
+    def test_publish_revision_doesnt_remove_latest_revision_created_at(self):
+        # Create a revision
+        revision = Page.objects.get(id=1).save_revision()
+
+        # Check that latest_revision_created_at is set
+        self.assertIsNotNone(Page.objects.get(id=1).latest_revision_created_at)
+
+        # Publish the revision
+        revision.publish()
+
+        # Check that latest_revision_created_at is still set
+        self.assertIsNotNone(Page.objects.get(id=1).latest_revision_created_at)
Repository: wagtail/wagtail

Issue:
Unicode content in rich text causes error
Steps to reproduce:
1. Using the wagtail interface, create a new instance of a page derived model which has a rich text field
2. In the rich text field, include unicode characters such as: `©`  or `’`
3. Publish the page
   
   The page will be published fine, and probably rendered normally through a template.
4. Return to the wagtail admin, and edit the newly created page
   
   The rich text field is not rendered in the editing page. Inspecting the html shows that wagtail is attempting to render the field, its heading is there. But the field is not rendered.
   
   If you attempt to publish this new page, the form will submit a page with no content in the rich text field.



Discussion:

Resolving patch:
diff --git a/wagtail/utils/widgets.py b/wagtail/utils/widgets.py
--- a/wagtail/utils/widgets.py
+++ b/wagtail/utils/widgets.py
@@ -1,3 +1,5 @@
+from __future__ import absolute_import, unicode_literals
+
 from django.forms.widgets import Widget
 from django.utils.safestring import mark_safe
 
@@ -8,7 +10,7 @@ def render(self, name, value, attrs=None):
 
         final_attrs = self.build_attrs(attrs, name=name)
         id_ = final_attrs.get('id', None)
-        if 'id_' is None:
+        if id_ is None:
             return widget
 
         js = self.render_js_init(id_, name, value)


Test patch:
Repository: wagtail/wagtail

Issue:
Dropping Python 3.2 support
Python 3.2 is quite old and many projects are dropping support for it (`libsass` and `treebeard` both have already). Should we consider dropping support as well?



Discussion:
I vote yes.


Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -71,7 +71,6 @@
         'Programming Language :: Python :: 2',
         'Programming Language :: Python :: 2.7',
         'Programming Language :: Python :: 3',
-        'Programming Language :: Python :: 3.2',
         'Programming Language :: Python :: 3.3',
         'Programming Language :: Python :: 3.4',
         'Framework :: Django',


Test patch:
Repository: wagtail/wagtail

Issue:
Update to treebeard 3.0
This fixes many of the Django 1.7 warnings we get.

It also drops support for both Python 3.2 and 3.3 so we might need to tread carefully if we decide to adopt it. We already have a dependency that doesn't support 3.2 (`libsass`) which doesn't seem to be causing any problems for the time being (tests all pass, but I've not cheked it recently).



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -33,7 +33,7 @@
     "django-libsass>=0.2",
     "django-modelcluster>=0.4",
     "django-taggit==0.12.2",
-    "django-treebeard==2.0",
+    "django-treebeard==3.0",
     "Pillow>=2.6.1",
     "beautifulsoup4>=4.3.2",
     "html5lib==0.999",


Test patch: