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

Issue:
Fix consequences of making subscription OneToOneField
For instance:

```
 FieldError: Cannot resolv keyword 'notification_type' into field. Choices are: article, articleplugin_ptr, created, deleted, id, subscription, subscription_ptr
```

Fix consequences of making subscription OneToOneField
For instance:

```
 FieldError: Cannot resolv keyword 'notification_type' into field. Choices are: article, articleplugin_ptr, created, deleted, id, subscription, subscription_ptr
```



Discussion:
To be more clear on what the issue is, have a look at the AtricleSubscription model before the OneToOneField was introduced. This multiple inheritance was removed due to a change in Django 1.7.

https://github.com/django-wiki/django-wiki/blob/041864243aabad899c52116b22cd19e583816f79/wiki/plugins/notifications/models.py

So the change is that: Before, all fields of the django-nyt model `Subscription` was available directly on `ArticleSubscription`, and now you have to access them through `article_subscription.subscription.xxx`.

To be more clear on what the issue is, have a look at the AtricleSubscription model before the OneToOneField was introduced. This multiple inheritance was removed due to a change in Django 1.7.

https://github.com/django-wiki/django-wiki/blob/041864243aabad899c52116b22cd19e583816f79/wiki/plugins/notifications/models.py

So the change is that: Before, all fields of the django-nyt model `Subscription` was available directly on `ArticleSubscription`, and now you have to access them through `article_subscription.subscription.xxx`.


Resolving patch:
diff --git a/wiki/plugins/notifications/models.py b/wiki/plugins/notifications/models.py
--- a/wiki/plugins/notifications/models.py
+++ b/wiki/plugins/notifications/models.py
@@ -24,9 +24,9 @@ class ArticleSubscription(ArticlePlugin):
     
     def __str__(self):
         title = (_("%(user)s subscribing to %(article)s (%(type)s)") %
-                 {'user': self.settings.user.username,
+                 {'user': self.subscription.settings.user.username,
                   'article': self.article.current_revision.title,
-                  'type': self.notification_type.label})
+                  'type': self.subscription.notification_type.label})
         return str(title)
     
     class Meta:


Test patch:
Repository: django-wiki/django-wiki

Issue:
Downloading attachments with non-ascii characters is broken with Python 2
```
UnicodeDecodeError at /12/plugin/attachments/download/33/
'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
Request Method: GET
Request URL:    http://localhost:8000/12/plugin/attachments/download/33/
Django Version: 1.7.4
Exception Type: UnicodeDecodeError
Exception Value:    
'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
Exception Location: /home/christian/Projects/Python/django-wiki/testproject/wiki/core/http.py in send_file, line 50
Python Executable:  /home/christian/.virtualenvs/wiki-py2/bin/python
```



Discussion:
The cause is `from __future__ import unicode_literals`. 

I think the fix is to remove `.encode('utf-8')`, but I don't know enough about unicode handling in Python2/3 to be sure about this. 

Edit: Yeah, I'm pretty sure the fix is to remove encode. With encode in Python3 you get filenames like b'-xc3-xb8-xc3-xb8-xc3-xa5.pdf' from øøå.pdf


Resolving patch:
diff --git a/wiki/core/http.py b/wiki/core/http.py
--- a/wiki/core/http.py
+++ b/wiki/core/http.py
@@ -45,6 +45,6 @@ def send_file(request, filepath, last_modified=None, filename=None):
     
     # TODO: Escape filename
     if filename:
-        response["Content-Disposition"] = "attachment; filename=%s" % filename.encode('utf-8')
+        response["Content-Disposition"] = "attachment; filename=%s" % filename
     
     return response


Test patch:
Repository: django-wiki/django-wiki

Issue:
Django 1.7 migrations are incomplete, fail after makemigrations
My project uses Django 1.7.5 and Python 3.4.  I installed `django-wiki` from the current `master` branch, added the necessary settings, and ran `manage.py migrate`, and everything worked.  But my project's model definitions are in constant flux right now, so I re-create my initial migrations fairly often.  The most recent time I did this, it generated a second migration for `django-wiki`:

```
$ manage.py makemigrations
Migrations for 'wiki':
  0002_auto_20150308_0558.py:
    - Remove field article from articleplugin
    - Remove field articleplugin_ptr from reusableplugin
    - Remove field articles from reusableplugin
    - Delete model ReusablePlugin
    - Remove field articleplugin_ptr from revisionplugin
    - Remove field current_revision from revisionplugin
    - Remove field plugin from revisionpluginrevision
    - Delete model RevisionPlugin
    - Remove field previous_revision from revisionpluginrevision
    - Remove field user from revisionpluginrevision
    - Delete model RevisionPluginRevision
    - Remove field article_revision from simpleplugin
    - Remove field articleplugin_ptr from simpleplugin
    - Delete model ArticlePlugin
    - Delete model SimplePlugin
```

