How to add STATIC files

You will most likely add STATIC files to your source code repository. As they are likely to be hardcoded in your code and templates it is a good idea to keep those and your STATIC files in sync.

Your STATIC files are collected (found and copied or symlinked) with the help of finders. This collection process might be a little confusing for you. Basically you don’t need to worry about where your files are copied, you just need to maintain the files in the locations I mention below. Collection process consolidates all your STATIC files for you, and it does it automatically.

If you are developing a reusable app place your STATIC files under the static directory. Your app directory should look like this:

$ ls -1
models.py
static/
templates/
views.py

If you are developing a project absolute filesystem paths listed in your STATICFILES_DIRS setting will be collected:

>>> from django.conf import settings
>>> settings.STATICFILES_DIRS
('/opt/myproject/src/project/static',)

One important thing to note, as I mentioned in the first part, is to set your STATIC_ROOT outside of your project directory. This is the location where all the STATIC files found will be consolidated. Making this directory independent from your project installation enabled its reuse.

How to upload MEDIA files

MEDIA files are typically uploaded by users when the project is online and a reference is stored in a model field. While this is true most of the time, MEDIA files can be generated by code and/or a reference can be provided in some other way that doesn’t involve models. But these edge cases are out of the scope of this post.

The easiest way to allow users upload their files is to use a FileField or ImageField on a model and derive a form from it:

from django.db import models
from django.forms.models import modelform_factory


class MediaModel(models.Model):
    media_file = models.FileField(upload_to='user_media')


MediaForm = modelform_factory(MediaModel)

You can then use this form to provide upload functionality:

def media_create(request):
    if request.method == "POST":
        form = MediaForm(request.POST, request.FILES)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect(reverse('media-list'))
    else:
        form = MediaForm()
    return render_to_response('usermedia/create/html', {'form': form})

Of course it is better to use a generic CreateView now we have them with Django 1.3. I wanted to emphasize one point and avoid the complexities of a class based view; you must pass request.FILES to the form’s constructor. Actually this is a good practice whether or not your form has an file field.

As in the case with STATIC files, MEDIA_ROOT should be in a location seperate from your project files. If you delete your project directory you would also lose MEDIA files otherwise.

Conclusion

This concludes Working with files in Django. I hope these posts are helpful to you. Once you are comfortable working with files I strongly recommend you to take a look at Django Compressor

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

How to setup file serving for development server

As I mentioned earlier, it is best to serve files on a fast HTTP server. But this setup is overkill for development environments, you can safely let Django handle your files. The snippet below relies on the assumption, behind the scenes, that DEBUG is always True in development environment and it is always False in production environment. It should be fine for the purposes of this post:

from django.conf.urls.static import static
from django.contrib.staticfiles.urls import staticfiles_urlpatterns

urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
urlpatterns += staticfiles_urlpatterns()

It is quite straightforward. Nothing gets added to urlpatterns unless DEBUG is True and prefix (MEDIA_URL and STATIC_URL) is not a fully qualified URL.

How to reference STATIC files in templates

There are two ways to reference any file. You can use a file’s location in your file storage (your filesystem for example) for internal use. Or you can build a URL for the file so that clients can access it. This post will cover the latter, as the former is a simple matter of applying os.path.join() to STATIC_ROOT and the particular file’s path.

To build a URL in your templates you can simply concetenate STATIC_URL with the file’s relative location to it:

<img src="{{ STATIC_URL }}myapp/img/logo.png" />

However, to have STATIC_URL available within your template context you need to make sure of two things:

• The template needs to be rendered with a RequestContext.
• django.core.context_processors.static needs to be included in TEMPLATE_CONTEXT_PROCESSORS setting.

I can’t think of a reason why, but if for some reason you are not using RequestContext, you can provide STATIC_URL using getstaticprefix tag:

{% load static %}
{% get_static_prefix as STATIC_URL %}

<img src="{{ STATIC_URL }}myapp/img/logo.png" />

How to reference MEDIA files in templates

Dealing with MEDIA files is much simpler. The FieldFile object returned by ImageField and FileField has path and url properties and you don’t need to do concetenation yourself:

