Media Library vs Content Hub

Laura,

The easy answer is to always use the Content Hub. I say this because the Media Library will "go away" forcing you to migrate your media library items to content hub items.

You can also use workspaces to separate your media library items. Create a workspace called Media Library or Images, etc and then you have a better way of organizing the content hub items rather than having everything in the default workspace.

TLDR; don't use the Media Library. We added it to Xperience because the Content hub wasn't mature enough for asset management 2 years ago when Xperience launched. Today the Content hub is 100x better and encourages marketers to do what they should have been doing for the past 10 years - treat their media and assets as content.

We have used the media library for a long time to manage assets and the client is most familiar with the media library.

Thankfully, we have a page in the documentation dedicated to all the features in Xperience for managing assets in the Content hub.

I know the content hub offers a lot of additional features for assets including editing, taxonomy & expanded customization.

This is correct. We also have features for optimization and AI content generation for assets in the Content hub. You can read about the benefits of using the Content hub for assets in our guides on storing content and content modeling.

I am concerned it could result in situations over time when many images are added, the ContentItem tables becoming very large.

Yes, it will become large just like the media library tables in previous versions of Kentico. Did those large tables cause a problem for your Kentico solutions?

We have tested the Content hub with millions of items 😅 and content delivery works just fine.

Also, what about separation of concerns? Having images, documents, and content in the content hub could make it messy.

Assets are content. If things are messy why not organize them?

• Smart folders (using content types and taxonomies)

• Content folders (for more organization control and responsibility)

• Workspaces (to limit content management permissions and access, like AlexG mentioned)

• If you need total control you can even create a "container" content type with content item fields to link and order related items.

Are you trying to convince me that Kentico media libraries never got messy because the media was separate from web pages? That was definitely never my experience 🤣🤣.

As Brenden mentioned, the media library will soon be deprecated and we're shipping a feature in the product to help customers (and partners) migrate media items to the Content hub (on our roadmap for June).

I've migrated our Media Library over to the Content Hub, using multiple Workspaces and migrating the "folder' structure as the content folders.

We have ourselves over 60,000 media assets i think...and i can tell you, it performs very well. Will it be slightly slower than if you had full paths (/mysite/media/etc)? Yes, because you can't beat a direct lookup, but that's hardly sustainable because you can't deploy then.

It probably is comparable in speed to the /getmedia links, as there is little to no difference between them and the /getcontentasset links in terms of lookup. It pulls down and caches images if you use blob storage (I would recommend).

I was at first worried about a bloated content hub, i'm not worried anymore.

We're also in the process of moving some things from a media library to the content hub. One slight issue we've run into is replicating the direct file path feature that K13 media libraries had. As far as I can tell there's no "easy" way to look up a content item by its folder. I put easy in quotes there because we did figure out a way, but it involves splitting apart the tree, getting code names for each segment, getting the ID, and then looking for a content item whose folder ID (which is not exposed via IContentQueryDataContainer) and name matches. None of that was obvious without breaking out a disassembler and seeing how XByK does this now.

Is there a better way to do that? Or any plan to introduce code to help with that?

Jason,

We'll likely support content item asset redirects in the future as an alternative solution to this scenario. So, instead of replicating "direct path" media library items (we have been recommending using permanent URLs in KX13 and older for awhile), you would be able to assign a redirect/alternative/vanity URL for that content item asset in the Content hub..

No promises on a delivery date for the feature, but it's something that has been discussed so give us feedback on the roadmap feature if this scenario is something you think you'll encounter again.

Thanks. I'll add feedback to that.

Our particular case was a client who is mass uploading 50+ files in the content hub and then emailing (outside of XByK) links to those files to their customers. Getting permanent content hub links to all of those files would be a lot of work, so they were pretty adamant about the need to access them by name and path.

Whether XByK is even the best place for something like that is certainly a good question, but their old CMS allowed them do it, so they wanted it here as well.

Whether XByK is even the best place for something like that is certainly a good question

Yeah, we focus features that enable easy content reuse within Xperience and across various channel types vs "export everything" features.

But, this is reasonable use case and like a great motivation for a team to build a small custom app in Xperience which lists recently uploaded content item assets & their URLs and then lets a marketer export the content item, asset, and URL values in bulk.

If you want an example of adding csv exporting to a listing page, check out the Kentico Community Portal example for form submissions.

Sometimes Kentico media library isn't the best way to store images either, we have had several v13 projects where the amount of images and subsequent folder structure required to store those images have caused the interface to be quite slow (particularly adding images to widgets).

I understand why everything has moved to the content hub, not only from the shared assets perspective but also making it very easy to add additional content to images (alt text for example) which was always a bit of a pain in the media library, and I'm sure the performance will be far better in the content hub than it was in the media library, making it easier to assign images to content and streamline a content editors workflow.

Having said that I do think its a shame the media library is going away, I realize we now have folders and smart folders in the content hub but i struggle to see how we can keep a handle on the content in there once it starts having 100K+ items in it (I'm less thinking about performance and more about management), I currently have a v13 site in mind with 10,000 nodes in the tree (each with a lot of widget content to move into the content hub) and 30,000 images in the media library (and that's not including a lot of other content that is currently stored in modules/custom tables which would probably be better stored in the content hub). It's hard to have discussions with clients on this system and say "this is going to be better for you" which it certainly is in many regards, but media storage is a hard sell, especially when they are struggling to keep a handle on their current system.

I think what I've taken from this is that Kentico are providing the foundation to be able to build sites, but once projects scale to enterprise level it really needs dedicated 3rd parties to handle these special requirements. this isn't just about images, for example if you want good site search you are probably looking at Algolia rather than the inbuilt Lucene, but that's not to say that the inbuilt search isn't great for smaller sites without the same requirement. In the same way for images something like Cloudinary or Binder are good options for storing images. This obviously adds additional cost but Kentico has always been a good framework for integrating with other systems, It's going to be down to each individual client/project to work out when what is built in is sufficient or when something more specialised is required to fulfil the needs of the project.

Thank you for sharing your perspective Chris!

I realize we now have folders and smart folders in the content hub but i struggle to see how we can keep a handle on the content in there once it starts having 100K+ items in it...

Just an idea, but you could use an entire workspace to separate the content items with assets from the non-asset content items. By separating assets into another workspace, the primary workspace wouldn't be cluttered with them.

This separate workspace could have whatever traditional content folder structure you need. It's worth noting that teams are familiar with a traditional folder structure so they think they need it, but content folders also require manual management so a larger hierarchy of folders might not be the best choice for scale.

You could then use a Taxonomy dedicated to internal content organization and search and build smart folders from this taxonomy. This is more scalable than content folders and a lot more flexible.

but media storage is a hard sell, especially when they are struggling to keep a handle on their current system.

From my experience with the media library in past versions of Kentico, that struggle was caused by how the Media Library was designed - a very simple folder structure, which didn't scale well, and required a large amount of manual maintenance.

The goal of the Content hub is to provide the scale and simplify the maintenance while also enable other kinds of tools to achieve the asset management experience the marketing team needs.

I think when a solution scales to a large number of content items we need to think differently about organization and management and let go of approaches that work fine for a small number of items.

It's going to be down to each individual client/project to work out when what is built in is sufficient or when something more specialised is required to fulfil the needs of the project.

Agree! We aren't a headless CMS that requires composability. We try to provide a good experience in the product for all the features a marketing team needs and allow optional composability if a team has a specific need... but I'm not yet convinced a large number of content items is one of those scenarios requiring composition with a separate product.