And this migration failed to run, with the following error:

```
Running migrations:
  Applying wiki.0002_auto_20150308_0558...Traceback (most recent call last):

...

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'wiki.SimplePlugin'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
 in an app with no migrations; see https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for more
```

Are those models really intended to be concrete?  Or should they be abstract mixins instead?



Discussion:
I haven't seen the error before. It suggests that an app label or something in the model's path has changed, because all those fields etc. are still there, just look in the models...

> Are those models really intended to be concrete?

Yes, this is to ensure that plugin data can be accessed without regards to any specific model types.

@benjaoming you're right, and after some more digging I've found the problem:

https://github.com/django-wiki/django-wiki/blob/master/wiki/models/__init__.py#L12-L13

If I add `from .pluginbase import *` here, then `manage.py makemigrations wiki` says no changes were detected, and everything still works properly.


Resolving patch:
diff --git a/wiki/models/__init__.py b/wiki/models/__init__.py
--- a/wiki/models/__init__.py
+++ b/wiki/models/__init__.py
@@ -10,6 +10,7 @@
 
 # TODO: Don't use wildcards
 from .article import *
+from .pluginbase import *
 from .urlpath import *
 
 # TODO: Should the below stuff be executed a more logical place?


Test patch:
Repository: django-wiki/django-wiki

Issue:
Allow hyphens in wiki slug
What's the reason for replacing hyphens with underscores?
I agree that spaces should be replaced with underscores as spaces in urls simply look bad. 
Hyphens on the other hand look fine and serve a different purpose than underscores. E.g. Wikipedia uses underscores for spaces and leave all hyphens as they are. 



Discussion:
Need hyphens as part of slug.  

For example we use other WIKI's for building pages for servers.  The pages have a url like `http://wiki.domain.com/hosts/datacenter-server-001`.  This gives us the ability to reference the page via a dynamically generated NOTES URL in our server monitoring app Nagios.

Without the ability to use hyphens in the slug, this functionality is broken for django-wiki for us and is a roadblock that prevents us from migrating to django-wiki.


Resolving patch:
diff --git a/wiki/forms.py b/wiki/forms.py
--- a/wiki/forms.py
+++ b/wiki/forms.py
@@ -333,7 +333,6 @@ def clean_slug(self):
                 parent=self.urlpath_parent)
         else:
             slug = slug.lower()
-            slug = slug.replace('-', '_')
             already_existing_slug = models.URLPath.objects.filter(
                 slug__iexact=slug,
                 parent=self.urlpath_parent)
diff --git a/wiki/views/article.py b/wiki/views/article.py
--- a/wiki/views/article.py
+++ b/wiki/views/article.py
@@ -75,8 +75,8 @@ def get_form(self, form_class):
             attrs={
                 # Make patterns force lowercase if we are case insensitive to bless the user with a
                 # bit of strictness, anyways
-                'pattern': '[a-z0-9_]+' if not settings.URL_CASE_SENSITIVE else '[a-zA-Z0-9_]+',
-                'title': 'Lowercase letters, numbers, and underscores' if not settings.URL_CASE_SENSITIVE else 'Letters, numbers, and underscores',
+                'pattern': '[a-z0-9_-]+' if not settings.URL_CASE_SENSITIVE else '[a-zA-Z0-9_-]+',
+                'title': 'Lowercase letters, numbers, hyphens and underscores' if not settings.URL_CASE_SENSITIVE else 'Letters, numbers, hyphens and underscores',
             }
         )
         return form


Test patch:
Repository: django-wiki/django-wiki

Issue:
Ordered list doesn't render properly
I am running django-wiki on Mac OS X 10.10.4 with a django 1.8 project and PostgreSQL database. 

Here's what pip reports from my virtualenv:

```
-e git://github.com/django-wiki/django-wiki.git@23705786796424a3b36be77c1e78d7316f89bb00#egg=wiki-master
```

I can display an ordered list fine with:

```
1. Dog
1. Cat
1. Mouse
```

That is:
1. Dog
2. Cat
3. Mouse

However, if the ordered list is preceded by an unordered list:

```
- Dog
- Cat
- Mouse

1. Dog
1. Cat
1. Mouse
```

