Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Munin-like dashboard for Django websites
Django-utils has a pluggable dashboard app for building munin-like graphs. -
Wordpress to Django: Designing Compatible URLs in urls.py
As I mentioned in my previous post, there are a few fairly easy strategies for maintaining the stable URLs for your content when migrating from WordPress to a local Django driven blog. Django allows you a high level of control over URL formats so it's fairly simple to design them to be compatible with WordPress URLs. Additionally WordPress has been around long enough that the standard URL re-write formats follow suggested best practices for content, so bringing your Django URLs in alignment with that is not only useful for migrating content but good practice overall. That said the two most common formats for URLs in WordPress are: http://<domain>/<4 digit year>/<1 or 2 digit month/<1 or 2 digit day/<slug>/ so for example the URL for the previous post linked above is... http://www.flagonwiththedragon.com/2011/06/01/wordpress-to-django-strategies-dealing-with-WordPress-querystring-urls/ The next most common format for URLs is similar and differs mostly in how months are abbreviated: http://<domain>/4 digit year>/<3 char month>/<1 or 2 digit day>/<slug>/ So an example of the same URL above in this format would be... http://www.flagonwiththedragon.com/2011/jun/01/wordpress-to-django-strategies-dealing-with-WordPress-querystring-urls/ Designing urls.py in Django to accomodate this is simply: # URL format where month format is abbreviated character format. url(r'^(?P\d{4})/(?P\w{3})/(?P\d{1,2})/(?P[0-9A-Za-z-]+)/$', 'post_detail_alt'), url(r'^(?P\d{4})/(?P\w{3})/(?P\d{1,2})/$', 'post_day_alt'), url(r'^(?P\d{4})/(?P\w{3})/$', 'post_month_alt'), # URL format where … -
Getting prepaid mobile internet in NL
Getting prepaid mobile internet in NL UPDATE: when you register for the extra € 5 credit on My Vodafone, enter a (fake) Dutch address. One attendee was refused for registration when entering a foreign address, and was then refused for registration because his number was supposedly already registered. Coming to DjangoCon from abroad? Mobile roaming is usually expensive, so if you want to use internet on your phone, it’s best to get a Dutch prepaid SIM card. For € 7.50, you can get 1 GB data. Tethering is technically not allowed, but they probably don’t actively check for this. The only option with acceptable pricing are two different SIM types from Vodafone. Note: I have not tested these instructions myself. Use them at your own risk. This is all based on the Dutch Vodafone website. If you find any issues with them, please let me know :) What to buy Buy either one of these SIM cards: Vodafone Prepaid SIM only Meerwaarderen (€ 7.50). This includes € 10 credit but does not include any data. Not available in microsim. Vodafone Prepaid Smartphone Sim Only 1GB (€ 20). This includes € 10 credit and a 1 GB data package. Also available … -
Django "view-permissions" for related objects
You have a model A with a relation to another model B. In the Django admin, you have full permissions for model A and none for model B. However, if you create a new object for model A, you need to select a related object from model B. Tough luck: Permission denied! -
Allow squid/mod_wsgi to pass the HTTP_AUTHORIZATION header to Apache
-
Using Fabric to update a remote svn checkout with ssh public key authentication
-
Using mysql load data infile with django
-
Angelo Dini is a core developer
Angelo Dini is a core developer -
Using the Django-Pagination app in Django 1.3
Like many Djangonaughts I use django-pagination as my primary means to page results on lists pages and between the differences on the original Google project page(1.0.5 is the last downloadable version), what appears to be the same project migrated to GitHub and the PyPi (1.0.7 is the pip install version) site for the project, things can get confusing. I'm probably the only person confused by this but it appear that the GitHub site is the most up to date and it appears to be in sync with the pip install version. Life signs overall are dubious on the project though with no updates having come since early 2010 and several (what seem to be) reasonable pull requests sitting in the project queue. One gotcha I wanted to point out in the PyPI readme file is the directions for TEMPLATE_CONTEXT_PROCESSORS: According to the project documentation, in settings.py you should set: 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" ) This can cause some problems in Django 1.3 however since the default TEMPLATE_CONTEXT_PROCESSORS have changed, in particular to support the new features for serving static media. So to include for pagination to work and to keep the default template context processors you should instead set: … -
Free bikes
Free bikes The City of Amsterdam is offering participants of DjangoCon a free bike for the duration of the conference. You can collect a voucher on monday during lunch. -
Test static resources in Django tests
At Mozilla we use jingo-minify to bundle static resources such as .js and .css files. It's not a perfect solution but it's got some great benefits. One of them is that you need to know exactly which static resources you need in a template and because things are bundled you don't need to care too much about what files it originally consisted of. For example "jquery-1.6.2.js" + "common.js" + "jquery.cookies.js" can become "bundles/core.js" A drawback of this is if you forget to compress and prepare all assets (using the compress_assets management command in jingo-minify) is that you break your site with missing static resources. So how to test for this?[367 more words] -
Test static resources in Django tests
At Mozilla we use jingo-minify to bundle static resources such as .js and .css files. It's not a perfect solution but it's got some great benefits. One of them is that you need to know exactly which static resources you need in a template and because things are bundled you don't need to care too much about what files it originally consisted of. For example "jquery-1.6.2.js" + "common.js" + "jquery.cookies.js" can become "bundles/core.js" A drawback of this is if you forget to compress and prepare all assets (using the compress_assets management command in jingo-minify) is that you break your site with missing static resources. So how to test for this?[367 more words] -
Test static resources in Django tests
At Mozilla we use jingo-minify to bundle static resources such as .js and .css files. It's not a perfect solution but it's got some great benefits. One of them is that you need to know exactly which static resources you need in a template and because things are bundled you don't need to care too much about what files it originally consisted of. For example "jquery-1.6.2.js" + "common.js" + "jquery.cookies.js" can become "bundles/core.js" A drawback of this is if you forget to compress and prepare all assets (using the compress_assets management command in jingo-minify) is that you break your site with missing static resources. So how to test for this?[367 more words] -
Test static resources in Django tests
At Mozilla we use jingo-minify to bundle static resources such as .js and .css files. It's not a perfect solution but it's got some great benefits. One of them is that you need to know exactly which static resources you need in a template and because things are bundled you don't need to care too much about what files it originally consisted of. For example "jquery-1.6.2.js" + "common.js" + "jquery.cookies.js" can become "bundles/core.js" A drawback of this is if you forget to compress and prepare all assets (using the compress_assets management command in jingo-minify) is that you break your site with missing static resources. So how to test for this?[367 more words] -
JavaScript Libraries Statistics
-
Django models ForeignKey and custom admin filters…
… or how to limit dynamic foreign key choices in both edit drop-down and admin filter. The problem: Having a foreign key between models in django is really simple. For example: Unfortunately in the real live the choices allowed for the connection are frequently limited by some application logic e.g. you may add answers only [...] -
Conference available on Guidebook
Conference available on Guidebook Guidebook is a mobile app for your iPhone or Android phone and can store information of any conference, such as the schedule, sponsor information and a map of the venues. You need to have an internet connection to download the conference information but once it’s downloaded, you can access it offline. Handy when you are from abroad! Grab it here and look for the DjangoCon Europe 2011 guide once it’s installed. -
Updates to the django-utils task queue
After several months of running the task queue bundled with django-utils, I decided to re-evaluate certain aspects of the design. This post describes those changes. -
Wordpress to Django: Strategies Dealing with Wordpress Querystring URLs
Stable URLs are the foundation of valuable information on the web. As Tim Berners-Lee eloquently described it "Cool URIs Don't Change" and I thought I'd address a few strategies and code I'm using in MetaRho for maintaining stable URLs for content migrating from Wordpress. Wordpress Querystring URLs By default Wordpress uses querystrings for accessing content, passing the internal ID number of the post through the 'p' attribute like so... http://<domain name>/index.php?p=<post id> So for example calling post id 1 on mydomain.com would look like. http://www.mydomain.com/index.php?p=1 Since best practice for Cool URIs and in Django is to use real URLs instead of Querystrings this presents a small problem. The easiest solution I found is to simply implement a decorator in Django that I put on the default index view to watch for incoming WordPress querystring URLs and query some extra field on the model for blog posts that holds the original WordPress ID number. Note I do NOT try to maintain ID numbers between posts as the better practice is to keep these opaque from the user. I use the common strategy of keeping a one to many Model related to my posts to contain key value pairs for extra data. In … -
Django comparison grid
Comparison grid django application allows creating comparison grids, attaching arbitary content types to grids and editing grid content through django admin interface. If there is something you would like to see, get in touch – or just fork it on GitHub, add the feature (with docs and tests, preferably!) and send me a pull request: https://github.com/bmihelac/django-comparison-grid And here are two screenshots. Admin interface: Example output: -
Django Class-based Views
Since the release of Django 1.3, developers can choose to use class-based views in their web apps. Since the announcement of class-based views, there has been said a lot about them. As with all changes, there are pros and cons, people who are excited and people who are disappointed. I, and I guess a lot of people with me, are excited by the class-based views, but disappointed by the documentation Django gives with them. Time to try to clear things up.What do I like about Django's class-based views?Well, to start with: consistency. It might sound a bit lame, but I think it's a great thing that, following models and forms, views are now also part of the class-based club. I somehow always thought it was weird to write your forms and models in a class, but your views in a function. This weird feeling is now gone. Lucky me.Secondly: consistency. Again? Yes, again, because you can now force your own code to be more consistent, by using subclassing. You can, for example, write your own superclass view template and let all your other views subclass it.And last: Subclassing. I found it hard to find an example to make my point, … -
Django site permissions
I’m announcing Site permissions, django application that allows restricting access to objects based on which site they belong. Basic goal is to allow restrict managing site content to users and groups in django admin interface. Site permissions works on and depends on django-guardian. Source code and example app is available on githib: https://github.com/bmihelac/django-site-permissions -
Handy mod_wsgi process names
One of the reasons I started experimenting with gunicorn instead of mod_wsgi was that it would help me identify the sites when looking at cpu/memory usage with top. With standard apache+mod_wsgi, you only get line upon line of /usr/sbin/apache2 -k start with no indication of which site it actually is. Turns out mod_wsgi can do that just fine, too! I got a comment on my gunicorn blogpost from Diederik v/d Boor that told me about mod_wsgi's display-name option. It was right there in mod_wsgi's WSGIDaemonProcess documentation but I completely overlooked it. What I did was to add a display-name like this: WSGIDaemonProcess mysite display-name=mysite_wsgi user=xyz group=xyz In top you might have to press c to view the full commandline for every top line. (Tip: press W to write the top config to disk to persist the change). See this picture. It shows a couple of not-yet converted wsgi sites with the unhelpful /user/sbin/apache2 name and a couple with the sitename with _wsgi in it. -
Leverage browser caching in Django and Lighttpd
An easy optimisation that greatly improves your website’s speed is to leverage browser caching through appropriate HTTP response headers for static files (CSS, images, JavaScript, etc.). My favourite technique is to set long expiration timestamps and then to force browsers to reload updated static content by a slight change in the file path. This technique is fairly easy to set up in Django and Lighttpd. -
Single simple view for Django form processing
I always feel a bit dissatisfied with the amount of code I have to put in to process forms in Django views. Like most python developers it feels like I've gotten too complex it if takes me more than 5 or 6 lines of code to do something. Previously I had coded seperate create and update views for form processing, partially this was to better control permissions but also because of the differences in dealing with bound and unbound forms as well as model instances. This is my first stab at implementing that simple logic based on several examples I've seen out there in other blogs. @login_required def post_edit(request, id=None): """ Handles creating or updating of individual blog posts. :parm request: request object being sent to the view. :param id: post id, defaults to None if new post. """ instance = None if id: instance = get_object_or_404(Post, id=id) title = "Create New Post" if instance: title = "Editing Post" # Create the form as needed. form = PostForm(request.POST or None, instance=instance) # Didn't work for me unles I passed k,v pair in instance. # Save the edited form if needed if request.method == 'POST' and form.is_valid(): # Validate and …
