Update template loaders and static file storage for Django > 2.0

[jcass77]

It looks like TenantStaticFileStorage has not been updated since Django 1.8, and is no longer compatible with Django > 2.0.

This PR just rebases the implementation on the standard django.template.loaders package to bring django-tenants back up to parity.

Fixes #197.

[jcass77]

Ok, I think this PR is ready for review. It resolves a large number of long-standing issues related to static file handling.

Apologies for the large commit - most of the diffs are generated by documentation changes and new test cases.

• re-based implementation on Django 2.0 static file finders and storage handlers. Fixes MULTITENANT_RELATIVE_STATIC_ROOT not working as intended #197. Fixes Specialized tenant template:  #187.
• static files defined in the tenant folders will now correctly override any project-level files of the same name. This makes it possible to have tenants selectively change just those files (e.g. images, CSS or JavaScript), that are unique to a particular tenant.
• collectstatic_schemas now collects the static files to the correct subdirectory for each tenant.
• Added new template loader. Fixes Error when I try to use template based on tenants, on Django 2.0.2 #158.
• got rid of CURRENT_SCHEMA_TO_SERVER_STATICFILES hack. Fixes CURRENT_SCHEMA_TO_SERVER_STATICFILES usage #188.
• added test cases for everything related to static file handling.
• added sensible defaults to make configuration easier.
• rewrote the documentation to simplify configuration steps.
• updated travis django dependency to Django>=2.0,<2.2 to align with setup.py. This would cause the travis build to fail with the new implementation. Also addresses What is DJANGO<2 in Travis config?  #196.
• updated docker image to use ubuntu:16.04 so that we can get access to Python 3.6 for testing.

[phalt]

+1 this will resolve the tests, which do not currently pass when running setup.py locally

[tomturner]

@jcass77 Thanks for this.

[rdraju]

django_tenants.template.loaders.filesystem.Loader get initialized only once. It happens with the first request and directories are set based on that tenant. Same template directories get utilized for all further requests from any tenant.

[rdraju]

Not relying on self.dirs and overriding get_dirs is the way to go? Any performance considerations? Can they be mitigated using CachedLoader?

[jcass77]

Hmmm...I thought I tested that scenario but you are right @rdraju, the Loader is only initialised once so I can see how the same template might be returned for all subsequent tenants.

Have a look at TenantFileSystemFinder for ideas on doing lazy loading so that the dirs are still only initialised once for each tenant.

[selvara80]

Unfortunately, This change breaks other functionalities.
1)STATICFILES_FINDERS is only looking for static files from the tenant folder. No file is fetched from the public folder.
2)When testing Media, No module named 'django_tenants.files.storages' .Believe the file name incorrectly got changed to 'storage'

[jcass77]

1. As far as I can recall, the standard Django finders will take care of looking up static files in the public folder. You still need to reference it in your settings.py though, which should include something like the following:

STATICFILES_FINDERS = [
    # https://django-tenants.readthedocs.io/en/latest/static.html#static-files-finders-aware-tenant
    "django_tenants.staticfiles.finders.TenantFileSystemFinder",  # Must be first
    "django.contrib.staticfiles.finders.FileSystemFinder",  # <-- include Django standard finder.
    "django.contrib.staticfiles.finders.AppDirectoriesFinder",
]

2.django_tenants.files.storages was renamed to django_tenants.files.storage to align more closely with the Django standard naming convention. I updated all of the internal references but might have underestimated the impact that this could have on existing users with pre-existing configurations. Have you tried updating your settings to use the new module name?

[gnalbandian]

1. As far as I can recall, the standard Django finders will take care of looking up static files in the public folder. You still need to reference it in your settings.py though, which should include something like the following:

STATICFILES_FINDERS = [
    "django_tenants.staticfiles.finders.TenantFileSystemFinder",
    "django_tenants.staticfiles.finders.TenantFileSystemFinder",  # Must be first
    "django.contrib.staticfiles.finders.FileSystemFinder",  # <-- include Django standard finder.
    "django.contrib.staticfiles.finders.AppDirectoriesFinder",
]

2.django_tenants.files.storages was renamed to django_tenants.files.storage to align more closely with the Django standard naming convention. I updated all of the internal references but might have underestimated the impact that this could have on existing users with pre-existing configurations. Have you tried updating your settings to use the new module name?

The issue seems to be that the {% static %} is always replaced by the STATIC_ROOT path and the schema name of the tenant appended ( STATIC_ROOT/tenant_schema ) even though there is no specific folder for tenant static files

[jcass77]

@gnalbandian can you log a ticket so that we can track an resolve this separately.

If there are no tenant-specific static files for the project, then removing it from the STATICFILES_FINDERS config section and relying on the Django standard django.contrib.staticfiles.finders.FileSystemFinder should be all that is required for that specific use case - or am I overlooking something else?

[gnalbandian]

@gnalbandian can you log a ticket so that we can track an resolve this separately.

If there are no tenant-specific static files for the project, then removing it from the STATICFILES_FINDERS config section and relying on the Django standard django.contrib.staticfiles.finders.FileSystemFinder should be all that is required for that specific use case - or am I overlooking something else?

If that is the intended behavior, then it's working as its intended.
I thought that the desired behavior was:
First, check for specific tenant static files.
Then, if none found, check for global static files

[jcass77]

Thanks for the feedback @gnalbandian. Yes I think that is the intended behaviour: each STATICFILES_FINDERS only looks for static files in the specific folders that it has been designed / configured for.

For django.contrib.staticfiles.finders.FileSystemFinder, that means tenant-specific files.