You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The URLs generated by TenantStaticFilesStorage are not compatible with the standard Django FileSystemFinder.
This causes a range of issues as soon as users swop out the standard StaticFilesStorage via the recommended STATICFILES_STORAGE = "django_tenants.staticfiles.storage.TenantStaticFilesStorage" configuration setting.
For example, if tenant 'public' is active, then TenantStaticFileStorage.base_url will append the schema_name to the URL to produce /static/public/.
This behaviour has some unintended consequences:
It is likely that most downstream finders will be based on Django's FileSystemFinder. Since the standard finder is not tenant-aware, and does not know how to interpret tenant-specific URLs, all of those finders will fail to find any static files (tenant-specific or otherwise), essentially rendering them useless.
This is probably also why @gradedcatfood got his deployment to work as part of Static Files Won't Serve #248 by adding the compressor.finders.CompressorFinder (since that finder ignores STATICFILES_STORAGE and uses a hard-coded CompressorFileStorage for serving up compressed files).
A very useful aspect of how django-tenant's static file handling is intended to work is that users are supposed to be able to selectively override static files with tenant-specific versions, without the framework insisting that each tenant has to provide its own version of every static file. This is explained in the docs:
...by adding TenantFileSystemFinder at the top, we ensure that Django will look for the tenant-specific files first, before reverting to the standard search path. This makes it possible for tenants to override any static files (e.g. stylesheets or javascript files) that are specific to that tenant, and use the standard static files for the rest.
An easy way to see this problem manifest in the most recent build is to delete any static files that have been collected into the STATIC_ROOT folder (usually 'staticfiles') and then try to access the django-admin pages. In this use case, TenantStaticFilesStorage fails to find any static files in STATIC_ROOT, and all of the fallback finders configured in STATICFILES_FINDERS choke on the tenant-aware URL:
The text was updated successfully, but these errors were encountered:
jcass77
changed the title
TenantStaticFilesStorage is incompatible with FileSystemFinder.
TenantStaticFilesStorage is incompatible with FileSystemFinder.
Apr 21, 2019
The URLs generated by
TenantStaticFilesStorage
are not compatible with the standard DjangoFileSystemFinder
.This causes a range of issues as soon as users swop out the standard
StaticFilesStorage
via the recommendedSTATICFILES_STORAGE = "django_tenants.staticfiles.storage.TenantStaticFilesStorage"
configuration setting.For example, if tenant 'public' is active, then
TenantStaticFileStorage.base_url
will append theschema_name
to the URL to produce/static/public/
.This behaviour has some unintended consequences:
It is likely that most downstream finders will be based on Django's
FileSystemFinder
. Since the standard finder is not tenant-aware, and does not know how to interpret tenant-specific URLs, all of those finders will fail to find any static files (tenant-specific or otherwise), essentially rendering them useless.This is probably also why @gradedcatfood got his deployment to work as part of Static Files Won't Serve #248 by adding the
compressor.finders.CompressorFinder
(since that finder ignoresSTATICFILES_STORAGE
and uses a hard-codedCompressorFileStorage
for serving up compressed files).A very useful aspect of how django-tenant's static file handling is intended to work is that users are supposed to be able to selectively override static files with tenant-specific versions, without the framework insisting that each tenant has to provide its own version of every static file. This is explained in the docs:
An easy way to see this problem manifest in the most recent build is to delete any static files that have been collected into the
STATIC_ROOT
folder (usually 'staticfiles') and then try to access the django-admin pages. In this use case,TenantStaticFilesStorage
fails to find any static files inSTATIC_ROOT
, and all of the fallback finders configured inSTATICFILES_FINDERS
choke on the tenant-aware URL:The text was updated successfully, but these errors were encountered: