django-comments-xtd | Django comments app with thread support | Notification library

Django has its own optional Sites framework which is distinct from Wagtail's concept of sites. In the standard Wagtail project template this is turned off (i.e. django.contrib.sites is left out of INSTALLED_APPS) but your project may have it enabled, particularly if you integrated Wagtail into an existing Django project. Like Wagtail, Django's site records are kept in the database, and I suspect this is where the example.com reference is hiding - if you have the Django admin site enabled (as distinct from the Wagtail one), you should find a Sites model listed in there.

Digging into the django-comments-xtd and django-contrib-comments code shows that the URL returned by the {% get_comment_permalink %} tag is ultimately handled by the django.contrib.contenttypes.views.shortcut view, which is indeed listed as making use of the Django sites framework.

As for why adding a second Wagtail site circumvents the problem: when Wagtail generates page URLs, it will prefer to return local URLs without the domain (e.g. ) when it can do so unambiguously - as is the case when only one Wagtail site is defined. Once you add a second site, it switches to a full URL including the domain - and at that point, Django recognises that it's been passed a full URL and doesn't try to apply its own site logic to 'fix' it up.

In your INSTALLED_APPS,in settings.py, If django.contrib.auth is above your app, DJANGO will render the default auth , So what you should do is place your app above the django.contrib.auth so that DJANGO will render yours first.

That works for me