The Secret Diary of a Sitecore Content Hub Newcomer

I should probably start with a confession - that none of this is really secret, I just thought it sounded like a cool title #SorryNotSorry. Now that we've got that disappointment out of the way, let's get some context. I started working at Sitecore as a Solution Architect almost two years ago and for that time I've worked exclusively with Content Hub. I am in a slightly unusual position of having no prior experience of traditional Sitecore products (XM, XP etc.) and also not having worked for Stylelabs - the company that developed Content Hub before being acquired by Sitecore. This means I really am a complete newcomer and I thought it might be useful to summarise some key things I've learned.

Content Hub is API driven

This might seem obvious, but Content Hub being truly API driven is significant - in means that whatever you can do in the UI, you can do via the API, and sometimes even more. This can be relevant in small ways, such as looking at the definition of a system-owned property (which isn't possible through the UI), or in larger ways, such as creating mass-edit jobs. I find it really refreshing to work with a product that doesn't hide any of it's functionality and is therefore easily customisable.

For example, Content Hub has the ability to group assets into collections, and then share those collections publicly. I have recently been working with a client that wanted to extend the capabilities of this public collection page, such that when an asset is downloaded, some additional information is written into the metadata of the file based on some of the properties within Content Hub. This could be easily achieved by writing a relatively simple Next.JS app that replaces the out of the box public collection page, accessing data and renditions via the Content Hub SDK.

You Can Do Almost Anything

(But just because you can, doesn't mean you should) The scripting capabilities in Content Hub allow for an endless

array of possibilities. One of the common topics that come up in implementations is how to map SSO claims to User Groups - this is easily done using a User Sign In script. Using external components, custom code can be added to any page, for example to display some information from another system or provide a specific view of some data within Content Hub.

It is easy to see Content Hub as the solution to all problems - and whilst this is true a lot of the time, it's not true all the time. When considering building a customisation, I think it's important to keep in mind what it is you are using Content Hub for, whether as a DAM, a PCM or any of the other modules. If it doesn't enhance that objective, should it really live inside Content Hub, or would it be best living somewhere else, integrated through the API.

Media Processing is Awesome

Given Content Hub started life as a DAM, it probably goes without saying that it's media processing capabilities are awesome, but I'm going to say it anyway - Content Hub's media processing capabilities are awesome!

I won't go into too much detail here, as it's all covered within the Content Hub documentation, but two of my favourite features are transformations, which allow on-demand modification and cropping of images and layering, which allows images to be stacked on top of each other. Imagine I am a drinks company and I have an image of someone sat at a table about to enjoy one of my delicious zesty drinks. Rather than create many variants of this image, by using layering, I can overlay different variants of the bottle, with different flavours or a different language, to use in various situations or geographies - pretty cool right?

Developer Rules Still Apply

Just because Content Hub is a SaaS product, it doesn't mean we can throw the rule book out of the window, developer rules still apply. Things such as naming conventions, source control, environment pipelines all stay relevant. I've seen a few projects struggle because these principles weren't adhered to at the start of the project, and therefore suffer down the line as any other software development project would.

The good news is that there are some great tools to help us with this. The Content Hub CLI is super useful and since v1.1.0 can push and pull entities between environments, making deployments far easier. There is also the Sitecore Content Hub VS solution for managing scripts, and if I might give a plug to my own work, an External Components Starter.

There is A Fantastic Community

Last, but certainly not least (the most over-used of all the clichés), I've learned that there is a fantastic Sitecore community including the Sitecore Stack Exchange, the Slack community with it's dedicated Content Hub channel and Sitecore User Groups. There is also a vast array of community produced content, such as Ronald Van der Plas' super useful Content Hub Power chrome extension, Rob Habraken's focal point module and the already mentioned Sitecore VS solution.

Final Thought

In summary I've not really provided any secrets, or even presented this like a diary, so it's not much of a secret diary to be honest, but if you've read all the way to this point, I owe at least something to takeaway; so how about a classic three point summary: functionality, extensibility and community.