(It feels like "best practices" type of question, sorry if these don't belong here)
I'm building a website which has user registration and password reset feature, both of which would send email to the user with a link to click to complete the respective process. While testing on a staging box, I used a dirty workaround in order finish the Proof Of Concept - hardcoded the website address in the template ) Needless to say, I want to fix this sooner rather than later. Searching around, found references to django.contrib.sites, which looks like a possible solution, though one thing bothers me - technically there's but one site, but with two stages, staging and production. I don't want to swim against the current, potentially abusing "sites", where another solution might apply.
I've then considered another approach - add respective URLs to corresponding settings.py files, of which I already have a grasp - one for local, one for staging, and one for prod. The issue here is probably obvious - I don't think it's proper (or possible) to read the settings.py from templates, and trying to keep the solution as simple as possible, I'm using a few standard views, which means I don't have access to the code thereof, to add values to the context. Perhaps I am supposed to override these standard views? Just call 'super' and then add my custom data to the context? But I don't know if this is a right approach tbh.
The third option seems to be adding a custom context processor to achieve the same goal, i.e. making settings values available to the templates that are interested therein. Sorry about a long question of "design" variety.
ok, so it was a wrong path after all - the reason why {{ domain }} in my template didn't work (resolved to 'localhost') was a missing line in nginx config:
location / {
proxy_pass http://unix:/run/gunicorn.sock;
proxy_set_header Host $http_host;
}
(the proxy_set_header line, to be exact)
can't claim I understand 100% what's happening here, but at least now I can move forward; the biggest question is where this {{ domain }} directive comes from - can't tell which of the several context processors copied from a tutorial put it in:
"django.template.context_processors.debug",
"django.template.context_processors.request",
"django.contrib.auth.context_processors.auth",
"django.contrib.messages.context_processors.messages",