Opened 5 years ago
Closed 5 years ago
#30538 closed Bug (wontfix)
Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin.
Reported by: | Loo Zheng Yuan | Owned by: | nobody |
---|---|---|---|
Component: | Utilities | Version: | dev |
Severity: | Normal | Keywords: | slugify prepopulated fields |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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 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 prepopulated_fields to generate a slug. The relevant javascript function seems to be found 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 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 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 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?
Change History (1)
comment:1 by , 5 years ago
Component: | Uncategorized → Utilities |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Summary: | Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin → Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin. |
Type: | Uncategorized → Bug |
Version: | 2.2 → master |
Thanks for this report.
slugify()
andURLify
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 follow triaging guidelines). Please see an old thread on the django-developers. You can leave your comment there if you think that this behavior should be changed.