Extending contrib.sites.get_current_site logic

21 views
Skip to first unread message

Aubrey Falconer

unread,
Oct 1, 2018, 7:29:45 AM10/1/18
to Django users

What is the best-practice pattern to replace/extend functionality in django.contrib libraries?


My use case in this instance is to add domain alias awareness to the contrib.sites library. I've already created a customized sites library that incorporates the additional model updates and logic we need, but other third-party libraries we use (allauth, for example) are directly calling django.django.contrib.sites.models.objects.get_current(). We've begun maintaining a local fork of each of these libraries to update the call to point to our customized sites lib instead. Is there a more efficient solution for this?

Jason

unread,
Oct 1, 2018, 8:31:43 AM10/1/18
to Django users
The only other alternative that comes to mind is maintaining a fork of django itself and overwriting the specific parts of `contrib.sites` that you need to modify.  Because the third part libraries are so tightly integrated with that bit of django and I don't think there's a method to specify an alternative, like AUTH_USER_MODEL is available for custom user models.

This is a good example of how modularity in packaging for django could be beneficial, because you could then make your own implementation of sites and import it with the same convention as the default package

Aubrey Falconer

unread,
Oct 2, 2018, 3:55:53 PM10/2/18
to Django users
Jason, thanks for your response. An AUTH_USER_MODEL type extension mechanism is what was looking for. It's useful to know that nothing like this exists out of the box, and that forking either third-party libraries or Django itself is the clear path forward. 
Reply all
Reply to author
Forward
0 new messages