Opened 6 years ago

Last modified 7 weeks ago

#18620 assigned Cleanup/optimization

Prefer current Site when checking M2M in "shortcut"/"view_on_site" redirect

Reported by: Mike Tigas Owned by: Paulo
Component: contrib.contenttypes Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


Given an object with a many-to-many relationship to django.contrib.sites.models.Site, the django.contrib.contenttypes.views.shortcut view simply picks the first domain returned, basically obj.<field>[0].domain. ( -- it even notes that the ordering is arbitrary.)

This can be confusing when operating several (shared database) Django sites where sometimes content is cross-posted between said sites.

Example that led to my noticing this issue: A story being edited on but posted to sites [,] redirects you to story's representation on the latter website when clicking "view on site" in the admin (or using anything else that uses that underlying shortcut view). (Ostensibly because "" sorts before "" and is therefore picked by the simple code I linked above.) Although this is a theoretically acceptable thing to happen, it's confusing to (even technical) users because they're on one of the acceptable sites for the content object and do not expect to be redirected to another site.

I propose that the view should prefer the current site in the event that both of the following are true:

a) the content object "Site" field is an M2M
b) the current Site object is one of the values set in that M2M

This shouldn't change behavior in any other circumstance (current site not in that M2M, site field is not M2M, etc), but it should alleviate some confusion to this specific usecase.

Have code and will post in a GitHub fork shortly.

Change History (8)

comment:1 Changed 6 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted

This makes sense and is backwards compatible.

comment:2 Changed 6 years ago by Mike Tigas

Has patch: set


Pull request:

Test isn't the best but does fail without the patch / tests the behavior pretty well.

Last edited 6 years ago by Mike Tigas (previous) (diff)

comment:3 Changed 6 years ago by Mike Tigas

Also I'm on the fence as to whether or not it should optimize and not query for current_site until absolutely necessary (i.e. use lazy or use some if-blocks). Basically to avoid one unnecessary query in the situation if we have a site FK.

comment:4 Changed 4 years ago by Tim Graham

Patch needs improvement: set

comment:5 Changed 8 months ago by Paulo

Owner: changed from nobody to Paulo
Status: newassigned

comment:6 Changed 8 months ago by Paulo

Patch needs improvement: unset

comment:7 Changed 2 months ago by Carlton Gibson

Triage Stage: AcceptedReady for checkin

comment:8 Changed 7 weeks ago by Tim Graham

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted
Note: See TracTickets for help on using tickets.
Back to Top