I understand External Content Library items have a URI that start with ecl: and have both external and CM-side metadata. I'm confirming how these translate into content delivery functionality.

Queries. Are either types of metadata available in the Content Delivery API through normal broker (Custom Criteria) queries?

Link format and resolving. Is it a good idea to resolve ECL URIs before they get to delivery, regardless of where we render wrapping markup like players or image tags? In other words, should we publish a direct link (or HTML fragment) for an image or video rather than URIs that start with ecl:.

Or is the output an implementation choice (would you create a control, tag, or custom rel tag with an ecl URI as a parameter)?

Specifically I see the External Content Library API is for Template Building Blocks and the Event System--I'm guessing we shouldn't use these in delivery.

2 Answers 2


The CD side does not know anything about ECL items at all.

So you have to deal with them in your templating code in CM. This means if any metadata (either type) has to be published you need to do this from your template.

You also have to resolve the ECL URI into either something binary downloaded from the external system and included in the package (this is how the CMIS connector works), or a link to the published item on the external system (this is how the Media Manager Connector works). There is no right or wrong in either approach, it all depends on the system you connect to.

  • Okay, this suggests I might model ECL items with direct relationships like we do for most multimedia ("embedded" or linked in RTF or in separate links). The linking component will of course have the metadata for CD-side queries. For ecl items directly on a page, we could "template" out metadata as you describe. So CD doesn't "know" about the ecl items, but it'll definitely have component presentations (and pages) for ecl items. ;-) Oct 15, 2013 at 20:01

As Lars already answered, the CD side doesn't know about ECL, it is as simple as that. But that indeed doesn't stop us from working with ECL items and their (external) metadata from the delivery side.

In my blog post last month I've explained how you could push ECL Components to the Broker (as DCPs) and make their External Metadata (the ECL Metadata from the external system) available to be queried from the Broker API. Basically everything is possible, but you have to think about it beforehand and make sure you publish what you need to the Broker.

The only thing which is really limited is if your external server can deliver you context specific results. Say for instance when you call the ECL method GetTemplateFragment(attributes) you do this based on some attributes. Now if these attributes could resize the result, then that sounds like it is something you would want to happen request time, and not publishing time. That is not possible with ECL, as ECL only lives on the CM side. But if your external system has a solution for this, then maybe the Template fragment returned could be something that calls the external system at request time, rather than give a direct result (like SDL Media Manager videos, their template code is a script tag which requests the actual video rather than returning the video itself).

  • Nice post, though I see why you had to mention "evil" three times. :-) So the ECL multimedia (stub) Component Metadata is the same as non-ECL items and ends up in the broker (as "Custom Metadata"). I can see where a hide or read-only GUI extension could help with the copy-external-metadata approach. ;-) Oct 16, 2013 at 16:16
  • Yup this definitely can benefit from a hide or read-only UI extension like Tridion FBI. By the way I'm currently busy with an event handler which is called when the stub Component is saved, and that can also handle this type of insertion. I'll blog about that one separately when it's done and make a reference back as that can be considered a 3rd option (less evil than the template code perhaps). Oct 16, 2013 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.