This problem can be solved with appending `SCRIPT_NAME` in to `SCRIPT_URL`
in `settings.py`
This can be easily added into default django `static` tag and
`django.contrib.staticfiles` tag as following:
{{{
def render(self, context):
url = self.url(context)
# Updating url here with request.META['SCRIPT_NAME']
if self.varname is None:
return url
context[self.varname] = url
return ''
}}}
On more research I found that `FileSystemStorage` and `StaticFilesStorage`
ignores `script_name` as well.
We might have to do a lot of changes but I think it's worth the efforts.
--
Ticket URL: <https://code.djangoproject.com/ticket/25598>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
This change doesn't seem correct to me (for one, it seems like it could
break existing sites). Why not include the appropriate prefix in your
`STATIC_URL` and `MEDIA_URL` settings?
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:1>
Comment (by DheerendraRathor):
This is not a patch. This is just an idea I got about the patch for `{%
static %}` only. The patch will (probably) involve `FileSystemStorage` and
`StaticFileSystemStorage` classes.
The main idea behind this feature was that Django will auto detect
script_name header and use that accordingly for creating static and media
urls. This will reduce human efforts for setting up sites in future. This
patch will also take time to develop so it can be added in Django2.0
timeline.
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:2>
Comment (by timgraham):
What I meant was that I don't think Django should automatically use
SCRIPT_NAME in generating those URLs. If you're running your site on a
subpath, then you should set your STATIC_URL to
'http://example.com/subpath/static/' or whatever. However, you might not
even be hosting static and uploaded files on the same domain as your site
(in fact, for user-uploaded files, you shouldn't do that
[https://docs.djangoproject.com/en/stable/topics/security/#user-uploaded-
content for security reasons]) in which case `SCRIPT_URL` is irrelevant in
constructing the static/media URLs.
How would the change make it easier to setup sites?
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:3>
Comment (by claudep):
I think that the idea basically makes sense. Ideally, a Django instance
shouldn't need to know at which subpath it is being deployed, as this can
be considered as purely sysadmin stuff. It would be a good separation of
concerns. For example, the Web administrator may change the
WSGIScriptAlias from /foo to /bar and the application should continue
working. Of course, this only applies when *_URL settings are not full
URIs.
In practice, it's very likely that many running instances are adapting
their *_URL settings to include the base script path, hence the behavior
change would be backwards incompatible. The question is whether the change
is worth the incompatibility.
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:4>
* component: Uncategorized => contrib.staticfiles
Comment:
I see. I guess the idea would be to use `get_script_prefix()` like
`reverse()` does as I don't think we have access to `request` everywhere
we need it. It seems like some public APIs like `get_static_url()` and
`get_media_url()` would replace accessing the settings directly whenever
building URLs. For backwards compatibility, possibly these functions could
try to detect if the setting is already prefixed appropriately.
Removing the prefix from the settings, however, means that the URLs are no
longer correct when generated outside of a request/response cycle though
(#16734). I'm not sure if it might create any practical problems, but we
might think about addressing that issue first.
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:5>
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:6>
* cc: kottenator@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:7>
Comment (by kottenator):
I'm here at DjangoCon US 2016 will try to create a patch for this ticket
;)
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:8>
Old description:
> By default, `static` tag just appends `STATIC_URL` in the path. When
> running on subpath it results in incorrect static url.
>
> This problem can be solved with appending `SCRIPT_NAME` in to
> `SCRIPT_URL` in `settings.py`
>
> This can be easily added into default django `static` tag and
> `django.contrib.staticfiles` tag as following:
>
> {{{
> def render(self, context):
> url = self.url(context)
> # Updating url here with request.META['SCRIPT_NAME']
> if self.varname is None:
> return url
> context[self.varname] = url
> return ''
> }}}
>
> On more research I found that `FileSystemStorage` and
> `StaticFilesStorage` ignores `script_name` as well.
> We might have to do a lot of changes but I think it's worth the efforts.
New description:
By default, `{% static '...' %}` tag just appends `STATIC_URL` in the
path. When running on sub-path, using `SCRIPT_NAME` WSGI param, it results
in incorrect static URL - it doesn't prepend `SCRIPT_NAME` prefix.
This problem can be solved with prepending `SCRIPT_NAME` in to
`SCRIPT_URL` in `settings.py` but that doesn't work when `SCRIPT_NAME` is
a ''dynamic value''.
This can be easily added into default Django `static` tag and
`django.contrib.staticfiles` tag as following:
{{{
def render(self, context):
url = self.url(context)
# Updating url here with request.META['SCRIPT_NAME']
if self.varname is None:
return url
context[self.varname] = url
return ''
}}}
On more research I found that `FileSystemStorage` and `StaticFilesStorage`
ignores `SCRIPT_NAME` as well.
We might have to do a lot of changes but I think it's worth the efforts.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:9>
Old description:
> By default, `{% static '...' %}` tag just appends `STATIC_URL` in the
> path. When running on sub-path, using `SCRIPT_NAME` WSGI param, it
> results in incorrect static URL - it doesn't prepend `SCRIPT_NAME`
> prefix.
>
> This problem can be solved with prepending `SCRIPT_NAME` in to
> `SCRIPT_URL` in `settings.py` but that doesn't work when `SCRIPT_NAME` is
> a ''dynamic value''.
>
> This can be easily added into default Django `static` tag and
> `django.contrib.staticfiles` tag as following:
>
> {{{
> def render(self, context):
> url = self.url(context)
> # Updating url here with request.META['SCRIPT_NAME']
> if self.varname is None:
> return url
> context[self.varname] = url
> return ''
> }}}
>
> On more research I found that `FileSystemStorage` and
> `StaticFilesStorage` ignores `SCRIPT_NAME` as well.
>
> We might have to do a lot of changes but I think it's worth the efforts.
New description:
By default, `{% static '...' %}` tag just appends `STATIC_URL` in the
path. When running on sub-path, using `SCRIPT_NAME` WSGI param, it results
in incorrect static URL - it doesn't prepend `SCRIPT_NAME` prefix.
This problem can be solved with prepending `SCRIPT_NAME` to `STATIC_URL`
in `settings.py` but that doesn't work when `SCRIPT_NAME` is a ''dynamic
value''.
This can be easily added into default Django `static` tag and
`django.contrib.staticfiles` tag as following:
{{{
def render(self, context):
url = self.url(context)
# Updating url here with request.META['SCRIPT_NAME']
if self.varname is None:
return url
context[self.varname] = url
return ''
}}}
On more research I found that `FileSystemStorage` and `StaticFilesStorage`
ignores `SCRIPT_NAME` as well.
We might have to do a lot of changes but I think it's worth the efforts.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:10>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:11>
* needs_better_patch: 0 => 1
Comment:
At least documentation and additional tests look like they are required.
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:12>
Comment (by kottenator):
Absolutely agree with your remarks, Tim. I'll add tests. Could you point
to docs that need to be updated?
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:13>
* owner: nobody => jrwdunham
* status: new => assigned
Comment:
I would like to take this ticket on and have a new PR for it:
https://github.com/django/django/pull/10724
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:14>
Comment (by Oleg Kainov):
I tried to revive activities around this ticket, so I created (yet
another) PR based on previous work
https://github.com/django/django/pull/11564
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:15>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:16>
* owner: Joel Dunham => Oleg Kainov
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:17>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:18>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:19>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:20>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"c574bec0929cd2527268c96a492d25223a9fd576" c574bec]:
{{{
#!CommitTicketReference repository=""
revision="c574bec0929cd2527268c96a492d25223a9fd576"
Fixed #25598 -- Added SCRIPT_NAME prefix to STATIC_URL and MEDIA_URL set
to relative paths.
Thanks Florian Apolloner for reviews.
Co-authored-by: Joel Dunham <Joel....@technicalsafetybc.ca>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:21>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"9d05add447d57d94ec9e9b3daa338d85a29fe083" 9d05add]:
{{{
#!CommitTicketReference repository=""
revision="9d05add447d57d94ec9e9b3daa338d85a29fe083"
Fixed #32394 -- Changed project template settings to use relative
STATIC_URL.
Refs #25598 which added original support for relative STATIC_URL and
MEDIA_URL.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25598#comment:22>