We are performing an upgrade from TridionSites 9.0 to 9.6.

A custom ECL Provider that we are using appears to be behaving slightly differently and is causing errors in the 9.6 environments.

9.0 behavior:

  • User can see the ECL mountpoint, Folders, and Files in the content tree (left panel).
  • User can open the File items and is prompted with the "Edit parent item?" localization message before opening the item.
  • User can open the item and metadata, and publish the item without any errors.

9.6 behavior:

  • The user can see the ECL mount point, and Folders in the content tree, but the Files do not display (can only see these in the main pane after you select a Folder).
  • User opens the File item and opens immediately in read-only mode without prompting about localization (other non-ECL items in the environment such as components and pages display and open normally with localization).
  • When opening the item, an error notification appears:
Unable to load blueprint info for item with id "[id of the File item]"
Unable to open the requested item
[NotSupportedException message from GetItem]

This is due to a NotSupportedException thrown from the GetItem() method, as it appears that GetItem() is being run on the parent Folder rather than just the File item itself (our code throws the exception if a non-File item is processed by GetItem()).

  • Once open (in read-only mode), the user can see the File item content and metadata as expected (despite the error notification).
  • When attempting to publish the File item from the website level, the publish dialog can be opened, but when clicking publish the same error as above is thrown (again the error message is from an exception when running GetItem() on the parent folder of the file item):
Unable to publish item(s) with id "[id of the File item]"
[NotSupportedException message from GetItem]
  • The publish action fails (does not start the publishing after the error and the item does not appear in the publishing queue)

We are not sure what is the difference between the environments that are causing the issue, and if it is something we can resolve by updating the ECL Provider code or configuration. If anyone has seen a similar issue with ECL Providers when upgrading or has any ideas it would be useful.

Note: as part of the upgrade we have a new build of the ECL provider targeting .Net 4.8, and packaged the ECL Provider as an AddOn, though we have also tried the manual installation on the server, and taking the exact old version from the old environment, the behavior above remains the same in all instances.

  • You clearly did a good job testing and explaining the issue, thanks for that. Did you also reach out to customer support?
    – Nuno Linhares
    Apr 14, 2023 at 12:15
  • Thanks very much @NunoLinhares . We are also discussing this with support.
    – jjlv-dev
    Apr 14, 2023 at 17:53

1 Answer 1


In Tridion Sites 9.6, the CM-ECL integration has been overhauled. This started because we needed a new integration point for the Core Service REST, but we ended up with using a different architecture for the integration with WCF Core Service and TOM.NET too. That is: there is an integration between Core Service / TOM.NET and ECL now, whereas ECL used to be quite separate before (the integration was done in the UI layer only).

All in all, this means that Tridion Sites 9.6 may use ECL Providers / Connectors in a different way than before. Indeed, it is expected that it performs GetItem(s) on ECL Folders, because it builds full paths for ECL items.

Furthermore, Tridion Sites 9.6 may be affected more by erroneous ECL Provider / Connector implementations than earlier releases. For example, if the ECL Provider returns an invalid parent item, this will make it impossible to determine a proper path. When returning the item itself as parent item, this might even lead to an endless loop, but ECL can recognize many invalid ECL Provider / Connector behaviors and will log warnings in the ECL log rather than crashing :-)

So, if you are observing weird behavior with ECL Providers / Connectors which are built/tested against older versions, start by checking the ECL log file. It may give hints towards what should be changed in the ECL Provider / Connector.

  • Hi @RickPannekoek, thanks so much for this explanation. It's useful to know that the additional calls to GetItem on Folders are intentional. We are investigating to see how we can work around this by returning an IContentLibraryItem for the folders as well.
    – jjlv-dev
    Apr 20, 2023 at 17:04

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.