Cloudinary Dynamic Folders
- Overview
- New Media Library features when Dynamic Folders is enabled
- New API options when Dynamic Folders is enabled
- Things to consider
- Known issues
- Summary
- Resources
Overview
Dynamic folders provide Cloudinary users the flexibility to organize and manage media assets with high performance and without risk of breaking production content. This mode adds new features and fields that can be used in both the Media Library interface and the API. By default, Cloudinary uses fixed folder structures.
Dynamic folders enables Cloudinary users to move assets between folders and rename folders without affecting the asset's public_id value and delivery URL path. In Cloudinary's default fixed folders mode, the folder and asset name shown in the Media Library directly correlate to the asset's public_id full path, and so control the delivery URL path and file name. Any changes made to the folder or asset 'name' seen in the Media Library interface when using fixed mode also modifies the asset's URL and risks breaking production content.
Important things to note:
- This is currently in BETA
- Once an account or sub-account is migrated to dynamic folders, we cannot revert back to fixed folders mode
| Identifier | Unique? | Identifiable? |
|---|---|---|
| Asset ID | Yes | Yes |
| Public ID | Yes | No |
| Display Name | No | No |
* The same display name can be used for different assets even in the same asset folder.
New Media Library features when Dynamic Folders is enabled
- Moving assets (no effect on delivery URL)
- Moving and renaming asset folders (no effect on delivery URL)
- New Display Name field (for use in Media Library, unrelated to delivery URL or public_id)
- Edit Public ID (this will affect delivery URL)
- New options in the upload preset in Media Library
- New Asset Folder field - this determines the folder that an asset will be placed in within the Media Library, but has no effect on public_id and therefore not delivery URL either
- New Asset naming section where you can select either
- Default settings - public_id is a randomly generated unique value without a path, and the asset name will be taken directly from the filename (not preferable for our workflow with Hybris sync)
- Define custom naming for display name and public_id, including the option to define the URL path (known as public ID prefix). Public ID prefix can be set to match the asset folder the asset is being uplaoded to, or you can specify a prefix of your own. If an asset is moved between folders, the prefix will not update.
- Options for uploading assets that use an existing display name
New API options when Dynamic Folders is enabled
New paramters:
Upload API
- asset_folder (string)
- display_name (string)
- public_id_prefix (string)
- use_filename_as_display_name (boolean)
The asset_folder, public_id_prefix and use_filename_as_display_name parameters can also be defined via the upload_presets API.
Things to consider
- Permissions - Media Library user minimum permission levels for the new dynamic folders capabilities are as follows:
- Create new folders: Can Contribute
- Rename both public IDs and display names: Can Edit
- Rename and move folders: Can Manage
- From the Media Library, you can still replace assets in the same way as is possible in Fixed folders mode.
- When you upload asstets to the Media Library, or drag and drop into the Media Library, the public IDs will not automatically get a matching path.
- When passing a public_id value that includes slashes (for example, animals/cats/tiger), the entire passed value continues to be the public_id, but the slashes do not define the path where the asset is stored in the Media Library. If you don't also pass an asset_folder value, the asset will be displayed in the root folder of the Media Library.
Known issues
- Webhook notification responses: display_name and asset_folder details are not yet included in existing webhook notification responses.
- Webhook notification triggers: Changes to the asset display name or asset folder, whether via UI or API, do not yet trigger webhook notifications.
- Platform integrations: Cloudinary platform integrations have not yet been tested with dynamic folders enabled. It's not recommended to work with integrations in this mode during the Beta stage. This includes the Cloudinary and Google Cloud integrations.
Summary
- Huge benefit in allowing teams to move or rename assets without breaking production site
- Still in BETA which means more maintenance on our side to keep up to date, but features that are currently available are what we are looking for
- Potentially too much flexibility, particularly on the Merch side where we fully rely on the asset paths to be in an expected format for the sync with Hybris to work
- There are user permissions that we could set to reduce the number of people that have full control over all features and the full flexibility, but there would be some work to determine who those people are, and determine a workflow between different users that doesn't hold the team up
- Default / fallback settings for public_id wouldn't fit our use case, so we would be relying on the teams to accruately fill out upload fields correctly in order to organise folders in the way that is required
- Hasn't been tested with platform integrations, which we know we will be using, which could be high risk.