Several of our customers have their own image systems for storing images. They would like to integrate this into Enonic XP, but we are a bit unsure what best solution would be. They are all with APIs and similar, but we are unsure about the best way to integrate this. An easy way would be to sync all images to a Media-folder in XP, or we could use a CustomSelector to search through the API, but this would make it hard to use them inside the HTMLArea in the way we can insert images now.
Anyone has any suggestions to how this can be done? Ideally we would like the normal image selector to be able to connect to the DAM rather than searching through Enonic for images, but not sure if this is possible today.
As you mention, there are many different DAM solutions out there. DAM may store images and other files. As you know, XP is kind of a simple DAM on it’s own. XP supports both editorial handling and use of assets, including delivery, especially when it comes to images. This gets interesting when using images in the rich text fields as you say. Using Macro references (for instance) surely would not provide the best editor experience.
In general we recommend the following approach, which we believe provides the best editorial experience, as well as consistency in delivery and integration, even supporting with multiple DAM solutions at once.
Most DAM provide a way of exposing/exporting images, either as raw files or through an API. If supported, tune the max resolution of images in such “exports”, as high resolution images typically will reduce image delivery performance in XP.
Create a destination folder in XP, just like you propose i.e. “DAM/” or “Media/”, preferably at the root of your content project.
Write an XP app that imports the images (and optionally folder structures) from the source DAM. Use createMedia() when writing the files to XP. Remember, XP will also be able to consume any kind of files, not just limited to images.
The integration is naturally the most complex part here, and how it works will vary with the capabilities of the DAM. We generally suggest the following approach:
Support configuration options that can be tuned via file (or even better, through a custom Admin UI)
Take care to optimize the import routine, so, if possible it only gets the changes (new/modified/deleted). Remember, you can store custom properties with XP content that helps you link content to the source files in the DAM.
You could also create a custom repo that helps you store configuration and other metadata related to imports, i.e. when was import last run, is this the first time, etc etc.
If the DAM supports web-hooks, this should be configured to trigger import of changes to XP instantly.
