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.