Opened 13 years ago

Closed 10 years ago

#3818 closed (wontfix)

Expose chosen settings to default context processor.

Reported by: ciantic@… Owned by: Adrian Holovaty
Component: Core (Other) Version: master
Severity: Keywords: expose_settings
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Gives user an ability to expose wanted settings to the default context processors, and when you control it from the only security risk is: stupid settings creator. Also it gives you control what to expose, if in future user might want to expose something else from there too.
It could be set by default to that.

There is no point to write multiple settings reading context processors, this is the settings context processor. If your application needs some other setting, then you expose it to the app.

Attachments (2)

context_processors.diff (420 bytes) - added by ciantic@… 13 years ago.
exposed context processor that handles reading of settings in context wise
context_settings.diff (1.1 KB) - added by m@… 10 years ago.
context processor for exposing settings in templates.

Download all attachments as: .zip

Change History (6)

Changed 13 years ago by ciantic@…

Attachment: context_processors.diff added

exposed context processor that handles reading of settings in context wise

comment:1 Changed 13 years ago by Chris Beaven

Triage Stage: UnreviewedDesign decision needed

It's come up before, but this is a slightly different take.

comment:2 Changed 13 years ago by Adrian Holovaty

Resolution: duplicate
Status: newclosed

Duplicate of #1278, which has been marked as a wontfix.

comment:3 Changed 10 years ago by m@…

Resolution: duplicate
Status: closedreopened

I don't think this is a duplicate of the MEDIA_URL ticket.

I think that it would simplify some development scenarios to be able to expose selected settings in the templates instead of having to write one-off context processors for every single one. This seems particularly useful for people who have custom settings. My usecase for this is a Google Analytics ID - I don't want GA to fire while I'm doing testing on my dev machine, so my dev has GA_ID set to "FOO" while the prod on has the real ID, and in my template I simply have {{ settings.GA_ID }}

I'm attaching a patch that is similar to the original one, with two differences:

  1. settings are placed in a context dict named 'settings' to avoid collisions and to improve readability, so a setting would be accessed from the template as {{ settings.FOO }}
  2. I've added the suggested defaults to

Changed 10 years ago by m@…

Attachment: context_settings.diff added

context processor for exposing settings in templates.

comment:4 Changed 10 years ago by Russell Keith-Magee

Resolution: wontfix
Status: reopenedclosed

This was marked Wontfix for a reason, and your patch doesn't address that reason.

The solution to every problem isn't "add a new setting". In this case, the solution is "write your own context processor".

Note: See TracTickets for help on using tickets.
Back to Top