I wasn't sure if my setup supported sessions properly. This view helped me make sure. Usage: fill the inputs with text and make sure that these values traverse a couple of requests. If it doesn't work then maybe the session backend you've set is broken?
A quick-and-dirty, and extremely simple, decorator to turn a simple function into a management command. This still requires you to have the management directory structure, but allows you to name your primary method whatever you want, and encapsulates the basic functionality of an argument-accepting management commmand. The function's docstring will be used for the command's help text if the `help` arg is not passed to the decorator. Simple usage: from myapp.utils import command @command() def my_command(): print "Hello, world" I'm not too familiar with the intricacies of decorators and management commands, so this could probably (most likely) be improved upon, but it's a start. **Update**: I've taken this a bit farther and put my work up on bitbucket: https://bitbucket.org/eternicode/django-management-decorators/src
A file storage which uses a more sane rename method for existing files. Add `DEFAULT_FILE_STORAGE = 'site.storage.BetterNameFileSystemStorage'` (obviously changing `site.storage` to the module which you put this inside)
This is an extremely simple example but from here the possibilities are almost endless :)
I use Django's built-in development server all the time, but get tired of typing out the command to run it, and if I'm testing some custom admin css/js, I *really* get tired of typing out the command that correctly directs the middleware to use my admin media dir. So I added this alias to my .bashrc and when I'm in a project's root, I just type 'pyserver' and the development server fires up, automatically passing an --adminmedia arg if I have some custom admin media for the project (otherwise it's 'runserver' as always). Note: This relies on the convention that my custom admin media will be in a folder called admin_media that resides at the project's base. Of course, change it to whatever convention you use. I'm not a bash expert or anything, but this works for me ;)
I don't know how robust or secure this is, but it's working for me so far.
For disabling autocomplete and security purpose, this snippet defines a CharField with a randomness name for each request of the form. This is useful for turning off autocomplete for credit card input in all browsers, without breaking the xhtml validation. * [https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML#Security](https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML#Security) * [http://en.wikipedia.org/wiki/Cryptographic_nonce](http://en.wikipedia.org/wiki/Cryptographic_nonce)
A filter to integrate Google Closure compiler in django-compress plugin. 1. [download django-compress](http://code.google.com/p/django-compress/) 2. install it 3. [download Closure Compiler](http://code.google.com/closure/compiler) 4. put the jar at the root of your project 5. put this snippet as a **__init__.py** file in a **google_closure** directory in the filters directory of the plugin 6. add `COMPRESS_JS_FILTERS = ('compress.filters.google_closure.GoogleClosureCompilerFilter',)` to your settings.py You can test `COMPRESS_CLOSURE_JS_ARGUMENTS = {'compilation_level': 'ADVANCED_OPTIMIZATIONS', }` in your settings.py too
The built-in escape filter only works with certain characters. It works great in environments where you can declare your charset (UTF-8). However, not everything can handle anything outside of the ASCII charset. This replaces all non-ASCII characters with their encoded value as `®` for ®, for example.
This templatetag let's you output a form with select boxes instead of the ul's for filters. Uses some hacks to get the param names out of query strings. This would be a lot easier if filterspecs defined params instead of query strings (if filter tag would handle the encoding)
**The problem** ModelChoiceField always uses __unicode__ or __str__ to fill the labels. I needed to dynamically select which field to use for the labels. **The solution** My approach copies a lot from [this blog](http://oebfare.com/blog/2008/feb/23/overriding-modelchoicefield-labels/) with some modifications to make it more dynamic. There are some proposals to fix on this [Ticket #4620]( http://code.djangoproject.com/ticket/4620) **How to use** Include the code on your forms.py (or whatever you are using) and use the CustomChoiceField with the extra argument label_field instead of ModelChoiceField. Hope it helps someone.
Automatically activates the virtualenv when running manage.py command. Just create requirements.pip file inside the root of django project and run ./manage.py update_ve in first time. Code checks requirements.pip and virtual env timestamps and require to recreate outdated environment.
Extra field for slugs that does the work. If the slug value is given, the value is not recreated but correctness is ensured. If value is not given, the field regenerates the slug.
Just like it says -- set it up and run. Use it for server migrations, for project handoffs, in cron jobs, you name it. I have never had problems exporting models to individual fixtures in this way, and only one bout of trouble re-importing them (and that was, like, an impossible-triangle of OneToOneField dependencies anyway, and they were going from a sqlite file to a postgres schema that totally had inappropriate nullable columns in it). I find that the json files named for what they contain is helpful when and if manage.py does freak out during an import, as the output from `loaddata` command is so opaque it's autistic, basically. A trivial refactoring effort could make it into a management command -- it already makes use of the builtin `dumpdata` command class internally. However I did not feel like overthinking it enough to set it up in a repository (doubtlessly padded with unrelated 'utilities' and explanatory .rst files) and then writing a blog post to sell it to you. That is why you are reading this code here, instead of on GitHub. Don't get me wrong, GitHub is awesome, and like a consummate host... but not the way I love me some quick and dirty snippet code, these days. Whatever, you say lazy, I say productively relaxed, potato/potahto. Erm. In any case please do enjoy this model fixture-exporter. Yes.
This is an addition to Django's cache_page decorator. I wanted to cache pages for anonymous users but not cache the same page for logged in users. There's middleware to do this at a site-wide level, and it also gives you the ability to partition anonymous users, but then you have to tell Django which pages not to cache with @never_cache.