hands-on Serach SharePoint Variations

Cross Site Publishing and Variations: hands-on experience

Thomy Gölles

Over the last months we had the chance to get our hands dirty in the new 2013 way. In this post I want to share some of the decisions we made by using the content by search webpart and the variations feature heavily. Introduction Late last year a customer asked us to implement a partner portal. He thought about a different publisher area where he is able to manage the content in German and a portal for each language group available. He wanted the upload use case as simple as possible to allow his co-workers to update the information without any further assistance. Also he requested to “somehow” tag the content for all other languages (FR, EN, IT, RU, CN) in German because they are not able to support all languages in the upload team. They also wanted to display the files in a “nice” way and the standard SharePoint list wasn’t included in their definition of nice. All user data (username, passwords) already existed from the up and running partner portal in use so we had to build a solution integrating all of this users in SharePoint. Also we had to guarantee that people from a defined language group can only access content of their configured language. How we did it Actually we already thought about XSP (Cross Site Publishing) and variations in our very first meeting. At this time we also thought that managed metadata navigation will be a good way to handle all the navigation settings in the portal, but … yeah that was plain wrong. Remember: you are not able to configure security trimmed links via managed metadata navigation. Everybody with access to the selected web will see all configured navigation links. For me that was a huge surprise. I had in mind that SharePoint *always* handles the navigation in the security context for the current user. With managed navigation that is not the case. So if you want to put some security in your navigation, you can’t use this new set of features. The XSP on the other hand worked like charm. We set up a document library as a catalogue for the content by search webpart. We used a term store to tag all the documents with the right category. To allow a real fast upload and publish process we mixed the metadata with a folder structure and worked with the default column values for the different folders. This enables the publisher to open that special library with the explorer view and allows a very fast upload with integrated tagging. For the ease of use we just implemented one document library with root folders for each language. From there on every language has a different subset of all available elements. The German portal hast the most content and every other language has just a subset of the German folder structure. With this folder structure the author only has to copy the documents to the right folder without any further configuration. Furthermore the author never has to actually update something in the user’s area. The only reason to browse the documents is to see if search already picked up the changes. Next step was to configure the variation root and the needed languages. In a first phase we built the German portal, so the variations generated a sub web with /de-de as our start url. In this web we created different web part pages for every content category. On every webpart page we configured a content by search webpart filtering on the specific content category. By using a custom display template we were able to show some specific information and a thumbnail for each element. That was some kind of tricky because we had to display documents and images as well with the same display template. If you dig deep into a search results node you recognize that the url to your element is different for documents and images, so you can’t build your href the same way. SharePoint always gives you the link to the display form for images in a document library if you use the Path property. You have to use a special property (DefaultEncodingURL) to get the full href to the specific picture. Security In terms of security we used SharePoint groups heavily. Every language has about 10 types of different user groups with different access rights. Both, the authoring web and the variation webs are security aware. All users are stored in a SQL database that is configured as a FBA membership provider source in SharePoint. Within the FBA administration every user can be configured for a different role in the portal. Adding a new language The task of adding a new language to the portal is accomplished by a mix of hands on configuration and some powershell scripts. All content is uploaded to an instance of the defined folder structure and tagged properly. The variations feature creates the new subweb with the target language. The SharePoint standard user interface supports the language by installing the right language pack. All custom menu entries at the navigation configuration have to be updated with the translated terms. All webpart headings are set via a powershell script. We used some of Gary Lapointe’s powershell magic to update webpart properties. Conclusion The out of the box features of cross site publishing and variations are really a huge step forward for the product. Yes they are built with a little focus on web publishing and anonymous access where also managed metadata navigation integrates well. But I hope this post gives you an idea how this features can also be used in a security aware intranet solution. References: Without the help of this blogs and articles we never could have accomplished the given task! Thx!

Thoughts, stories and ideas.




Menu

Get Interesting News