Django forms add placeholder from help text template tag
This snippet will change the field to include the placeholder in the field using the help_text attribute from the model or the form
- template
- tag
- forms
- help_text
- Django
- placeholder
This snippet will change the field to include the placeholder in the field using the help_text attribute from the model or the form
Some INSTALLED_APPLICATIONS applications may not be critical for your website to work - for example you may only need them for development - like 'django_extensions' or 'debug_toolbar'. They needn't be installed actually for the site to work. This way you can avoid discussions with other developers if some application should be included, or is it just spam, because if they don't like it, they don't have to install it. On a production server you can leave this not installed, to avoid security concerns like a possibility to IP-spoof and see the debug toolbar.
Model Field allowing to store multiple emails in one textual field. Emails separated by comma. All emails are validated. Works with Django admin.
A function extends of Tarken's django-excel-response django-excel-response 1、djangosnippets - http://djangosnippets.org/snippets/1151/ 2、pypi - https://pypi.python.org/pypi/django-excel-response/1.0 When using Tarken's django-excel-response. We find that Chinese is messed code when we open .xls in Mac OS. As discussed in http://segmentfault.com/q/1010000000095546. We realize django-excel-response2 Based on Tarken's django-excel-response to solve this problem By adding a Param named font to set font.
@vary_on_user doesn't work properly if your site uses third-party cookies, since the cache key is created from *all* of the cookies in the request header. This decorator caches pages based on the user ID, so it works reliably.
Yet another authentication by email address. This one is quick and dirty as we are saving email address in both Username and Email fields. For proper way how to deal with it see https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#auth-custom-user
Use this class to authenticate against Usercake (http://usercake.com/) password strings. When importing passwords from Usercake, the database values should be prefixed with "usercake$".
Store in SiteID a local var store for save SITE_ID thread-safe and set it with middleware. It's base on https://djangosnippets.org/snippets/1099/ but with call to local() in SiteID and using custom models for web site and domains.
Fixed-point model field based on `IntegerField` and `DecimalField`. Represented as `Decimal` in Python for accurate calculations, stored as integer in the database. Configurable decimal places, defaults to 2.
Everybody know about long spagetty-style settings file for django :-) I tried to find any cool settings loader, but have no luck.I created this one myself. Ok, we forgetting about `settings.py` and creating module settings (folder named settings with file `__init__.py`). This `__init__.py` file have preloader for modules placed in settings folder and `../settings_local.py` (if exists) at the end. settings_local is awesome tool, when you use any VCS like git and have settings in vcs, but for example you have different database connection settings. You can change this settings in settings_local. Settings splitter have variable moduleweights. This variable declares weights for selected modules to allow loader sort modules by priority and use already defined settings in each other loaded module. You can define your custom modules and weights there. Ok, now few examples. settings/env.py import os # Quick-start development settings - unsuitable for production # See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/ DEBUG = not 'http/ask.helldude.ru/' in os.path.realpath(__file__) settings/assets.py # Static files (CSS, JavaScript, Images) # https://docs.djangoproject.com/en/1.6/howto/static-files/ import os import sys settings = sys.modules['project.settings'] STATIC_URL = '/static/' STATIC_ROOT = os.path.join(settings.BASE_DIR, 'static') STATICFILES_DIRS = (os.path.join(settings.BASE_DIR, "project/static"),) STATICFILES_FINDERS = ( 'django.contrib.staticfiles.finders.FileSystemFinder', 'django.contrib.staticfiles.finders.AppDirectoriesFinder', 'compressor.finders.CompressorFinder', ) settings_local.py: import sys settings = sys.modules['project.settings'] print 'I WAS LOADED KHA KHA KHA' if settings.DEBUG: print 'In debug mode' You can see amazing 'hack' there :-) I use already defined settings via sys.modules['project.settings'] (where project is common folder for my project applications). I hope you like this small lifehack for django settings! rudude.
This widget is based on django foreign key form field, but its completely dynamic.
This is a class I use instead of the default PayPalPaymentsForm in django-paypal. I wanted to use the Paypal sandbox on my development site and the real Paypal site on my production site. Currently, if you want to output the Paypal form with the sandbox you have to call the sandbox() method on the form, rather than the render() method. Using this class instead of the default PayPalPaymentsForm, you can just set PAYPAL_DEBUG to True in the settings file and the form will take you through to the sandbox instead. Don't forget to set the sandbox merchant account's business email address as PAYPAL_RECEIVER_EMAIL too.
Use this class to authenticate against Drupal 7 password strings. When importing passwords from Drupal, the database values should be prefixed with "drupal$". In contrast to the two present solutions, this class also works with passwords which were imported to Drupal 7 (e.g. from Drupal 6 or phpBB) and with passwords with variable iteration numbers. It is possible to use this class for encoding passwords, but due to questionable design decisions in Drupal (like truncating the non-standard base64 encoded hash at 43 characters) I'd recommend to do this this only if you really need to be able to migrate back to Drupal.
Geocode lookup formats using Nominatim queries.
It's haystack whoosh backend code which involves stemming for specific language in time of indexing. 2 lines was changed comparing to original whoosh backend (StemmingAnalyzer replaced with LanguageAnalyzer for russian language, list of supported languages: [here](https://bitbucket.org/mchaput/whoosh/raw/default/src/whoosh/lang/snowball/__init__.py) )