django-compressor没有在Heroku上设置绝对CSS图像路径

I'm using django-compressor to concatenate and compress my CSS and JS files on this site. I'm serving static files from an S3 bucket.

我正在使用django-compressor来连接和压缩我在这个站点上的CSS和JS文件。我正在从S3存储桶提供静态文件。

On my local copy of the site, using a different S3 bucket, this all works perfectly. But on the live site, hosted on Heroku, it all works except the relative URLs for images in the CSS files do not get re-written.

在我的本地网站副本上，使用不同的S3存储桶，这一切都完美无缺。但是在Heroku上托管的实时网站上，除了CSS文件中图像的相对URL不会被重写之外，它都可以工作。

eg, this line in the CSS file:

例如，CSS文件中的这一行：

background-image: url("../img/glyphicons-halflings-grey.png");

gets rewritten to:

被重写为：

background-image:url('https://my-dev-bucket-name.s3.amazonaws.com/static/img/glyphicons-halflings-grey.png')

on my development site, but isn't touched on the live site. So the live site ends up looking in pepysdiary.s3.amazonaws.com/static/CACHE/img/ for the images (as it's relative to the new, compressed CSS file).

在我的开发网站上，但没有触及现场网站。所以现场网站最终会在图片中找到pepysdiary.s3.amazonaws.com/static/CACHE/img/（因为它与新的压缩CSS文件相关）。

For now, I've put a directory at that location containing the images, but I can't work out why there's this difference. Both sites have this in their settings:

现在，我已经在包含图像的位置放了一个目录，但我无法理解为什么会有这种差异。两个网站都在他们的设置中有这个：

COMPRESS_CSS_FILTERS = [
    # Creates absolute urls from relative ones.
    'compressor.filters.css_default.CssAbsoluteFilter',
    # CSS minimizer.
    'compressor.filters.cssmin.CSSMinFilter'
]

And the CSS files are being minimised just fine... but it's like the other filter isn't being applied on the live site.

并且CSS文件正在被最小化...但它就像其他过滤器没有在现场网站上应用。

3 个解决方案

#1

I recently ran into this issue on heroku, and running the latest version of django-compressor (1.3) does not solve the problem. I will provide the solution that I am using, as well as an explanation of the problems I ran into along the way.

我最近在heroku上遇到了这个问题，运行最新版本的django-compressor（1.3）并没有解决问题。我将提供我正在使用的解决方案，以及我在此过程中遇到的问题的解释。

The solution

解决方案

I created my own 'CssAbsoluteFilter' that removes the settings.DEBUG check from the 'find' method like this:

我创建了自己的'CssAbsoluteFilter'，它从'find'方法中删除settings.DEBUG检查，如下所示：

# compress_filters.py
from compressor.filters.css_default import CssAbsoluteFilter
from compressor.utils import staticfiles


class CustomCssAbsoluteFilter(CssAbsoluteFilter):
    def find(self, basename):
        # The line below is the original line.  I removed settings.DEBUG.
        # if settings.DEBUG and basename and staticfiles.finders:
        if basename and staticfiles.finders:
            return staticfiles.finders.find(basename)

# settings.py
COMPRESS_CSS_FILTERS = [
# 'compressor.filters.css_default.CssAbsoluteFilter',
'app.compress_filters.CustomCssAbsoluteFilter',
'compressor.filters.cssmin.CSSMinFilter',
]

The absolute urls now always work for me whether DEBUG = True or False.

无论DEBUG = True还是False，绝对网址现在总能为我工作。

The Problem

问题

The issue is connected to 'compressor.filters.css_default.CssAbsoluteFilter', your DEBUG setting, and the fact that heroku has a read-only file system and overwrites your app files every time you deploy.

该问题与'compressor.filters.css_default.CssAbsoluteFilter'，您的DEBUG设置以及heroku具有只读文件系统并在每次部署时覆盖您的应用程序文件这一事实相关联。

The reason compress works correctly on your development server is because CssAbsoluteFilter will always find your static files when DEBUG = True, even if you never run 'collectstatic'. It looks for them in STATICFILES_DIRS.

压缩在开发服务器上正常工作的原因是因为当DEBUG = True时，CssAbsoluteFilter将始终找到您的静态文件，即使您从未运行'collectstatic'。它在STATICFILES_DIRS中查找它们。

When DEBUG = False on your production server, CssAbsoluteFilter assumes that static files have already been collected into your COMPRESS_ROOT and won't apply the absolute filter if it can't find the files.

当生产服务器上的DEBUG = False时，CssAbsoluteFilter会假定静态文件已经收集到COMPRESS_ROOT中，如果无法找到文件，则不会应用绝对过滤器。

