How to search a list using a Content Editor web part

Had a challenge for a little while - a large list, over 4000 items, that need to be searchable.  Our staff don't want to understand how to use columns to filter, and they like text boxes that they can type in to.

Only found out today that you can search a list using a query string, a la:

http://sharepoint/Lists/Applications/AllItems.aspx?FilterName=Title&FilterMultiValue=*adobe*

This will bring back all items in this list that has a title containing the word "adobe".  Changing FilterName to the name of the column you wish to search will enable you to search other columns as well.

So, with a bit of a kickstart from here - SharePoint List Search in Moss 2007 - I adapted and came up with this code, which you can easily shove into a Content Editor web part at the top of your list page (AllItems.aspx, in this case).

<script type="text/javascript">

function RedirectUrl() {

var cs = document.getElementById("searchText").value;

var url = '';

url = "FilterName=Title&FilterMultiValue=*" + cs + "*";

window.location.href = "AllItems.aspx?" + url;

};

</script>

<div style="border-top: #cccccc 1px solid; border-right: #cccccc 1px solid; background: #efefef; border-bottom: #cccccc 1px solid; padding-bottom: 5px; padding-top: 5px; padding-left: 5px; margin: 10px auto 0pt; border-left: #cccccc 1px solid; display: block; padding-right: 5px; width: 60%">

<h3 style="text-align: center">

Type in this box to filter the list below:

<input class="search" id="searchText" type="text" style="padding-bottom: 10px; padding-top: 10px; padding-left: 10px; padding-right: 10px"/>

<input id="btnSearch" onclick="return RedirectUrl();" type="button" value="Search"/>

</h3>

</div>

If you would like more information on throwing things around in a query string to filter or sort a list, have a look at this lovely blog post: Search, Filter or Sort Lists from a Query String.

Exporting all custom solutions from a SharePoint 2010 farm

Not many updates to the blog lately, apologies for that.  I'm working on moving our current SharePoint 2010 environment to a new server farm, hosted by a new company who insist that we have to rebuild everything from the ground up.

I've been using AutoSPInstaller to automate a lot of the process of building a new farm, but one thing I couldn't find much instruction on is those custom solutions and features we're using.  I didn't want to source every single solution again - some were developed by me, so they're easy to find, but there are others which aren't so easy to find (3rd party contractor developments).

Finally found a solution, from Using PowerShell to export all solutions from your SharePoint 2010 farm and other fun:

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + "\" + $_.Name; $_.SolutionFile.SaveAs($var)}

So simple, and works exactly as you'd expect.  Now I can pick from all of my solutions which ones I still actually need.

JSON returned from listdata.svc for a full list, but "XML" for a single item

I've been trying to use jQuery to get some data from a SharePoint list named Articles, using REST.  Hit a wall, couldn't figure it out.  Quick blog post about how I got around it.

Basically, when I tried to use $.getJSON with this URL:

http://sharepoint/_vti_bin/listdata.svc/Articles()

I was able to parse the data in jQuery as you'd expect.  Worked like a dream.  However, when I tried to just return one single list item, using:

http://sharepoint/_vti_bin/listdata.svc/Articles(1)

jQuery silently failed.  Couldn't get any data out of it whatsoever.  When I looked at Google Chrome's Developer Tools (specifically, the Network function), I could see that Articles() was being returned as application/json as you'd expect, but Articles(1) was being returned as text/plain.  jQuery didn't like that.

So, I added a parameter to my URL:

http://sharepoint/_vti_bin/listdata.svc/Articles(1)?format=JSON

And everything is right in the world again.

Investigating Translation Services in SharePoint 2013

There are a few parts to Translation Services.

The first is the ability to translate a document within Word Web App (interesting to note that Office Web Apps now runs separately to SharePoint 2013, whereas it was previously installed as a component to SharePoint 2010).  All you have to do is to click File, and then Translate.  You'll be given a list of languages to translate to, and your document will then be translated.  Of course, this is a systematic translation and won't be completely accurate, but it'll be a good indication. See this video - SharePoint 2013 Translation Service - to see it in action.

Secondly, and more impressively for developers and administrators, is the ability to translate documents from within the SP2013 interface.  Out of the box, there are PowerShell commands to perform translations, but a small piece of coding can be done (see: SharePoint 2013 translation services) that will allow you to add context or ribbon options that perform translations for you.  These can be done either synchronously (you wait for the translation to complete before you continue) - or asynchronously (the translations are carried out in the background and will be ready for viewing at a later stage, often within seconds).  This can be tied into workflow, so a document could be uploaded to a library, and the translation could then be placed into a language-specific library or sent to a human translator for approval.

The most interesting part of the asynchronous process (as demonstrated in the video above) is that entire document libraries can be translated at once.  A copy of each file is created, with the language code added to the file name after translation.

Finally, we come to Variations.  If you intend for your entire site to be multilingual, you would activate Variations.  This will allow all content - navigation, pages, even list items - to be different (or varying) across languages or locales.