<img src="{{ some_model.some_image_field.url }}" />

Next part deals with adding files to your project.

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 3
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

• Files that are hard coded in templates or in code. We will call them STATIC files.
• Files that are referenced in the code but only known in the run time. We will call them MEDIA files.

Now of course all these files are static and most of them can be classified as media, but I chose those terms because that more or less how they are referred to in Django documentation.

Since files are stored on disk or some other storage backend it is best to serve them on a fast HTTP server and let Django handle only dynamic content.

How to configure STATIC/MEDIA related settings

Let’s look at some code first and we can comment on it afterwards. I use the following setup in my projects:

import os

_PATH = os.path.abspath(os.path.dirname(__file__))

MEDIA_ROOT = os.path.join(_PATH, 'files', 'media')
MEDIA_URL = '/media/'

STATIC_ROOT = os.path.join(_PATH, 'files', 'static')
STATIC_URL = '/static/'
STATICFILES_DIRS = (
    os.path.join(_PATH, 'static'),
)
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)

ADMIN_MEDIA_PREFIX = '/static/admin/'

_PATH should be obvious. But the way I use it is a little tricky here. Basically I am using a files directory that contains media, for MEDIA files, and static, for STATIC files, directories. This seperation is essential. You will pull your hair if you don’t seperate those two from the beginning. This will allow you to reuse them easily if you deploy a new version to a different location.

But why is files under the project directory? Because we need to check-in STATIC files? NO! It is just a convenience for the development environments. I strongly suggest overriding MEDIA_ROOT and STATIC_ROOT in your deployment settings and basically move the files directory outside of the project path. STATIC files that we check-in resides in <_PATH>/static. django.contrib.staticfiles app collects your STATIC files from your project specific directories and within your apps and copies everything in the right places inside STATIC_ROOT.

To sum up the points above:

• Check-in STATIC files in a folder within your project directory (see STATICFILES_DIRS & FileSystemFinder). If you are developing an app AppDirectoriesFinder will collect static files within the static directory in your app directory.
• Seperate the directories, where your MEDIA files are saved and where your STATIC files are collected (see STATIC_ROOT & MEDIA_ROOT).
• Keep your STATIC_ROOT and MEDIA_ROOT outside of your project directory in production environment.

One more thing to note is STATIC_URL and MEDIA_URL should both have a trailing slash. This will save you a lot of trouble later.

Next part deals with serving files in development environment and referencing them in code and templates.

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 2
2. Working with files in Django – Part 3
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. Working with files in Django – Part 3

This might sound nice at first. If you are pirating music, movies or whatever, and feel guilty, this way you can say I'm paying my tax, therefore my conscience is clear. Pirating is suddenly legit, content is finally free as in free speech. Moreover there is a good sum of money in the Piracy Tax pool now. Yay! We saved the music industry (or content producers in general)! No, you didn’t. You just eased your conscience.

Let’s get real. Suppose you passed the bill of Piracy Tax at the parliament and a good number of people are paying this tax. That’s just one part of the equation. How will this money be distributed? What will determine the relative share between artists? Do we need distributors anymore? Do we even need producers anymore? And most importantly when you cap the total amount of earnings, will this have any negative effects on creativity? And finally which problem exactly is this Piracy Tax solving?

In the comments of Serdar Kuzuloğlu’s post, several people stated that it should be trivial to gather reliable statistics on downloads. This is not true at all. Even if there was a single distributor (I hope we agree this is undesirable) there will be statistical errors. No system is 100% reliable. But HTTP, i.e. web sites are especially not suitable for transactional operations. Aside from this fact, there will likely be a dozen of services. Are you just planning on adding the figures to calculate the final share? How about the differences in these services’ reach? Don’t you think simply adding the figures makes the system easy to game?

Something everybody seems to forget is there will be always piracy a.k.a P2P¹. It would take you to the wrong conclusion to assume everybody is the same. Not everybody is using Windows, not everybody has Flash, there are even people who doesn’t have a graphical browser. Do you even know what a text browser is?² It is not wise to ignore these people because they are the minority. These people are Internet residents, like it or not you are just tourists. They have practically invented the Internet. So please don’t make the mistake of ignoring the possible effects of technologies like tor and the culture of FLOSS.

In any case, statistical errors are unavoidable. I would suggest 3% is an acceptable error margin. Then what happens to the independent artist or the small production company that should have 0.25% and ends up having 0.025% share? Is this fair now? The pirate tax pool would likely benefit the big players and crush the independents. Big players have already been employing portfolio management strategies, independents just can’t do that. It is naive to think Piracy Tax could sweep so called low-quality productions away and elevate finer artists. It will be exactly the opposite.

Virtue consists, not in abstaining from vice, but in not desiring it. (George Bernard Shaw)

Piracy Tax will severe the already severed bonds between the artists (the producers of art) and us (the consumers) even more. When we buy a DVD or CD it is not just bread on the tables. It is also sending the message “I like what you do. Here, I even choose to give my hard earned money willingly to support your art”. Emphasis on willingly and supporting art. It’s not a passive action like listening to the radio. You (consumer) take a conscious step. Your contributions are small materially, but it should mean something to the artist even at the individual level. We need art. It is not just listening to music or whatever. But we need art to compete in the neverending race of civilization. No art, no culture. No culture, no civilization. Lack of civilization is inevitable slavery. So, we need to learn to support our artists willingly and directly. Piracy Tax is an obstacle for this social goal.

What about opting-out? If I opted out will I still be able to use legal download services? If I am not allowed to opt out but I continue pirating³ your download statistics will be further skewed. If this is being done to free the content then why do we have to give up our freedom⁴. If this is being done to increase the profits of content industry… Well, then it makes sense.

If the free market is a bad idea, why don’t we shift the whole economy to a controlled market? With pirate tax in effect, content industry’s income is not only centralized but falls under government control. The government controls the art. I don’t like that idea. Art should be free. In short I don’t think Piracy Tax is the way to go.

What Is My Proposal Then?

I have been thinking hard about Pirate Party and the problem of piracy. The question is not what should we do about piracy? Unless you want to treat the symptoms. The question is how will content industry adapt to the information age? We adapted to information age quite well, didn’t we? Why can’t they do the same? I don’t want to believe they are so stupid that they don’t really know how. As far as I can understand they don’t want to change. Because change has a price. And they don’t want to pay. They want us to pay the price for them stagnating like that. Let’s stop beating around the bush and see it as it is.

Smart artists are already making the move. They let you download their movies and songs for free, and find other channels of monetization. Lots of concerts for example. Not necessarily huge stadium concerts. If you take all those middlemen out of the equation you don’t have to be all that popular. All in all, it is much better than continuously whine about piracy.

My proposal is not to engage ourselves with Piracy Tax⁵. There has to be a better solution. At least a solution that doesn’t necessarily make big players more powerful than they are. Let’s support far-sighted artists who take the steps to adapt new conditions for now. And continue to discuss alternatives.

1: I know piracy doesn’t equal to P2P. It is possible to share content legally via P2P networks. Also P2P is not the only channel you can distribute pirate content. I just think they are interchangeable in the context of this post.

2: It does matter. Let’s not go to the extreme. It would be a waste of time and energy for me to even subscribe to a web based service. Torrents are much easier and flexible for me. And I have a graphical browser with Flash capability.

3: See 2 above.

4: Money can buy freedom, any objections?

5: I would like to remind those who would suggest Piracy Tax as a temporary solution; laws might end up being in effect for too long.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

There is a newer version of this post. Information below is no longer valid!

There is a misconception about how static files (a.k.a media files) are handled in Django. Actually it is quite clearly documented here and here. Nevertheless a question about this comes up in the mailing-list or IRC channel frequently:

Where do I put my media files?

Django can’t find my foo.gif!

How can I link my CSS?

First of all, just to make it clear; just because a server returns a response body with an internal URL doesn’t necessarily mean it will be available on that server. It is one thing that your templates produce the correct URL to a media file and another thing that your server actually serves that resource on that URL. Django development server doesn’t automagically serve media files¹.

