[Django] #30538: Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin

28 views

Skip to first unread message

Django

unread,

Jun 2, 2019, 12:51:26 PM6/2/19

to django-...@googlegroups.com

#30538: Inconsistent slug generation behaviour of slugify() and prepopulated fields
in Django Admin
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
nomenklature |
Type: | Status: new
Uncategorized |
Component: | Version: 2.2
Uncategorized | Keywords: slugify
Severity: Normal | prepopulated fields
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Hi everyone. I wanted to highlight an inconsistent slug generation
behaviour that I noticed.

So, for generating slugs, there are two ways I can go about doing it. One
way is by using the
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/utils/text.py#L393
django.utils.text.slugify()] function to create a slug. This behaviour
allows us to create a default for a model field by modifying the save()
function, etc. Another way, if you are using Model Admin, is by using the
[https://docs.djangoproject.com/en/2.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields
prepopulated_fields] to generate a slug. The relevant javascript function
seems to be found
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/contrib/admin/static/admin/js/urlify.js#L161
here].

Interestingly, and pretty obviously after viewing the differences between
the two codes, they result in slightly different slugs. For a string like
`How To Maintain Coke Diet` will have the following inconsistencies:

Via
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/utils/text.py#L393
django.utils.text.slugify()]: `how-to-maintain-coke-diet`
Via prepopulated_fields: `how-maintain-coke-diet`

On closer analysis, it seems that this was the case because of the
following code in
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/contrib/admin/static/admin/js/urlify.js#L161
django/contrib/admin/static/admin/js/urlify.js]:

{{{
// Remove English words only if the string contains ASCII
(English)
// characters.
if (!hasUnicodeChars) {
var removeList = [
"a", "an", "as", "at", "before", "but", "by", "for",
"from",
"is", "in", "into", "like", "of", "off", "on", "onto",
"per",
"since", "than", "the", "this", "that", "to", "up", "via",
"with"
];
var r = new RegExp('\\b(' + removeList.join('|') + ')\\b',
'gi');
s = s.replace(r, '');
}
}}}

With that, I recognise that there may be reasons accounting for the
inconsistencies. One could also argue that I can just stick to using the
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/utils/text.py#L393
django.utils.text.slugify()] function, but I value the ability to
prepopulate slug fields from Django Admin (of course with a more
standardised behaviour).

Perhaps someone can weigh in on this and see if we can or should
standardise the implementation of both?

--
Ticket URL: <https://code.djangoproject.com/ticket/30538>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Jun 3, 2019, 3:32:32 AM6/3/19

to django-...@googlegroups.com

#30538: Inconsistent slug generation behaviour of slugify() and prepopulated fields

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by felixxm):

* status: new => closed
* type: Uncategorized => Bug
* component: Uncategorized => Utilities
* version: 2.2 => master
* resolution: => wontfix

Comment:

Thanks for this report. `slugify()` and `URLify` behave differently since
their introduction in dd5320d1d56ca7603747dd68871e72eee99d9e67 and
ed114e15106192b22ebb78ef5bf5bce72b419d13 in 2005. Changing this behavior
would be backward incompatible, that's why I'm marking this as "wontfix"
(see [https://docs.djangoproject.com/en/stable/internals/contributing
/triaging-tickets/#closing-tickets follow triaging guidelines]). Please
see
[https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!searchin
/django-developers/urlify|sort:date/django-
developers/X2JZV7cMtD4/m8gtBmixXcsJ an old thread on the django-
developers]. You can leave your comment there if you think that this
behavior should be changed.