If "Variations" have been enabled, SP2013 can prepare an XLIFF translation package for selected documents, and these can then be sent to, or downloaded by, an external translation agency.  When they have finished translating these documents, they send back, or upload, the translation package, and SP2013 will carry out the operations required to make these documents or pages available to that language variation.

For more info on Variations, see Variations overview in SharePoint Server 2013
...and for more info on Translation Services, see Introduction to Machine Translation Services in SharePoint 2013

Investigating network performance improvements in SharePoint 2013

Various improvements have been made to network performance in SharePoint 2013.  

One of the key improvements is known as Minimal Download Strategy.  From Introduction to Minimal Download Strategy in SharePoint 2013: "Minimal Download Strategy is a new feature in SharePoint 2013 that improves client rendering performance and fluidity when navigating from page to page by download only the changes between two compatible pages. Fewer bytes will be downloaded and the page will appear more quickly."

Sites running with Minimal Download Strategy (enabled by default for SP2013 team and community sites) only load the master page and layout once.  To compare, in SP2010, navigating to a sub-folder in a document library will cause the entire page to load again.  In our existing SP2010 site, the core layout and master page takes up 48Kb of bandwidth on each load, plus whatever the content of the actual page is (such as a document library, which is about 25Kb per page).  If you navigate to five pages within a site on SP2010, that uses around 350Kb of bandwidth.  In SP2013, this would be 170Kb.

In my tests on my own connection to the SP2010 server, a 70Kb page took on average 1113ms to display, which works out at 16ms per Kb.  For 20 typical page loads in SP2010, this would be 22.4 seconds of network usage.  In SP2013 (in theory), this would be reduced to 8.7 seconds of valuable network usage.

(Please note that these tests are certainly not controlled and comprehensive, but give a general idea of the improvements that Minimal Download Strategy can bring.)

Other improvements to WAN performance are improved image compression, and faster response time to incoming requests (up to 50% in some tests).  In other tests carried out by Microsoft (see Testing WAN connections for SharePoint 2013 architectures) on a connection between Redmond and Beijing showed a 10Mb ZIP file taking 53-140 seconds to upload to SP2010, but only taking 49-63 seconds to upload in SP2013.

Also worthy to note is the improved document library synchronisation.  This did exist in SP2010 using SharePoint Workspace, but I found this to be incredibly buggy and difficult to use when working with large teams.  Since SP2013 uses SkyDrive Pro (included with Office 2013), SharePoint document libraries can be completely synced onto a user's computer for offline use.  This can be used for an individual's personal work documents (in which case, the files are synchronised to the user's MySite on SP2013), or for a team to collaborate on documents as a group.  SkyDrive is already considered a worthy competitor to other services such as Dropbox and Google Drive for personal use, and this SP2013 integration brings that functionality to a business as well. (See also: Overview of SkyDrive Pro in SharePoint Server 2013)

To bring this all back to the end user, these improvements, plus the new look and feel (with better tactile response and more interactive page layouts) can help the SP2013 site seem almost instant and easier to use.

How to sell SharePoint 2013 to a steering committee

A few weeks ago, I was asked to prepare a presentation on the reasons we should upgrade our SharePoint 2010 environment to SharePoint 2013.  It wasn't enough to simply say "it looks pretty", but that was obviously (what I thought) a key selling point, as the presentation was to be delivered to non-technical decision makers.  My presentation included a look at the improved social computing features, an improved way of deploying new custom developments (or apps), and one final slide just summarising some of the new technical features - Translation Services, Workflow Services, and "Minimal Download Strategy".

It turns out that the greatest interest from almost everyone at the table was these three technical points.  The look and feel?  Not of interest to most people, as we already have a heavily-customised and branded master page.  Others didn't like the social element at all.  But the last slide was the strongest for them, and I learnt from that to focus more on these parts.

I decided to carry out more research on these technical features to better sell the product.  Sure, the end users will probably appreciate the new user interface and ease of use, but if the business owners don't see a benefit, the users will never get to use it.

The next few posts will be my semi-technical findings on:

• Minimal Download Strategy (or, more generally, network performance improvements)
• Translation Services

Hopefully someone else researching SP2013 will find some interest in these features and help them also sell a very promising product upgrade.

Changing a name in SharePoint People Picker using PowerShell

The company I work for has recently acquired another business, and the migration process for getting their Active Directory users into our Active Directory has resulted in duplicate accounts for the same person. Sometimes the duplicate account is on a different domain, but often it's the same domain, resulting in confusion when there is a need to select a user from the People Picker.

One option to resolve this is to simply delete the SPUser.  However, I don't like deleting things.  There is always a chance this could have adverse effects somewhere else, and there's also the higher chance that the SPUser will just be recreated when something occurs in the Active Directory.  So, I've opted for another solution, which is to simply change the DisplayName of that erroneous account to something obvious (such as "Do not use").

Eventually, these duplicate accounts will be deleted from the Active Directory, which makes me more confident in deleting the SPUsers too, but until then, this will have to do.

Set-SPUser -Web http://sharepoint -Identity "domain\duplicateuser" -DisplayName "Do Not Use"