0

(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.

alexakarpov
  • 1,848
  • 2
  • 21
  • 39
  • 1
    Have you tried get the site url from request object? https://stackoverflow.com/questions/2345708/how-can-i-get-the-full-absolute-url-with-domain-in-django – kmmbvnr Jan 09 '22 at 05:22
  • 1
    If you need add data in context that is not available in request as mentioned by @kmmbvnr then it is commen practice to overwrite get_context_data(..) for class based views. If you have many class based views with the same need then place your on get_context_data in a Mixin. There is many examples here on Stackoverflow – Razenstein Jan 09 '22 at 05:35
  • thanks to both of ya; turned out there's the {{ domain }} thing already available in templates, and the reason it wasn't working was a missing line in nginx config – alexakarpov Jan 09 '22 at 06:13
  • the question remains however - which of the existing context processors creates that 'domain' ? These all came from a tutorial I was using building the core of the site, and now I wish I knew LOL – alexakarpov Jan 09 '22 at 06:29

1 Answers1

0

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",
alexakarpov
  • 1,848
  • 2
  • 21
  • 39