I've recently upgraded my project environment to django 1.6. After the upgrade, I found out that all the static files in the existing projects do not work anymore, even if I create a new project following the tutorial, the static file still does not work. Can any one help me out?
Here is my project structure
-mysite
manage.py
-mysite
urls.py
views.py
settings.py
__init__.py
wsgi.py
-static
jqury.js
settings.py looks like this
INSTALLED_APPS = (
...
'django.contrib.staticfiles',
)
TEMPLATE_DIRS = (
os.path.join(BASE_DIR, 'WorldCup\\templates'),
)
TEMPLATE_CONTEXT_PROCESSORS = [
'django.core.context_processors.static',
'django.contrib.auth.context_processors.auth',
]
STATIC_URL = '/static/'
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'WorldCup\\static'),
)
print STATICFILES_DIRS
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
#'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
I print the staticfiles_dirs, the result is ('G:\django_project\mysite\mysite\static',), which correctly points to my static file folder.
The html file looks like:
{% load staticfiles %}
<script type="text/javascript" src="{% static "WorldCup/jquery-1.10.2.js" %}"
<body>
hello world======{% static "WorldCup/jquery-1.10.2.js" %}=======
</body>
the page displays "hello world======/static/jquery-1.10.2.js=======", which seems correct.
But the Console complained with:
Traceback (most recent call last):
File "D:\Python27\lib\wsgiref\handlers.py", line 85, in run
self.result = application(self.environ, self.start_response)
File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
ine 68, in __call__
return super(StaticFilesHandler, self).__call__(environ, start_response)
File "D:\Python27\lib\site-packages\django\core\handlers\wsgi.py", line 206, i
n __call__
response = self.get_response(request)
File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
ine 58, in get_response
return self.serve(request)
File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
ine 51, in serve
return serve(request, self.file_path(request.path), insecure=True)
File "D:\Python27\lib\site-packages\django\contrib\staticfiles\views.py", line
41, in serve
return static.serve(request, path, document_root=document_root, **kwargs)
File "D:\Python27\lib\site-packages\django\views\static.py", line 61, in serve
content_type, encoding = mimetypes.guess_type(fullpath)
File "D:\Python27\lib\mimetypes.py", line 297, in guess_type
init()
File "D:\Python27\lib\mimetypes.py", line 358, in init
db.read_windows_registry()
File "D:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
for subkeyname in enum_types(hkcr):
File "D:\Python27\lib\mimetypes.py", line 249, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 0: ordinal
not in range(128)
[01/Dec/2013 07:42:33] "GET /static/jquery-1.10.2.js HTTP/1.1" 500 59
Even if I change to the image file instead of js file, I still get those errors....
My best guess based on your error message is that you have non-ASCII characters in your Windows registry, and something in the
mimetypesmodule (part of the Python standard library) is choking on that. I assume either the Django statics server, or the Django staticfiles app itself, is callingmimetypes.This is not a problem with your system per se; if I'm correct in my diagnosis it's clearly a bug in
mimetypes.Here are some options:
You could upgrade to Python 3.3 or 3.4 beta. Django 1.6 is fully compatible with Python 3 and I would be very surprised to see that this bug still exists in Py3 because one of the explicit goals of Py3 was to make unicode encode/decode errors less common.
You could downgrade back to Django 1.5.
You could use a different operating system for development work. Relatively few Python programmers do their dev work in Windows, although the number is not zero either. You are less likely to run into extremely obscure bugs if you use OS X or Linux for development work. That having been said, Windows is an officially supported platform, so if there is a problem with the interaction between CPython and Windows, then that is a CPython bug.
You could try to find exactly what change between 1.5 and 1.6 caused this problem, but that is likely a fool's errand and, assuming it's not an outright bug in Django, will at best result in you having to maintain a fork with your patch for your personal use (not recommended).
You could try to find the offending line in your registry and scrub it, but I don't know how you would go about doing this. You may have a combination of locale settings, the localized version of Windows, non-English installed software or custom MIME types that is causing this problem. Since it seems likely that it is a bug in the mimetypes library and not the fault of your system, you could easily find that the problems in your registry are simply a consequence of some normal function of your computer.
If the problem is with the Django statics server in a way that wouldn't affect your application in production (where the Django statics server, which is only suitable for development, would presumably be disabled) then you could disable the Django statics server and use some other statics serving solution for development. This is inconvenient but would probably work, as long as the problem is with the Django statics server only. To test, set DEBUG to False or otherwise turn off the statics server and run your application -- if it still crashes, then it's not a Django statics server issue; otherwise, it likely is.
Finally, you could try to track down the actual bug and fix it. This is a complex process -- you would need to isolate the bug, see whether it needs to be fixed in the CPython standard library or in Django (I suspect the former), file a report with either of those projects, then write a patch and submit it or get someone else to do likewise. Until it is submitted and accepted, you could theoretically maintain a fork of CPython with the fix applied, but that is a maintenance nightmare.
There is still the possibility that I am outright wrong about the cause and it's not a bug in
mimetypes-- in that case you might have more options.