This blog post is a part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives our view about the setup of a flexible information architecture that can be reused in multiple projects.
Within a previous posts I introduced a Content module. This module contains fields that are used in pages. The definition of the content module is:
| Name | Base templates | Fields |
|---|---|---|
| IContent | Standard template | – |
| _ContentTitle | Standard template, IContent | ContentTitle |
| _ContentAbstract | Standard template, IContent | ContentAbstract |
| _ContentImage | Standard template, IContent | ContentImage |
Pages that are constructed in the project scope, inherit one or more of the _ContentTitle, _ContentAbstract and _ContentImage templates. When we focus on the _ContentImage template, containing a Sitecore image field type, we are confronted with an interesting challenge. The Source value for the image field type has to be set to a certain value from where the editors can select images. Because images are most likely project or even site scoped we have to find a way that images from other projects or sites are not accessible in the image selector.
The first thought is to find some solution to override the value of the Source field on project or site level. Unfortunately, until the moment of writing none of the current (Sitecore 8.2 update 2) or previous versions of Sitecore permits you to override this through some pipeline processor or other kind of configuration. Unless, and that’s where the second part of the post is about, you use a lookup field like droplist or droplink. For all other fields we have to think about a different solution
For selecting media items for the media library the solution lays in a good structure of the media library and the use of Sitecore security: roles and access rights.
An example of the media library structure can be this:
We created root folders for the different media types. Within these root folders, media folders for the different projects are created. A third level can be the creation of a universal media folder and site specific media folders within the project folder.
The reason for this structure is that the root for the image field type in the _ContentImage tem-plate can now be set to the root folder Images in the media library. From there on, all access is managed with help of Sitecore security. By creating appropriate roles per project and/or site, and using access rights to divest access to folders that are not part of a project or site that fits the role, content managers and editors have only access to the subset they should have access to.
Another example where this will work as well could be a Related Media module. Within this module there are interface templates for selecting images (a collection of product specific images) and files (downloadable documents with extra information). Because multiple media items should be selected, the TreeListEx field type would fit this purpose. This implementation is straightforward and for a RelatedDocuments field the parameters look like this:
| Field name | RelatedDocuments |
| Field title | Related Documents for Download |
| Field type | TreeListEx |
| Field Source | datasource={730C1699-87A4-4CA7-A9CE-294AD7151F13}&includetemplatesforselection=Pdf |
When an editor has to select documents for download, and all security is applied, only the appropriate folders will appear:
What about related content?
Another interesting dilemma rises when you think about selecting related content. The content templates are created in the project scope, so, module in the feature or foundation scope never can dictate how the field is configured, because that leads to dependencies in the wrong direction. In a later post I’ll give a description how we solved that challenge.
Summary
In this post a outline is given for the access of content in de Media Library. By restuctering the Sitecore Media Library in a few folders with a distinct purpose, and by adding project and/or site folders beneath it is easy to order documents, images and other kind of media assets in a structured way. Using Sitecore security, e.g. roles and access rights, we can give content editors access to only those media items, they are allowed to access. The configuration of the corresponding field types in our modules, like TreeListEx and Image, is now made straightforward.
MY THOUGHTS ABOUT... 