Settings

There are three settings to get right: MEDIA_ROOT, MEDIA_URL and ADMIN_MEDIA_PREFIX. MEDIA_ROOT is the absolute filesystem path where your media files are. I usually set it like:

MEDIA_ROOT = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'media')

This will set MEDIA_ROOT to point to the media directory in your project directory². MEDIA_URL and ADMIN_MEDIA_PREFIX are URL’s:

MEDIA_URL = '/media/'
ADMIN_MEDIA_PREFIX = '/media/admin/'

With this setup, to serve admin media in production, all I need to do is to symlink media folder of admin app into my media directory. Of course you can set MEDIA_URL to point to another domain/subdomain. Such as http://media.mydomain.com/. But this way you can’t serve your media from development server.

URL Configuration

Add the following code snipplet at the end of your root urls.py:

   1 if settings.DEBUG:
   2     from django.views.static import serve
   3     _media_url = settings.MEDIA_URL
   4     if _media_url.startswith('/'):
   5         _media_url = _media_url[1:]
   6         urlpatterns += patterns('',
   7                                 (r'^%s(?P<path>.*)$' % _media_url,
   8                                 serve,
   9                                 {'document_root': settings.MEDIA_ROOT}))
  10     del(_media_url, serve)

settings.DEBUG == True doesn’t necessarily mean development server is running. But it is a good indicator since deploying with development server is not a good idea for many reasons. Notice here we don’t serve media unless MEDIA_URL is an absolute URL on our server.

Templates

Finally we need to specify media URL’s correctly. To avoid hard-coding media path we will be using {{ MEDIA_URL }} context variable in our templates. To have {{ MEDIA_URL }} included automatically in each template we need to do two things:

1. Make sure you have django.core.context_processors.media in your TEMPLATE_CONTEXT_PROCESSORS.
2. Make sure each view is using a RequestContext.

Afterwards all we need to do is to specify our media URL’s like this:

<img src="{{ MEDIA_URL }}img/header.jpeg" />

This will be translated to:

<img src="/media/img/header.jpeg" />

Bonus

While we are at it, why not serve our 500 and 404 pages statically. When DEBUG == True, 500 (server error) and 404 (not found) situations are handled with special debugging views. So there’s no chance to test your error pages. Add the following code, just like static serving code:

   1 if settings.DEBUG:
   2     urlpatterns += patterns('',
   3                             (r'^404/',
   4                                 'django.views.generic.simple.' \
   5                                 'direct_to_template',
   6                                 {'template': '404.html'}),
   7                             (r'^500/',
   8                                 'django.views.generic.simple.' \
   9                                 'direct_to_template',
  10                                 {'template': '500.html'}))

Now when you visit /500/ and /404/ on your development server you will be served a fake error page.

1: There is an exception here. If you configured your settings correctly, development server will serve admin media.

2: Assuming your settings.py is directly inside your project directory, hence the __file__.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

Great talk. Also note the elegance of Omnisio player.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

But I would like to take the first argument from the article and elaborate on it a little bit; There’s nothing to do there (in a social network). Social networks like MySpace, Facebook and Orkut are based on creating a profile and associating other profiles with it. Thus you get to show everybody how many friends you have, you get to sell them and poke them and bite them (via Facebook applications), you get to rate them (in Orkut) and finally you get to send them private (and otherwise) messages. You can do all this stuff, so these social networks must be invaluable tools for our social life, right? Let’s take a closer look.

Last time I checked, relationships were more about quality than quantity. Who cares if you have 10 or 1000 friends in your profile? Having a huge friend count doesn’t even make you a popular person as far as I’m concerned. Because I know people who just pop out of nowhere and request to be friends with me. Unsurprisingly they have a high friend count themselves, go figure!

I think relationships are about sharing experiences. Social networks like Facebook give you that opportunity. In a twisted sick way though. For example you can poke your friends. Think about how much you can strenghten your relationships by poking people. And not only that, thanks to the application API you can buy and sell your friends as pets or you can suck their blood till they become vampires. Just the constant stream of invitations makes up a great experience. But I doubt it is the kind of experience Facebook wants you to have.