Jerdez, django-compressor's author, explains it like this:

django-compressor的作者Jerdez解释如下：

the CssAbsoluteFilter works with DEBUG = False if you've successfully provided the files to work with. During development compressors uses the staticfiles finder as a convenience so you don't have to run collectstatic all the time.

如果您已成功提供要使用的文件，则CssAbsoluteFilter与DEBUG = False一起使用。在开发过程中，压缩器使用staticfiles finder作为方便，因此您不必一直运行collectstatic。

Now for heroku. Even though you are storing your static files on S3, you need to also store them on heroku (using CachedS3BotoStorage). Since heroku is a read-only file system, the only way to do this is to let heroku collect your static files automatically during deployment (see https://devcenter.heroku.com/articles/django-assets).

现在为heroku。即使您将静态文件存储在S3上，也需要将它们存储在heroku上（使用CachedS3BotoStorage）。由于heroku是一个只读文件系统，唯一的方法是让heroku在部署期间自动收集静态文件（请参阅https://devcenter.heroku.com/articles/django-assets）。

In my experience, running 'heroku run python manage.py collectstatic --noinput' manually or even in your Procfile will upload the files to S3, but it will NOT save the files to your STATIC_ROOT directory (which compressor uses by default as the COMPRESS_ROOT). You can confirm that your static files have been collected on heroku using 'heroku run ls path/to/collected'.

根据我的经验，手动或甚至在你的Procfile中运行'heroku run python manage.py collectstatic --noinput'会将文件上传到S3，但它不会将文件保存到STATIC_ROOT目录（默认情况下压缩器使用哪个压缩程序作为COMPRESS_ROOT ）。您可以使用'heroku run ls path / to / collecting'确认您的静态文件已在heroku上收集。

If your files have been collected on heroku successfully, you should be able to compress your files successfully as well, without the solution I provided above.

如果您的文件已成功收集到heroku，您应该能够成功压缩文件，而无需我上面提供的解决方案。

However, it seems heroku will only collect static files if you have made changes to your static files since your last deploy. If no changes have been made to your static files, you will see something like "0 of 250 static files copied". This is a problem because heroku completely replaces your app contents when you deploy, so you lose whatever static files were previously collected in COMPRESS_ROOT/STATIC_ROOT. If you try to compress your files after the collected files no longer exist on heroku and DEBUG = False, the CssAbsoluteFilter will not replace the relative urls with absolute urls.

但是，如果您自上次部署以来对静态文件进行了更改，则heroku似乎只会收集静态文件。如果没有对静态文件进行任何更改，您将看到类似“复制的250个静态文件中的0个”。这是一个问题，因为heroku在部署时会完全替换您的应用程序内容，因此您将丢失以前在COMPRESS_ROOT / STATIC_ROOT中收集的任何静态文件。如果在heroku和DEBUG = False上不再存在收集的文件后尝试压缩文件，则CssAbsoluteFilter不会用绝对URL替换相对URL。

My solution above avoids the heroku problem altogether, and replaces relative css urls with absolute urls even when DEBUG = False.

我上面的解决方案完全避免了heroku问题，并且即使在DEBUG = False时也用绝对URL替换相对的css url。

Hopefully other people will find this information helpful as well.

希望其他人也会发现这些信息也很有用。

#2

I've had this exact same problem for a month now, but this is fixed in the 1.3 release (3/18/13, so you were probably on 1.2), so just upgrade:

我已经有一个月的完全相同的问题了，但这在1.3版本中已经修复（2013年3月18日，所以你可能在1.2上），所以只需升级：

pip install -U django-compressor

The exact problem I gave up on working out, but it's related to Heroku and CssAbsoluteFilter being called but failing at _converter method. Looking at the 1.3 changelog, the only related commit is this: https://github.com/jezdez/django_compressor/commit/8254f8d707f517ab154ad0d6d77dfc1ac292bf41

确切的问题我放弃了解决，但它与Heroku和CssAbsoluteFilter被调用有关但在_converter方法失败。查看1.3更改日志，唯一相关的提交是：https：//github.com/jezdez/django_compressor/commit/8254f8d707f517ab154ad0d6d77dfc1ac292bf41

I gave up there, life's too short.

我放弃了，生命太短暂了。

#3

Meanwhile this has been fixed in django-compressor 1.6. From the changelog:

同时这已经在django-compressor 1.6中得到修复。来自更改日志：

Apply CssAbsoluteFilter to precompiled css even when compression is disabled

i.e. the absolute filter is run even with DEBUG = True.

即使DEBUG = True，也运行绝对过滤器。

#1