#14709 closed (fixed)
staticfiles app seems forced upon me
Reported by: | Jeremy Whitlock | Owned by: | Jannis Leidel |
---|---|---|---|
Component: | Contrib apps | Version: | 1.3-alpha |
Severity: | Keywords: | staticfiles | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I just updated my Django to the latest dev (14587) and I'm finding that the staticfiles app (django.contrib.staticfiles) seems to be forced upon me. Prior to updating, my Django app was serving static files in development mode the way the documentation suggested which used MEDIA_ROOT and MEDIA_URL. After I updated Django, I get the following:
Validating models...
0 errors found
Django version 1.3 alpha 1 SVN-14587, using settings 'singularity.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Unhandled exception in thread started by <bound method Command.inner_run of <django.core.management.commands.runserver.Command object at 0x10133c9d0>>
Traceback (most recent call last):
File "/Library/Python/2.6/site-packages/django/core/management/commands/runserver.py", line 83, in inner_run
handler = self.get_handler(*args, options)
File "/Library/Python/2.6/site-packages/django/core/management/commands/runserver.py", line 115, in get_handler
return AdminMediaHandler(handler, options.get('admin_media_path', ))
File "/Library/Python/2.6/site-packages/django/contrib/staticfiles/handlers.py", line 23, in init
utils.check_settings()
File "/Library/Python/2.6/site-packages/django/contrib/staticfiles/utils.py", line 40, in check_settings
raise ImproperlyConfigured("The MEDIA_URL and STATICFILES_URL "
django.core.exceptions.ImproperlyConfigured: The MEDIA_URL and STATICFILES_URL settings must have individual values
Now...my settings.py wasn't updated to have the staticfiles app installed so I'm confused. Being a development version of Django, I go to the docs and I see serving static files is documented differently. I also see that the TEMPLATE_CONTEXT_PROCESSORS includes the staticfiles context processor by default. My first thought was to remove that by overriding the default for TEMPLATE_CONTEXT_PROCESSORS but I still get the error above. I don't mind using the staticfiles app but it shouldn't be forced upon me like it appears to have been. Existing Django apps shouldn't fail upon startup or there should at least be some documented way to completely turn off the new staticfiles app.
Change History (5)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
I did figure out a good way to workaround this. Since the only time I need Django to be involved in my static file serving is in DEBUG/developer mode, I was able to succumb to the new requirement and I set the STATICFILES_URL/STATICFILES_DIRS settings. With those two settings in place, I was able to use the staticfiles_urlpatterns from django.contrib.staticfiles.urls. Now, this all makes sense because of the following:
- The default TEMPLATE_CONTEXT_PROCESSORS includes the django.contrib.staticfiles.context_processors.staticfiles processor
- The STATICFILES_URL is only checked in DEBUG mode
- My urls only include the staticfiles_urlpatterns url(s) in DEBUG mode
I guess since there is a workaround this isn't that big of a deal, at least for me. I still think there is a good bit of confusion around the staticfiles app when it comes to how this problem manifested. The reason it's confusing is because I didn't enable any django.contrib.staticfiles app yet I'm getting errors related to this app. The error makes you feel forced to use the staticfiles app and the only way to avoid it is using the workaround I documented earlier. I even wonder if my workaround above is working by mistake. While I know why this is happening and I have a working workaround (for now), I still can't tell if this should be happening the way it is.
comment:3 by , 14 years ago
milestone: | → 1.3 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
Thank you for your thorough report, this is indeed a problem with check_settings() being called in StaticFilesHandler.__init__
.
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [14592]) Fixed #14693, #14709 -- Backwards incompatible change to rectify the confusion around the STATICFILES_URL and STATICFILES_ROOT settings.
- Two new global settings that will be used by -- but are not limited to -- the staticfiles app: STATIC_ROOT and STATIC_URL.
- Moving the 'django.contrib.staticfiles.templatetags.staticfiles' template tag to the core ('django.templatetags.static') and renaming it to 'get_static_prefix'.
- Moving the context processor 'django.contrib.staticfiles.context_processors.staticfiles' to the core ('django.core.context_processors.static') and renaming it to 'static'.
- Paths in media definitions will use STATIC_URL as the prefix if the value is not None, and falls back to the previously used MEDIA_URL.
Thanks again to the community for constructive criticism and Carl and Russ for sanity-inducing discussions on IRC.
I've been looking through the sources and it seems that this is a result of AdminMediaHandler being a subclass of StaticFilesHandler. StaticFilesHandler.init makes a call to django.contrib.staticfiles.utils.check_settings() in DEBUG mode and this is where the problem arises.