File Uploads to Cloudinary Fail Under Django 5.2 (Works in 5.0.6)

[Sureshlama23]

After upgrading to Django 5.2, file uploads using django-cloudinary-storage==0.3.0 no longer upload to Cloudinary. Instead, Django automatically creates a local media/ folder and saves files there, even though the same configuration works perfectly with Django 5.0.6. The setting DEFAULT_FILE_STORAGE = "cloudinary_storage.storage.MediaCloudinaryStorage" is present and unchanged. There are no visible errors or warnings during the upload process. Reverting to Django 5.0.6 restores the expected behavior, where files are uploaded directly to Cloudinary and no local media directory is created. This suggests a breaking change in Django 5.2 or a compatibility issue with django-cloudinary-storage==0.3.0. Tested with Python 3.12.6, Django 5.2, and django-cloudinary-storage==0.3.0.

[klis87]

So it means that probably Django changed sth in 5.2 . Unfortunately I do not have any room to work on it. I will happily accept a PR though, and if necessary, help with the current code base.

[obatabba]

Issue confirmed, but it's not related to django-cloudinary-storage

So for the last couple of days I've been trying different cloud storage providers and I was very confused because the files kept getting saved in the filesystem, until I started using the "new" STORAGES dictionary for configuring storage backends, which was introduced in django 4.2 (see https://docs.djangoproject.com/en/5.2/releases/4.2/#custom-file-storages for more details) and despite the release notes clearly stating that the old settings (DEFAULT_FILE_STORAGE and STATICFILES_STORAGE) are deprecated as of that django release, and then they got removed in django 5.1 (see https://docs.djangoproject.com/en/5.2/releases/5.1/#features-removed-in-5-1 for more details), none of the tutorials or documentations of 3rd party packages (e.g. django-storages) states that only the new STORAGES dictionary works with django > 5.1

TL;DR

As from django 5.1, the only way to configure custom storage backends is like this:

# settings.py

STORAGES = {
     "default": {
          "BACKEND": "cloudinary_storage.storage.MediaCloudinaryStorage",
     },
     "staticfiles": {
          "BACKEND": "django.core.files.storage.FileSystemStorage",
     },
}

CLOUDINARY_STORAGE = {
    'CLOUD_NAME': 'your-cloud-name',
    'API_KEY': 'your-api-key',
    'API_SECRET': 'your-secret-key',
}

and there's also the OPTIONS key, which you can use with S3-compatible storages I guess:

# settings.py

STORAGES = {
     "default": {
          "BACKEND": "storages.backends.s3.S3Storage",
          "OPTIONS": {
              "access_key": 'your-s3-access-key',
              "secret_key": 'your-s3-secret-key',
              "bucket_name": 'your-s3-bucket-name',
          },
     },
     "staticfiles": {
          "BACKEND": "django.core.files.storage.FileSystemStorage",
     },
}

@Sureshlama23 I hope this helps.

@klis87 you can assign this issue to me, I'll try to update README.md as soon as I can.

[klis87]

@obatabba thank you so much for your investigation. assigned the issue to you :)

[obatabba]

@klis87 You're very welcome, and thank you for django-cloudinary-storage. I'll start working on it.

[obatabba]

@klis87 Hi.
I was getting started working on the docs and I realized something, as I mentioned earlier, DEFAULT_FILE_STORAGE won't work anymore and using STORAGES is mandatory, and this is a breaking change but we can't do anything about it. So if we're going to use STORAGES dictionary, why not also use OPTIONS sub-dictionary ? to give you some context, the values assigned to OPTIONS dictionary in STORAGES configuration gets automatically passed to the constructor of the storage class, and it's meant to be used to set the required settings of the Storage backend like API_KEY, for example:

STORAGES = {
     "default": {
          "BACKEND": "cloudinary_storage.storage.MediaCloudinaryStorage",
          "OPTIONS": {
               "CLOUD_NAME": "1",
               "API_KEY": "2",
               "API_SECRET": "3"
          }
     }
}

MediaCloudinaryStorage(Storage):

     def __init__(self, **settings):     # settings.items() -> [("CLOUD_NAME", "1"), ("API_KEY", "1"), ("API_SECRET)]
          ...

And in order to use this new mechanism, a lot of changes have to be done in app_settings.py, and I'm willing to work on it, but there's a design decision you should make, and it's whether or not the Clouidnary settings should be set only in the new OPTIONS dictionary or also in the current CLOUDINARY_STORAGE dictionary ? note that this doesn't help backward compatibility because again, DEFAULT_FILE_STORAGE is already removed, and new users of this package will have to use STORAGES anyway, so, should I keep CLOUDINARY_STORAGE or not ?

[Sureshlama23]

@obatabba Thanks a lot, I hadn’t used the STORAGES setting before, but your explanation clarifies it. I’ll update my config and give it a try. Appreciate your effort in tracking this down and sharing the solution :)

[klis87]

Thanks for you PR and analysis, I answered all your questions there, but if you need anything else, pls let me know