Allow MEDIA_ROOT inside STATIC_ROOT

[Bruno Renié]

I have the following layout:

STATIC_ROOT = '/path/to/static/'
STATIC_URL = '/static/'

MEDIA_ROOT = STATIC_ROOT + 'media/'
MEDIA_URL = STATIC_URL + 'media/'

Basically, MEDIA_ROOT is a subdirectory of STATIC_ROOT.

With runserver, I won't be able to serve my media files. When I try to fetch a media file, the StaticFilesHandler tries to handle it (since its URL starts with STATIC_URL) but no finder will be able to resolve its path.

The handler then raises a 404 even if I have a pattern in my urlconf to serve my media files.

After discussing it on IRC, it looks like two things are needed to support this:

• Patch the contrib.staticfiles handler to specifically ignore anything inside MEDIA_URL

• Add extra checks to the collectstatic management command to make sure collectstatic won't write anything inside MEDIA_ROOT (which could potentially overwrite some user data).

[Bruno Renié]

Patch for the StaticFilesHandler

[Bruno Renié]

Patch for collectstatic, probably needs some improvements

[Bruno Renié]

Hmmm this is trickier. With the patch applied, the media files aren't served by staticfiles but defining a custom view won't work either.

urlpatterns += patterns('django.contrib.staticfiles.views',
    url(r'^static/media/(?P<path>.*)$', 'serve',
        {'document_root': settings.MEDIA_ROOT}),
)

The 'serve' view is called, but the options dict is not passed to the view. 'document_root' is swallowed somewhere and ends up as None in the view, something bad probably happens in the staticfiles handler. If I change MEDIA_URL to '/static_media/' and the URL pattern to r'^static_media/(?P<path>.*)$', the options dict is correctly passed to the view.

I thought modifying _should_handle() on StaticFilesHandler would do the job, but apparently it's not enough. The staticfiles handler isn't transparently giving the control back to the parent WSGIHandler if _should_handle returns false.

[Carl Meyer]

This is a 1.3 blocker, because it's a significant problem with a new feature in 1.3.

[Jannis Leidel]

Replying to brutasse:

Hmmm this is trickier. With the patch applied, the media files aren't served by staticfiles but defining a custom view won't work either.

urlpatterns += patterns('django.contrib.staticfiles.views',
    url(r'^static/media/(?P<path>.*)$', 'serve',
        {'document_root': settings.MEDIA_ROOT}),
)

The 'serve' view is called, but the options dict is not passed to the view. 'document_root' is swallowed somewhere and ends up as None in the view, something bad probably happens in the staticfiles handler. If I change MEDIA_URL to '/static_media/' and the URL pattern to r'^static_media/(?P<path>.*)$', the options dict is correctly passed to the view.

Not sure what you mean with "something bad happens", the view looks just fine: source:django/trunk/django/contrib/staticfiles/views.py#L23

I thought modifying _should_handle() on StaticFilesHandler would do the job, but apparently it's not enough. The staticfiles handler isn't transparently giving the control back to the parent WSGIHandler if _should_handle returns false.

[Carl Meyer]

After further IRC discussion with jezdez, closing this wontfix. Supporting a configuration with MEDIA_ROOT inside STATIC_ROOT introduces a number of additional complexities and couplings between staticfiles and the MEDIA_* settings, which we are trying to avoid, and it's not clear what meaningful benefits it buys us. The main mentioned benefit was to only require one alias on the front-end webserver: that seems minor, since an alias is e.g. just one line in an nginx conf file. In any case, the same result can be achieved by putting MEDIA_ROOT and STATIC_ROOT side by side in a parent directory, and aliasing the front-end webserver to that parent directory.

[Jacob]

Milestone 1.3 deleted