Folder structure and is cached in the browser the exact same way as standard Tridion Items. The first time you load them they will be retrieved, and after that you have to use Refresh to update the list. So just like you do not see any call to the ECL GetList implementation when switching to an ECL folder already loaded, you won't see any call to the TCM ...
For starters it is important that you implement all of these methods correctly, and that you have a clear definition of what is a EclItemTypes.File and what is a EclItemTypes.Folder.
Let me try to explain based on my Flickr ECL provider example, the IContentLibraryContext.FindItem(IEclUri) I chose to return null, which basically forces ECL to call ...
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 ...
The icon on the mountpoint is set in the IconIdentifier method in the class that implements the IContentLibraryContext interface. For instance you could have something in there like:
public string IconIdentifier
if (_disconnected) return "disconnected";
The value for _disconnected you have to set ...
Access to see the ECL mount point (and also write permissions to Tridion metadata) is controlled with the permissions for the stub folder. Unfortunately the stub folder is hidden for non-admins, so only admins can modify the permissions in the current release of ECL (yes, we know :) ). Notice you can control both read and write access here (who can update ...
You should not attempt to create stubs manually though the core service.
The EclService (hosted in the same process as the Core Service) expose the method:
public IDictionary<string, string> CreateOrGetStubUris(IEnumerable<string> eclItemUris)
It will create the Tridion stub components for you (if needed) and return the TCM URIs.
ECL is what is technically known as "somewhat BluePrint aware". :)
More specific: ECL is aware that the same item can exist in multiple publications with different name, metadata, and even binary content. It is also aware that not all items are necessarily present in all publications. Every time ECL calls the provider to get an item (or a list of items) it ...
Does the "Everyone" group always have the same identifier (e.g. tcm:0-1-65568)?
Yes, this is the default id assigned during Tridion installation
How else would you find the Everyone ID (CME or code if you prefer)?
You can query the Tridion_cm database in the TRUSTEES table (this will always be id=1)
I understand this is a setting that's not visible in ...
The only option that we've found working is by separately exporting and importing the stubs from the parent publication before exporting and importing the other items.
Disclaimer: I don't know if this is the right way to do it, but as said, it seems to be the only option.
No you don't have to use the Media Manager ECL Stub Schema provided as part of the DXA Media Manager Module, as long as you ensure that the Schema title is exactly the same (it's the default title for MM ECL Stub Schemas, assuming that the ID of your ECL Mount Point for Media Manager is mm).
As of DXA 1.5, there are a few additional metadata fields defined ...
There is nothing in ECL that will attempt to stop a provider from leaking memory.
So all the usual suspects apply: Missing calls to Dispose, event subscriptions, and static variables. I am sure there are more, but these are the three top contenders to memory leak I have encountered.
If the memory leak is observed in an SDL provider (for example Media ...
In order to understand what is going on you need to understand how ECL works.
The ECL URI that you see in the UI is not what actually gets saved in to the CM.
When you use an ECL component somewhere in other component or page, under-the-hood ECL creates stub component (if it does not yet exist) and substitutes the ECL URI with the TCM URI of the just-...
One would indeed expect the ordering to be (alphabetical) similar to that of the CME, but as @Marko mentions, the order is coming from the external system. That is basically how ECL works.
In an ECL connector, you implement the IContentLibraryContext interface, and there you will have to implement the GetFolderContent(IEclUri parentFolderUri, int pageIndex, ...
If your Publisher is outscaled onto a separate Windows server, then you'll need to make sure that the ECL mountpoints are configured correctly on that server too.
I've been caught-out by that before!
P.S. You'll need to restart the SDL Publisher Windows Service after making the change.
You can only see HTML5 distributions in the SDL Media Manager mountpoint.
To publish from Media Manager to YouTube there is a specific YouTube channel where you need to add the assets too.
So if these assets are also in an HTML5 distribution, you can see (and use) these in SDL Tridion (you must have a Resolve ECL TBB which resolves the distribution to the ...
I have updated the following article. It now contains an extract of the App.config file containing the bindings and endpoint information.
Configure your App.config file with the URL to your Secure Token Service and you should be able to connect to SDL Media Manager using the provided helper class.
var mediaManagerClient = MediaManagerHelper....
I don't think it matters much if you insert Bart's TBB into the template before the DD4T TBBs. The problem is that DD4T's "Publish binaries for xxx" TBB will still throw this exception because it always does an AddBinary call on the URI, and that is not supported for ECL URIs.
To solve this, I think it is necessary to merge Bart's code with the DD4T TBBs, ...
Seems like Tridion.ExternalContentLibrary.TcmExtension is not installed or not working on your CM
In Tridion.ContentManager.config in "extensions" section you should have something like this
<add assemblyFileName="YOUR_TRIDION_FOLDER/bin/Tridion.ExternalContentLibrary.TcmExtension.dll" />
ECL installer adds it there but may be it is removed on your ...
There is no method build into ECL - the Tridion UI doesn't really have anything ECL could build it on top of as far as I know. An Anguilla data extender can't return a result and a warning. It can return a result or an error.
Try to avoid throwing exceptions in IContentLibrary.CreateContext. Unless you need to determine if the specific user has access to ...
For an item of the File type, make sure you return an instance of IContentLibraryMultimediaItem from GetItem and GetItems.
The exceptions can be a bit hard to read, as they originate from the code connecting the different versions of the contracts.
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 ...
ECL keeps track of Stub Schemas by AppData attached to the Schema
The AppData name starts with ecl:stubschema
Apparently this AppData was deleted somehow and therefore ECL lost track and tried to recreate the Schema causing the issues you describe.
You are right in guessing that the CME does caching. The part in ECL which integrates with the CME is implemented via a GUI Extension using the Anguilla framework, and browser caching plays a role here. This is why when deploying new GUI extensions we increment the modification number in the System.config file to force the browsers to get all new versions ...
After some debugging, we found the cause of this problem.
In our ECL extension, we have to implement the function
public IFolderContent GetFolderContent(IEclUri parentFolderUri, int pageIndex, EclItemTypes itemTypes)
The key to the solution is the itemTypes parameter
This ItemTypes parameter contains a list of itemType Enums ...
If it was running before and not anymore now, and you didn't change anything in the configuration just before it stopped working, then the configuration is fine.
My guess is something happened to the ability of the CMS connecting to the service end point address. Which could be several things:
connection issues somewhere between the CMS and the service
The YouTube ECL provider on Tridion World has the source code in the package zip, which you could update to use the newer YouTube API.
The provider was created for a specific project and hasn't really been looked at in a while. When I get a chance, I'll have a look at updating it to the newer API.
However, I can't promise when this will be, as I'm working ...
Browsing and selecting an item use the methods GetItem and GetFolderContent in your provider, so they are probably working as expected.
When you save an item, Tridion will automatically load the item again and return it to the UI which is then updated. This has nothing to do with ECL, it is how Tridion ensures the new state of the item is correctly shown in ...