I have a custom media item template that allows users to add category filters to the uploaded file. The media item is kept in the media library. The filters are to be selected from a folder underneath the Home item of relevant site in the content tree. They are selected using a treelist control. We have multiple sites, each will have their own Home item and filter folder. I need to set the source of the treelist control to point to the relative filter folder for each site.
If the media item were under the Hoe item I could use this:
query:ancestor-or-self::*[##templatename='Home']/item[#key='filters']
But of course the media item won't find ancestor-or-self::*[##templatename='Home'] as it isn't on that branch, it's parallel.
I doubt our naming standard will be robust enough to ensure any relative path based entirely on item names, and I'd rather avoid having to concatenate a name of a media folder to find the correct name of the Home item.
Is there any way of solving this elegantly?
I could of course put the filters folder elsewhere, either in the Media library (would rather avoid this as it will not be intuitive to our business users) or in a global section (where they would have to find their own specific site folder below - or add another security configuration to the content tree).
The getLookupSourceItems pipeline would allow you to add custom tokens/syntax to the Source field, e.g. a lookup to the correct site's home item.
http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/Reference-the-Context-Item-and-System-Date-in-the-Source-Property-of-Sitecore-ASPNET-CMS-Fields.aspx
However from what I can gather, TreeList does not use this pipeline. Thus another option might be to create a custom TeeList field type.
http://www.cmssource.co.uk/blog/custom-tree-list
Answering my own question:
This isn't possible to do without employing some form of naming standard. If the branches within the media library mirror the branches within the content tree (Site1, Site2, Site3 etc) then a naming standard could enforce the correct relation between a media library branch and a content tree branch. If no such naming standard and branch mirroring is in place then there is no way of connecting a media folder with a specific site without adding a configuration item of some sort to contain the reference.
Related
I'm new to Sitecore XP 8.2 and try to study by articles and youtube.
However, I can't figure out why we should use datasource, instead of having multiple items in the content tree? How can I enable Global on the content tree?
If you by 'datasource' means 'Rendering Datasource Location' heres a real life example, where using datasource is helpfull, instead of having data items underneath each page item.
Lets say, you have a Footer module, which you would like to include on all content pages in your website. And the Editors should be able to change the content of the footer module on all pages, but the effect should be global.
In this case, could a solution be, to make a folder at the top of your tree structure called 'Shared Modules', and point the 'Footer Rendering Datasource Location' at this folder.
In case an editor changes the footer text on the main page or a subpage, the effect will allways be saved in the same location.
unlike, a 'Texbox module' which you would like to have multiple of on multiple pages. these would you like to have placed underneath each of your content pages in a folder e.g 'Page Modules'.
You can use Sitecore Datasource for a variety of reasons. One of the reasons is to use this instead of context item so that you can refer to another item in Sitecore content tree. Another good reason is to personalize your content or run the A/B testing, content testing. Using Sitecore datasource, make different parts of page componentize and all this helps content editor to improve experience in content editor.
For some good information on using Sitecore datasource, you can look at
https://www.linkedin.com/pulse/how-improve-experience-editor-sitecore-number-ways-rohit-chopra
https://www.linkedin.com/pulse/sitecore-personalize-content-conditional-renderings-sub-rohit-chopra
In short, with datasources you can re-use your items, makes your life much easier if you want to go with personalization and its easier to manage in terms of security/workflows.
A datasource is a pointer from your presentation to a content item. This item can easily be picked from a global or local placement in the content tree. You can still navigate from the datasource to other items (like subitems) if you want a more complex structure for your content.
The advantages of using datasources, is that Sitecores presentation engine, Experience Editor and marketing/personalization is based on the usage of datasources. Further you cater for reuse of content, as multiple presentations can point to the same datasource item.
By using datasources you decouple the content from the structure of your content tree and hierarchy.
I'm trying to understand the best approach to create article items in my sitecore 7.2 project.
Basically I'm considering 2 options:
1 - Create an article as a page;
2 - Create an article as a Site Data Item.
1 - Create article pages under a given page (i.e. My Articles). This way each article would have a specific URL out of the box, easier to understand in Content Authors' point of view;
2 - Have a specific folder (i.e. Article Folder) under Site Data. This way we don't need to have a page for each article - I was thinking to have a single Article page that would render the article fields. However this would require more work in terms of URLs, navigation, etc.
Is there any other ideas? Am I missing something? I was also having a look at Buckets...
Thank you
I'm going to disagree with Marek and recommend you opt for option 2.
Storing your articles in folder under a Data node allows those items to be datasourced. This is the principle Sitecore was built on. You can then surface those articles in a number of interesting ways via Widgets such as Promo Panels, prompting the user to click through to read about the article without duplicating its data and requiring Content Editors to manage data multiple times.
It even supports multiple sites, so the Articles can be used in other sites you may add to your Sitecore instance in the future.
As you state it will require extra work in terms of Urls and Navigation but it can be achieved via Sitecore's Wild Card Item and you an even use a great open sourced Module from Sitecore's Marketplace to complete 90% of the work for you. See links below for more information.
You can still implement Marek's point of applying Presentation Details once on the Standard Values of the Wild Cart Item you create. If you are using Sitecore 7 and above you can store all your articles in a Bucket so if you have lots of articles they are stored and searchable in a meaningful way.
http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2011/09/wildcards-and-data-driven-urls.aspx
https://marketplace.sitecore.net/en/Modules/Wildcard_module.aspx
In a standard one instance setup the easiest implementation is to create articles as pages.
In Sitecore you want to limit the items in a folder to 100 or less which is best practice to keep the content editors experience optimal.
This then leads you needing a folder structure and a couple options:
Manually maintain a folder structure for your articles. For example articles/year/month/day. This gives your editors the most control over the folder structure and allow them to navigate the articles in a more traditional way via a visible folder structure.
Use a bucket which automatically generates the folder structure and hides this complexity from the content editor. This takes the manual folder creation and maintenance away from the content editor and are automatically generated based on the configuration you set out for your bucket. The folders wont be visible to the content editor so they will be forced to search in the bucket for any articles rather then navigate the folders.
Use the shared source News mover module (https://marketplace.sitecore.net/en/Modules/News_mover.aspx). This takes a different approach to the above. It works via a traditional folder structure however it generates folders and moves the item on save based on the date field in the article. So the news mover handles the generation of folders however you will still need to check your not exceeding 100 items per folder again for performance when opening folders with large amounts of items.
With all solutions you must still consider the URLs for your articles as they will include the folder structure by default. This is not always acceptable. I prefer to remove the folder structure from the URL. For this you need to create a custom linkProvider and a custom HttpRequestProcessor. Firstly the linkprovider allows you to ensure the new URL is always created and displayed in your site as you want. Next the HttpRequestProcessor ensures that when navigating to the shortened URL Sitecore recognises it as a valid URL and presents the correct page.
By excluding the folder structure from the URL it also adds the additional benefit that the URL is not dependent on the structure. This means editors can change that folder structure and not need to create redirect items to ensure SEO rankings or users bookmarks are not lost.
The cleaner data model is to use the wildcard approach for the URLs and centralize the storage of articles data in a bucket of datasources. This will give you optimum performance and reuse of the data.
However, this isn't how an author thinks about their website. When they use the system, they tend to navigate to the area where they would view articles and try to create a new one there. Authors tend to think in 'pages', so try to hide whatever data model you are using from them and give them the ability to edit the page with Experience Editor.
Some developers try to optimize too far and forget that the authoring experience is likely the most important piece of the delivered solution. The author doesn't care how efficiently you stored the data, only that they can edit it easily and publish efficiently. Whatever model supports that for your author base is how you should implement it.
My recommendation is a page-based approach where the author creates the URL structure with folders and items, something they understand. Then, if you really need to, you can have the primary article data be a datasource-driven component on the page. The user gets to use all the tools they are familiar with (Experience Editor,preview navigation) but you can still store the raw data in a centralized folder. You could then theoretically swap out the article data using DMS rules, or hide information based on authentication or membership status.
Go with approach 1: article is a page.
Define all your presentation details on Article Page template __Standard Values. All new articles will get them. And you can change some of the presentation details for your chosen articles if you want.
If you know that you'll have lot of articles, think about year/month/day folder structure, e.g. articles/2015/06/12.
Approach 2 doesn't give you anything - you still need to have an item for every article. And as you wrote, it would require additional coding which is not required.
I'm looking to use the Sitecore Item Buckets package from Shared Source since I needed faceted search functionality and it makes sense to use the built in functionality rather than writing by own Lucene.Net search.
Sitecore Item Buckets
I'm having trouble with the search, or maybe I am reading the documentation wrong.
According to the documentation in section 2.2.3 & 3.1.3 I just need to mark a field as "Is Facet" and my filter will show in the search results.
I've also defined a tag field on the template and changed the Tag Parent field in "/sitecore/system/Modules/Item Buckets/Item Buckets Settings" to point to correct folder. This is working correctly, I can apply a set of tags to an item and search from the Bucket UI using "tag:CSharp" and it brings back the correct results, but again there is no filter shown in the list. I've rebuilt the bucket indexes in all cases.
Am I missing something? Should these show up in the list automatically, do I need to change some settings or provide my own implementation?
Screenshot
This is all within the Buckets Client UI, I haven't started writing any code yet, and on a clean install of Sitecore 6.5 (update-5/rev. 120706).
I'm not sure the documentation wording around this is entirely clear at the points I've mentioned. If you read further down the document though, section 4.3:
Item Buckets ships with 5 different types of faceting.
Templates
Fields
Dates
Locations
Authors
If you would like to introduce your own faceting categories then you only need to implement the IFacet interface.
There is an example of IFacet implementation in the documentation, or use dotPeek to look at the implementations of the existing Facets.
You also need to add an item to Sitecore: /sitecore/system/Modules/Item Buckets/Facets
I'm trying to implement a list where the only item type is a folder. If someone click "New" they are brought to a form that allows them to enter a folder name, description, and select either "Active" or "Inactive" from a drop-down menu. Inside the folder I want a simple list with only 2 columns.
I tried making a custom Folder content type with the columns I needed and making it the default content type. This seems to work to make the list of folders. Once I go inside the folder and try to change the internal view/list setting (I don't want to use the custom folder content type inside the folder...i just need 2 simple columns) it changes the settings for the list of folders as well. Is there any way for the internal list to have different settings than its parent?
I don't know if this issue is still relevant, but maybe someone else will find my answer useful.
I used to implement a list that contains only folders in the root, which in order can contain few item based content types.
There was two event receivers for FeatureActivated and ItemAdded events, which changes UniqueContentTypeOrder property (the list of content types available for user to create) of the lists root folder and a folder being created respectively. Like this:
List<SPContentType> ctl = new List<SPContentType>();
foreach (SPContentType ct in lst.ContentTypes) if (ct.Id.IsChildOf(SPBuiltInContentTypeId.Folder)) ctl.Add(ct);
lst.RootFolder.UniqueContentTypeOrder = ctl;
lst.RootFolder.Update();
Also, I designated different available list views for root folder and the folders it contains, by specifying ContentTypeID attribute for a View definition.
Unfortunately, no. Since SharePoint is Lists are not relational data, the only options to you are allowing several Content Types. If a content type is available to the list, it's available to the entire list (root, and sub-folders).
One possibility to model what you are trying to accomplish relies on SharePoint 2010 Enterprise. Infopath allows you to customize the New Item Form for a List. It might be possible to edit the form such that it only allows Folders on the Top Level, and List Items within a folder, but I don't know for sure - it's been a while since I customized a List Form with Infopath.
I have a content type that has a lookup field for a document library in its sub site. The content type is declared a site collection root level but I want the look up field to look up the document library in its local sub site where used. I deploy the content types using PowerShell and have used an event receiver to add the look up field. I can't however get it to reference the correct list, it only ever references the list at the root site collection.
How can I overwrite the look up list?
I avoid setting the List attribute in the Field element. I have had problems saving the site as a template when a custom Field has the List attribute set. But the other problem is that these properties are write-once. Better to leave it blank in the definition and then set it in the instance programmatically using SPFieldLookup.LookupWebId and SPFieldLookup.LookupList.