But hey, you can use social networks to communicate with people too. Isn’t that a good thing? You can publish your status, you can send your friends private messages. You can even join groups to meet like minded people! Isn’t that cool? …well, no. If you think that’s cool you must have missed the news about something called Internet! You can do all these without a social apparatus and almost always more effectively. You can email people for example. I would suppose people check their email more often and with greater attention than their social web2.0 gadgetry Mainstream social networks are not much more than profile association tools. There is nothing to do there. And noone, other than your friends, cares about your profile decoration. Perhaps not even your friends…

This huge mass of loser generated content reminds me of all that wasted bandwidth over once popular and useless e-mail forwards. When I lashed out to the senders they would be offended and surprised at the same time. How could I reject these wonderful delights Internet has to offer us. Do they still forward? That was before we had hyper-super-wall applications and send-poop applications. Actually I am a big fan of user generated content. There are many blogs for example, not only worth reading but their content is so precious that you can’t just possibly buy a book or take a course to get to that information. These people genuinely have something to tell and they have spent the effort to set-up a proper channel for their valuable voice. There are lame blogs as well, but of course if you’re reading this you already know that. But the bad ones are not strongly connected with the good ones, therefore you don’t even have to notice them. In other words they can not publish stories in your news feed.

There are also social networks that are built around another application. So there is a common goal, or at least something solid to talk about. I divide them into three and a half categories; building, sharing, bookmarking and business.

• Building applications with social networking are in my opinion most sophisticated and most valuable. Common example is Wikipedia. If you find it hard to spot social networking elements in Wikipedia that is probably because you have only seen the frontend. Wikipedia is a big community, and they form a social network with a wide communication bandwidth. Just google it to find out about how they operate and edit. Another good example to this category is open source software development. They also form a social network, and the networking aspect is much bigger this time.
• Sharing applications with social networking include Youtube, Flickr, 8tracks and the like. I won’t deny most of the content here is loser generated, just go to a random Youtube video and try to read the comments. But that may be, on an end user level, irrelevant. In these applications networking is not pushed too hard and the sharing mission is fully accomplished.
• Bookmarking is actually a special case of sharing. Bookmarking applications such as Reddit, Digg and Stumbleupon are built on an incredibly powerful idea of sharing bookmarks. Today we are using WWW for many different things, but generally surfing is still the most prevalent. And hyperlinks and search engines fail to serve well enough for general purpose surfing. Social bookmarking does. You can choose a general or specific category and enjoy an almost endless stream of human reviewed websites.
• Business oriented social networks form half a category. They are not very different than mainstream friend portfolios. They emphasize business networking and I hear they can be useful. People are more open to meet new people in business context and these sites copy real world interaction successfully, so I don’t put them together with the other time wasters.

If you want a web presence the best way in my opinion is blogging. If you don’t have anything to say, no matter how many social profiles you have and how many times you can twit a day doesn’t really matter, nobody cares. You can also incorporate social media if you like, you can import your RSS into your Facebook profile or ping.fm some your posts. There is no need to spend a lot of time tweaking your profile, it is pointless.

On the other hand social networking is an important concept. It adds value when it is built around another, related service. Take Kongregate for example. I mentioned about how it is structured as a game which forms social network with unique dynamics. Check it out, if you also believe profile association is not the highest point for social networks.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2

Looking at aqcuisitions like this one, I see two things;

• Improving end user experience (or conversation in some cases) is more important than technical superiority. Omnisio didn’t host uber quality HD videos or 3D sound or anything fancy like that. What made me fall in love with the service is that they simply synchronized (vector) keynotes with the actual video.
• Execution is king for investors of any kind. This should be no surprise though. Not because they risk their money. But because startup businesses are usually making up their specific business as a whole as they go. So there is not really any substantial know-how, unless you are a copycat.

Check out Startup School 2008 videos on Omnisio.

Related posts:

1. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor
2. Working with files in Django – Part 1
3. Working with files in Django – Part 2