Fix CSS Absolute Filter bug when working with remote files #337

Open
wants to merge 3 commits into
from

Projects

None yet

3 participants

dulaccc commented Nov 25, 2012

Hi,

It seems to me that every time I tried to set my production app setting DEBUG to False, the css absolute filter wasn't applied. So after a little digging, I found that the condition

if (not (filename and filename.startswith(self.root)) and
        not self.find(basename)):
    return self.content

wasn't taking into account if the file wasn't stored on the server root path.
Indeed, I was forced to set COMPRESS_ROOT equal to STATIC_ROOT (correct me if I'm wrong). Then STATIC_ROOT need to be a local path on the server and can't be a remote path to a S3 bucket.

So filename never starts with this.root value.

If I'm miss-understading the usual settings to work well with Amazon S3 assets tell me, I'm sure I'm not the first one to use this configuration.

Should this also support scheme-less urls (i.e. using // instead of https:// and http://). I not sure what the intent of the has_scheme, but from what I see it looks likes // should be a valid protocol.

dulaccc commented Jan 7, 2013

I Agree! // is technically a valid protocol but I don't know if the urllib python module is aware of this one, because when you use it in a web page it means "use the protocol that the user used to load the web page", right ?

And I'm not sure if a django-compressor filters has a reference to the request made.

I'll take a closer look at it.

Yeah // just uses the same protocol as the rest of the page. Handy if you use CSS on both secure and insecure pages.

I'm not sure that urllib needs to understand. I am currently using some code similar to yours to handle // and it works fine for the moment.

alanjds commented Mar 26, 2013

I have the same issue right now. Going to test this fork

alanjds commented Mar 26, 2013

Looks like my issue is other than yours. Mine fixed by setting COMPRESS_ROOT = MEDIA_ROOT

dulaccc commented Mar 27, 2013

Yeah, that seems to be an issue related to the way we structured our static and media directories. That's why in my initial comment on this PR I said

Indeed, I was forced to set COMPRESS_ROOT equal to STATIC_ROOT (correct me if I'm wrong). Then STATIC_ROOT need to be a local path on the server and can't be a remote path to a S3 bucket.

Did you make the same choice as mine for STATIC_ROOT ?

alanjds commented Mar 27, 2013

No, its on MEDIA_ROOT for me.

I am using an special storage that partially handles this issue for me:
https://bitbucket.org/alanjds/django-storages/commits/branch/filecache_storage(still
beta)

It copies the needed files to the server from the remote storage when
needed by django_compressor.

Its better if django_compressor can provide a solution, but this storage
addresses other issue of mine: some thumbnail generation libs transfers the
source image once for every thumbnail created.


Alan Justino da Silva
* Cel: +55 11 9822-5769


2013/3/27 Pierre Dulac notifications@github.com

Yeah, that seems to be an issue related to the way we structured our
static and media directories. That's why in my initial comment on this PR I
said

Indeed, I was forced to set COMPRESS_ROOT equal to STATIC_ROOT (correct me
if I'm wrong). Then STATIC_ROOT need to be a local path on the server and
can't be a remote path to a S3 bucket.

Did you make the same choice as mine for STATIC_ROOT ?


Reply to this email directly or view it on GitHubhttps://github.com/jezdez/django_compressor/pull/337#issuecomment-15518784
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment