Manage Custom Media Metadata in the Contentstack SaaS Headless CMS

This blog post provides some perspectives about managing custom metadata for media assets stored in the Contentstack SaaS headless CMS. I do not have anything implemented as I do not have any related requirements; these are just some ideas that I wanted to write down while I was thinking about the topic. If anyone is interested in implementing any of these suggestions, with some minimal requirements, I would be happy to try to prototype something.

When a CMS user uploads a file into the CMS, Contentstack creates an asset. Assets are like entries that use a content type predefined by Contentstack. One of the fields of an asset is its URL, which returns the uploaded binary. Other fields populated by Contentstack indicate the type of the asset, its size, and for an image, its dimensions.

Some solutions require media metadata beyond the fields provided by Contentstack assets. You cannot alter the content type used for assets. Instead, you may store media metadata in entries that reference assets.

For example, a content type that represents a page may contain a group of fields, where one field references an asset to display on the page and other fields contain custom media metadata about that asset. This approach does not prevent data re-use, but storing media metadata separately from content simplifies specification of where and how to reuse data.

To store media metadata separately from content, you can create additional content types that define fields for custom media metadata, and associate entries based on that content type with assets in Contentstack. To prevent multiple entries for a single asset, you can make the field in the media metadata content type that reference the asset unique. You can use webhooks to create media metadata entries automatically when CMS users create assets and set the unique field value to reference the asset accordingly.

In the media metadata content type, you could implement a custom field type that allows the user to specify custom metadata while uploading a file. Rather than creating an asset, the CMS user would create an entry based on this content type, and then upload the resource “into” that entry. If you implement a custom field type for media metadata, then you may want to consider storing all media metadata to that field as a single JSON value rather than using separate Contentstack fields for each value.

Retrieving the media metadata entry for an asset would require an HTTP query separate from that used to retrieve the asset. To simplify its retrieval, you can use the title or description field of the asset to store the identifier of the related media metadata entry.

You can implement a webhook that copies field values from the media metadata entry updated by the CMS user to the description field of the corresponding asset when users save a media metadata entry.

You can implement a custom widget that renders a thumbnail (in the case of images), metadata, and links to view and edit the asset associated with a media metadata entry.

Rather than or in addition to using native CMS media management facilities, many headless CMS solutions integrate with digital asset management platforms, typically by implementing custom fields and extensions to the rich text editor that allow selection of media from external systems. Such extensions typically store the identifier of the external resource in a field of an entry, where metadata is managed in the source system.

Before modeling solutions for media metadata, consider any cases where CMS users may need to override data that would otherwise come from a shared source.

You can use Contentstack dynamic image manipulation to optimize, scale, and otherwise manipulate images before caching binary content on the CDN. You can upload multiple variations of a single image, such as copies with specific crop dimensions, or you can specify crop dimensions in content that references images.

If you have suggestions for managing media metadata for assets in Contentstack, please comment on this blog post.