This is a piece of middleware that reports the logged-in user back to Apache. This should cause the logged-in user to be present in the apache access log. Put it in `settings.MIDDLEWARE_CLASSES` after `AuthenticationMiddleware`. This has been tested with mod_python but does [not work with wsgi](http://groups.google.com/group/modwsgi/browse_thread/thread/8785a99d4ba7ee99).
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
I never found a good snippet or tutorial to get the app_list (in django.admin) on other pages except the index page. So i started asking on irc j00bar has given me a very nice answer, but first i didn't know what to do with it till now. Anyways this snippet is very handy for the people who wants this but don't know how to get it. This is special made for the django version 1.1 Installation is quite easy, it is a context processor, so download this file put anywhere in your project, i got it in a app called cms_theme (theme and template related stuff.) and put the location in your settings.py file, example: `TEMPLATE_CONTEXT_PROCESSORS = ( 'django.core.context_processors.auth', 'django.core.context_processors.debug', 'django.core.context_processors.i18n', 'django.core.context_processors.media', 'django.core.context_processors.request', '****cms.cms_themes.context_processors.theme', '****cms.cms_themes.context_processors.applist', )` The '****' stuff is nothing, i replaced my company name with it. Of course you may put the context processor anywhere else, that is your choice. Good luck! Alexander
This is some (probably) pretty dodgy code that allows for foreign keys in the admin's list_filter without using a custom FilterSpec. It overrides the django.db.models.options.Options get_field class to handle spanned relationships, i.e. list_filter=('house__room__town',) as seen in http://code.djangoproject.com/ticket/3400 I have only tested this with a double foreign key relationship('house__room'), and it worked. It hasn't been tested in production, and the troubling part of this code is probably to use of 'deepcopy'. I do add those copies back to the options instance, so there shouldn't be too much runaway copying.
Having things like DATABASE_NAME in the admin interface is handy if you're working on development and deployment systems. Replace the template admin/base_site.html with the template code. The variables to be displayed in the admin need to be exported into the environment before running the server. The python code shown is an example of a wsgi handler, and the same format can be used in manage.py for the development server.
When doing a list_filter on some object in the Django interface, every single item will be displayed. This is not always smart when very long list of choices can be displayed, even though the majority of these choices might not even exist in the database at all. Using this script will only display a filtering possibility for those items actually present in the database. This script is not generic, and you will need to change the lines noted "Change this", since I cannot know what exactly you need to filter. There is possibly a way to make this completely generic, and I hope this will inspire someone to make it!
Sets request.is_crawler Allow bot lockout from certain urls in urlconf ,add view parameter 'deny_crawlers' ex. url(r'^foo/$', 'views.foo',{'deny_crawlers' : True},name='foo') view param is removed after middleware pass.
CIDR ( http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing ) is a well-known IP range syntax. This CIDR_LIST class can be used to make ranges of IPs considered "internal" for Django's debugging and security purposes. (Django only ever needs to do "ip in INTERNAL_IPS" so __contains__ is sufficient for the purpose.) For example, to make localhost and the entire block of 10.0.0.* considered to be internal, use: INTERNAL_IPS = CIDR_LIST([ '127.0.0.1', '10.0.0.0/24' ])
OrderField for models from http://ianonpython.blogspot.com/2008/08/orderfield-for-django-models.html and updated to use a django aggregation function. This field sets a default value as an auto-increment of the maximum value of the field +1.
I had an issue with the django templating system, where by if I included several different files at the same level on one template.. and all the included templates extended the same base template. It would render the defined blocks for the first inclusion for all. i.e. everything in the parent that is being extended would be not updated for the subsequent inclusion. So, if anyone else has this problem. I have a solution that I sorta wanted for other reasons anyway. It's called a decorator tag, you can include and extend a template at the same time - in-line, with local context scoping so it only affects that tag. This is also a nice way to avoid creating .html files for simple extending purposes.
This snippet is helpful if you do a lot of editing on a single large admin form (for example, in a rich text field), and want to frequently save your progress. If you press control-S, or command-S on a Mac, the admin change form will save and reload, and the page will scroll back down to where you last were. This snippet relies on jquery, [jquery.cookie](http://plugins.jquery.com/project/cookie), and the [shortcut.js](http://www.openjs.com/scripts/events/keyboard_shortcuts/) keyboard library (which doesn't use jquery, but seemed more robust than the jquery keyboard plugins I saw). It uses a temporary cookie to remember where the page was scrolled to, to avoid having to override the admin behavior. Note: don't put this in templates/admin/change_form.html -- the circular import causes a Django crash. *Edit: Had forgotten to include jquery.cookie, which I was already including elsewhere.*
This allows you to access the choices (and their respective values) you create as a dictionary. It works great within django and it allows you to reference the choices as a dictionary (CHOICES[CHOICE1]) instead of CHOICES[0][0]... it is a tuple... but I mean, come on... what if you change the order? If you need the tuple just call CHOICES.choices and it will return the standard tuple.
A decorator that allows the programmer to restrict access to some views only to non logged-in users. For instance, if an user in logged in, it should be denied access to views like /accounts/register or /accounts/login.
example formset views for multiple image upload hope its useful ...
This is an improvement on other ButtonAdmin implementations. A few features : It allows you to specify whether button appears on change form or change list; whether the form is to be saved before the resulting function is called; whether the button should be displayed Look at the bottom of the snippet for usage. And make sure you admin urls are enabled using (r'^admin/', include(admin.site.urls)) instead of the old method