Then the ordered list is rendered as an unordered list:
- Dog
- Cat
- Mouse
- Dog
- Cat
- Mouse



Discussion:
Wow, didn't know this could happen. You've found an error in the Markdown library for Python.

```
➜  ~  cat | markdown_py
Does it work?

 - Dog
 - Cat
 - Mouse

 1. Dog
 1. Cat
 1. Mouse


<p>Does it work?</p>
<ul>
<li>Dog</li>
<li>Cat</li>
<li>
<p>Mouse</p>
</li>
<li>
<p>Dog</p>
</li>
<li>Cat</li>
<li>Mouse</li>
</ul>%                   
```

Closing and cheering on the Markdown devs. If you like, you could go and help them out @davidthewatson - and thanks for reporting!

Okay we're referred to the markdown.extensions.sane_lists extension, I'll add that as a default extension.


Resolving patch:
diff --git a/wiki/conf/settings.py b/wiki/conf/settings.py
--- a/wiki/conf/settings.py
+++ b/wiki/conf/settings.py
@@ -25,6 +25,7 @@
         'attr_list',
         'extra',
         'codehilite',
+        'sane_lists',
     ],
     'safe_mode': 'replace',
     'extension_configs': {


Test patch:
Repository: django-wiki/django-wiki

Issue:
AJAX calls to revision diff and merge gives 500 server error
When viewing changes, clicking the version links gives 500 error, as the call to the diff() view function fails.
The same goes for merging of different versions.

The reason being that attaching a function pointer to a class is basically the same as
assigning a new instance method to the class. Thus, the first method argument is 'self', which
in this case is the URLPatterns object itself, when it should be the Django request object.

A PR is coming up shortly.



Discussion:

Resolving patch:
diff --git a/wiki/urls.py b/wiki/urls.py
--- a/wiki/urls.py
+++ b/wiki/urls.py
@@ -32,11 +32,11 @@ class WikiURLPatterns(object):
     article_settings_view_class = article.Settings
     article_source_view_class = article.Source
     article_plugin_view_class = article.Plugin
-    revision_change_view = article.ChangeRevisionView
-    revision_merge_view = article.merge
+    revision_change_view_class = article.ChangeRevisionView
+    revision_merge_view = staticmethod(article.merge)
 
     search_view_class = settings.SEARCH_VIEW
-    article_diff_view = article.diff
+    article_diff_view = staticmethod(article.diff)
 
     # account views
     signup_view_class = accounts.Signup
@@ -96,7 +96,7 @@ def get_revision_urls(self):
             # where to redirect after...
             url(
                 '^_revision/change/(?P<article_id>\d+)/(?P<revision_id>\d+)/$',
-                self.revision_change_view.as_view(),
+                self.revision_change_view_class.as_view(),
                 name='change_revision'),
             url('^_revision/preview/(?P<article_id>\d+)/$',
                 self.article_preview_view_class.as_view(),
@@ -139,7 +139,7 @@ def get_article_urls(self):
                 name='source'),
             url(
                 '^(?P<article_id>\d+)/revision/change/(?P<revision_id>\d+)/$',
-                self.revision_change_view.as_view(),
+                self.revision_change_view_class.as_view(),
                 name='change_revision'),
             url(
                 '^(?P<article_id>\d+)/revision/merge/(?P<revision_id>\d+)/$',
@@ -183,7 +183,7 @@ def get_article_path_urls(self):
                 name='source'),
             url(
                 '^(?P<path>.+/|)_revision/change/(?P<revision_id>\d+)/$',
-                self.revision_change_view.as_view(),
+                self.revision_change_view_class.as_view(),
                 name='change_revision'),
             url(
                 '^(?P<path>.+/|)_revision/merge/(?P<revision_id>\d+)/$',
@@ -199,7 +199,8 @@ def get_article_path_urls(self):
         ]
         return urlpatterns
 
-    def get_plugin_urls(self):
+    @staticmethod
+    def get_plugin_urls():
         urlpatterns = []
         for plugin in list(registry.get_plugins().values()):
             slug = getattr(plugin, 'slug', None)


Test patch:
Repository: django-wiki/django-wiki

Issue:
Error when adding URL paths through the admin
For articles I made through the admin interface, when I try to add a slug in the URL paths, I get the following error:

IntegrityError at /admin/wiki/urlpath/add/
NOT NULL constraint failed: wiki_urlpath.article_id

If I make an article through the UI default interface, it works though. Why is that?



Discussion:
First you create the article, then you create its URLPath... but the admin interface doesn't contain the `article` field in the form... that could be possible to add, but it would have to be as a raw foreign key field and not a drop down.

This would be a good first PR for you if you're interested since the other issue you opened has been fixed in another PR ;)


Resolving patch:
diff --git a/wiki/admin.py b/wiki/admin.py
--- a/wiki/admin.py
+++ b/wiki/admin.py
@@ -20,6 +20,7 @@ class ArticleObjectAdmin(GenericTabularInline):
     model = models.ArticleForObject
     extra = 1
     max_num = 1
+    raw_id_fields = ('article',)
 
 
 class ArticleRevisionForm(forms.ModelForm):
@@ -77,6 +78,7 @@ def __init__(self, *args, **kwargs):
 class ArticleAdmin(admin.ModelAdmin):
     inlines = [ArticleRevisionInline]
     form = ArticleForm
+    search_fields = ('current_revision__title', 'current_revision__content')
 
 
 class URLPathAdmin(MPTTModelAdmin):
@@ -85,11 +87,20 @@ class URLPathAdmin(MPTTModelAdmin):
                    'articles__article__created',
                    'articles__article__modified')
     list_display = ('__str__', 'article', 'get_created')
