Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#14709 closed (fixed)

staticfiles app seems forced upon me

Reported by: jcscoobyrs Owned by: jezdez
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: UI/UX:

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.

Attachments (0)

Change History (5)

comment:1 Changed 3 years ago by jcscoobyrs

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 3 years ago by jcscoobyrs

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 Changed 3 years ago by jezdez

  • milestone set to 1.3
  • Owner changed from nobody to jezdez
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted

Thank you for your thorough report, this is indeed a problem with check_settings() being called in StaticFilesHandler.__init__.

comment:4 Changed 3 years ago by jezdez

  • Resolution set to fixed
  • Status changed from assigned to 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.

comment:4 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.