Why are the default STORAGES options ignored?

[rose-pace]

I've been debugging an issue with images hosted in the cloud are not loading correctly and have gotten an error message stating that the container name was not set. I was surprised because I have it set in the options for my default STORAGES and my static STORAGES and everything not going through the CMS does work without this error. After digging through the filer code I noticed that the default storages backend is used by the options are not.

Is there a reason for this? If there is why even bother using the default storages setting at all and just specify that FILER_STORAGES must be used. At least add something to the documentation calling this out.

[fsbraun]

Hi @rose-pace , thanks for taking the time to dig into this and report your findings — we really appreciate detailed feedback like this.

You're absolutely right to point out the current behavior can be confusing, especially when the default Django STORAGES settings are respected only partially when it comes to filer.

To clarify: django-filer uses its own FILER_STORAGES configuration internally for historical reasons, and this separation can indeed lead to inconsistencies if not explicitly configured. That said, your suggestion to call this out more clearly in the documentation is a good one, and something I'd love to see improved. Also, we might want to have the default STORAGE options respected for FILER_STORAGES.

Please also keep in mind that django-filer is an open-source project maintained by a group of volunteers. We're always working to balance maintenance with limited time and resources, so thoughtful reports like yours help a lot.

If you're up for it, we'd welcome a pull request to improve the documentation or even explore a more consistent fallback to the default STORAGES. But in the meantime, we’ll aim to add a clarification in the docs to help others avoid this pitfall.

Thanks again!