+    raw_id_fields = ('article',)
 
     def get_created(self, instance):
         return instance.article.created
     get_created.short_description = _('created')
 
+    def save_model(self, request, obj, form, change):
+        """
+        Ensure that there is a generic relation from the article to the URLPath
+        """
+        obj.save()
+        obj.article.add_object_relation(obj)
+
+
 admin.site.register(models.URLPath, URLPathAdmin)
 admin.site.register(models.Article, ArticleAdmin)
 admin.site.register(models.ArticleRevision, ArticleRevisionAdmin)
diff --git a/wiki/models/urlpath.py b/wiki/models/urlpath.py
--- a/wiki/models/urlpath.py
+++ b/wiki/models/urlpath.py
@@ -71,8 +71,11 @@ class URLPath(MPTTModel):
     article = models.ForeignKey(
         Article,
         on_delete=models.CASCADE,
-        editable=False,
-        verbose_name=_('Cache lookup value for articles'),
+        verbose_name=_('Lookup value'),
+        help_text=_(
+            "This field is automatically updated, but you need to populate "
+            "it when creating a new URL path."
+        )
     )
 
     SLUG_MAX_LENGTH = 50
@@ -84,7 +87,9 @@ class URLPath(MPTTModel):
         'self',
         null=True,
         blank=True,
-        related_name='children')
+        related_name='children',
+        help_text=_("Position of URL path in the tree.")
+    )
 
     def __init__(self, *args, **kwargs):
         pass


Test patch:
Repository: django-wiki/django-wiki

Issue:
UnicodeEncodeError when replacing images or files with non-US filename
My Setting : Python 2.7.6, Django 1.7.8 and Django-wiki 0.1.dev with LANG="ko_KR.UTF-8" 

In test article, click 'Edit' -> 'Images' -> 'Add new image'

There is no problem when I upload non-US filename ( 사랑이란.jpg , for example ).

`"New image 사랑이란.jpg was successfully uploaded. You can use it by selecting it from the list of available images."`

But error occured when I click again 'Images' and click 'Replace'

`UnicodeEncodeError at /Test/_plugin/images/33/revision/add/
'ascii' codec can't encode characters in position 7-10: ordinal not in range(128)`

Same problem occured with Japanese character. ( 愛し.jpg , for example )

I guess @python_2_unicode_compatible decorator doesn't work well, so I changed code wiki/plugins/images/models.py

```
 56     def __str__(self):
 57         title = (_('Image: %s') % self.current_revision.imagerevision.get_filename(
 58         )) if self.current_revision else _('Current revision not set!!')
 59         return str(title)
```

to 

from django.utils.encoding import smart_unicode <- add 

```
def __str__(self):
     title = (_('Image: %s') % self.current_revision.imagerevision.get_filename(
     )) if self.current_revision else _('Current revision not set!!')
     return smart_unicode(title)
```

and there is no errors. But I also guess this code doesn't work under python3.

Any Ideas?



Discussion:

Resolving patch:
diff --git a/wiki/plugins/images/models.py b/wiki/plugins/images/models.py
--- a/wiki/plugins/images/models.py
+++ b/wiki/plugins/images/models.py
@@ -7,6 +7,7 @@
 from django.db import models
 from django.utils.encoding import python_2_unicode_compatible
 from django.utils.translation import ugettext_lazy as _
+from django.utils.translation import ugettext
 
 from . import settings
 
@@ -54,9 +55,10 @@ class Meta:
             app_label = settings.APP_LABEL
 
     def __str__(self):
-        title = (_('Image: %s') % self.current_revision.imagerevision.get_filename(
-        )) if self.current_revision else _('Current revision not set!!')
-        return str(title)
+        if self.current_revision:
+            return ugettext('Image: %s') % self.current_revision.imagerevision.get_filename()
+        else:
+            return ugettext('Current revision not set!!')
 
 
 @python_2_unicode_compatible
@@ -114,8 +116,7 @@ class Meta:
         ordering = ('-created',)
 
     def __str__(self):
-        title = _('Image Revsion: %d') % self.revision_number
-        return str(title)
+        return ugettext('Image Revsion: %d') % self.revision_number
 
 
 def on_image_revision_delete(instance, *args, **kwargs):


Test patch:
Repository: django-wiki/django-wiki

Issue:
Article rendering cache key using active language
Rendering may use translated texts. For instance, `wiki/plugins/macros/templates/wiki/plugins/macros/article_list.html` has this:

    <li class="nav-header">{% trans "Article index" %} <i class="fa fa-list"></i></li>

The above will result in the string "Article index" being rendered and stored on the first active language that results in a call to `Article.render`, and thus all other languages will use this rendering regardless.

We should use the active language in the cache key to avoid this behavior.


Discussion:

Resolving patch:
diff --git a/wiki/models/article.py b/wiki/models/article.py
--- a/wiki/models/article.py
+++ b/wiki/models/article.py
@@ -6,6 +6,7 @@
 from django.core.urlresolvers import reverse
 from django.db import models
 from django.db.models.signals import post_save, pre_delete, pre_save
+from django.utils import translation
 from django.utils.encoding import python_2_unicode_compatible
 from django.utils.safestring import mark_safe
 from django.utils.translation import ugettext_lazy as _
@@ -209,8 +210,11 @@ def render(self, preview_content=None):
                                           preview=preview_content is not None))
 
     def get_cache_key(self):
-        return "wiki:article:%d" % (
-            self.current_revision.id if self.current_revision else self.id)
+        lang = translation.get_language()
+        return "wiki:article:{id:d}:{lang:s}".format(
+            id=self.current_revision.id if self.current_revision else self.id,
+            lang=lang
+        )
 
     def get_cached_content(self):
         """Returns cached """


Test patch:
Repository: django-wiki/django-wiki

Issue:
Bleach strips all styles (could be configurable)
Hi,

in our project we sometimes rely on django-wiki allowing the article writers to use their custom styles in an article.., with new django-wiki using bleach, this stopped working. It is possible to allow `style` attribute for all allowed tags, but bleach also requires a list of styles to allow, which defaults to an empty list, and is not configurable in current django-wiki release.

Would it be possible to add another setting for allowed styles, like the settings for allowed tags and attributes?


Discussion:
Yes, I would totally welcome that change. Would you be able to do a PR, adding this as a setting?

Sorry that this Bleach stuff has caused so many issues up until now :(

Resolving patch:
diff --git a/wiki/conf/settings.py b/wiki/conf/settings.py
--- a/wiki/conf/settings.py
+++ b/wiki/conf/settings.py
@@ -93,6 +93,25 @@
     )
 )
 
+# Allowed inline styles, default is no styles (empty list)
+MARKDOWN_HTML_STYLES = (
+    getattr(
+        django_settings,
+        'WIKI_MARKDOWN_HTML_STYLES',
+        []
+    )
+)
+
+_project_defined_attrs = getattr(
+    django_settings,
+    'WIKI_MARKDOWN_HTML_ATTRIBUTE_WHITELIST',
+    False)
+
+# If styles are allowed but no custom attributes are defined, we allow styles
+# for all kinds of tags
+if MARKDOWN_HTML_STYLES and not _project_defined_attrs:
+    MARKDOWN_HTML_ATTRIBUTES['*'] = 'style'
+
 
 # This slug is used in URLPath if an article has been deleted. The children of the
 # URLPath of that article are moved to lost and found. They keep their permissions
diff --git a/wiki/core/markdown/__init__.py b/wiki/core/markdown/__init__.py
--- a/wiki/core/markdown/__init__.py
+++ b/wiki/core/markdown/__init__.py
@@ -40,6 +40,7 @@ def convert(self, text, *args, **kwargs):
                 html,
                 tags=settings.MARKDOWN_HTML_WHITELIST,
                 attributes=settings.MARKDOWN_HTML_ATTRIBUTES,
+                styles=settings.MARKDOWN_HTML_STYLES,
             )
         return html
 


Test patch: