Did you make it to CoreMedia's Developer Conference this year? If you didn't, well, you definitely missed out. If you did, you might remember our little competition for our Labs platform: We asked the community for ideas for useful and cool features they'd like to see in Labs, and promised that the best idea would actually get implemented.
The winners are Daniel Stephan and Constantin Erckenbrecht from our much valued partner init, who were nice enough to point us to an issue that's been a traditional headache in many projects: How can a casual user conveniently transfer content between CoreMedia environments (for example, from a Dev system to UAT, or the other way around)? Of course there's always been server export/import, but that's a developer tool, and as such pretty much keeps the "casual" users out of the game.
Enter CoreMedia Studio Hub.
If you're not aware, Studio Hub basically lets you "mount" various data sources into Studio so you can work with them seamlessly, as if they were stored in CoreMedia itself. Currently, implementations are available for Amazon S3, Dropbox, YouTube, RSS Feeds, and local filesystems. You can configure any number of them in your Studio instance, and once you do, the data sources appear as separate tree nodes in the Studio Library. There's an extensible preview and, of course, you can interact with the CoreMedia content repository by just dragging, say, an image stored in an S3 bucket into a CoreMedia folder, and a respective content item will be automatically created.
Screenshot Studio Selection
This is now also possible for other CoreMedia repositories. Syncing content works for single content items as well as for entire folders, which will then be copied recursively.
Of course, this implementation raises a few interesting questions with no obvious answers. For example, consider a situation where you transfer an entire subfolder to your primary repository, and one of the content items from the "source" repository links to an item outside of that subfolder. What should happen to this link once the respective content item is created in the target repository? One possible approach would be to check if the target repository has a content item with matching name and path than the original one, and then have the newly created document link to that one. But whether or not that is the right thing to do very much depends on your specific use case.
So why don't you take it for a spin and tell us what you think? We'd love to get some feedback on this, and yes, we're also open for pull requests.
